2 # RFC 3045: Storing Vendor Information in the LDAP root DSE
7 # This attribute contains a single string, which represents the name of
8 # the LDAP server implementer.
10 # All LDAP server implementations SHOULD maintain a vendorName, which
11 # is generally the name of the company that wrote the LDAP Server code
14 attributetype ( 1.3.6.1.1.4 NAME 'vendorName'
15 EQUALITY 1.3.6.1.4.1.1466.109.114.1
16 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
17 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
21 # This attribute contains a string which represents the version of the
22 # LDAP server implementation.
24 # All LDAP server implementations SHOULD maintain a vendorVersion.
25 # Note that this value is typically a release value--comprised of a
26 # string and/or a string of numbers--used by the developer of the LDAP
27 # server product (as opposed to the supportedLDAPVersion, which
28 # specifies the version of the LDAP protocol supported by this server).
29 # This is single-valued so that it will only have one version value.
30 # This string MUST be unique between two versions, but there are no
31 # other syntactic restrictions on the value or the way it is formatted.
33 attributetype ( 1.3.6.1.1.5 NAME 'vendorVersion'
34 EQUALITY 1.3.6.1.4.1.1466.109.114.1
35 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
36 SINGLE-VALUE NO-USER-MODIFICATION
39 # The intent behind the equality match on vendorVersion is to not allow
40 # a less than or greater than type of query. Say release "LDAPv3 8.0"
41 # has a problem that is fixed in the next release "LDAPv3 8.5", but in
42 # the mean time there is also an update release say version "LDAPv3
43 # 8.01" that fixes the problem. This will hopefully stop the client
44 # from saying it will not work with a version less than "LDAPv3 8.5"
45 # when it would also work with "LDAPv3 8.01". With the equality match
46 # the client would have to exactly match what it is looking for.