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 DESC 'RFC3045: name of implementation vendor'
16 EQUALITY 1.3.6.1.4.1.1466.109.114.1
17 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
18 SINGLE-VALUE NO-USER-MODIFICATION
23 # This attribute contains a string which represents the version of the
24 # LDAP server implementation.
26 # All LDAP server implementations SHOULD maintain a vendorVersion.
27 # Note that this value is typically a release value--comprised of a
28 # string and/or a string of numbers--used by the developer of the LDAP
29 # server product (as opposed to the supportedLDAPVersion, which
30 # specifies the version of the LDAP protocol supported by this server).
31 # This is single-valued so that it will only have one version value.
32 # This string MUST be unique between two versions, but there are no
33 # other syntactic restrictions on the value or the way it is formatted.
35 attributetype ( 1.3.6.1.1.5 NAME 'vendorVersion'
36 DESC 'RFC3045: version of implementation'
37 EQUALITY 1.3.6.1.4.1.1466.109.114.1
38 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
39 SINGLE-VALUE NO-USER-MODIFICATION
42 # The intent behind the equality match on vendorVersion is to not allow
43 # a less than or greater than type of query. Say release "LDAPv3 8.0"
44 # has a problem that is fixed in the next release "LDAPv3 8.5", but in
45 # the mean time there is also an update release say version "LDAPv3
46 # 8.01" that fixes the problem. This will hopefully stop the client
47 # from saying it will not work with a version less than "LDAPv3 8.5"
48 # when it would also work with "LDAPv3 8.01". With the equality match
49 # the client would have to exactly match what it is looking for.