# # RFC 3045: Storing Vendor Information in the LDAP root DSE # # 2.1 vendorName # # This attribute contains a single string, which represents the name of # the LDAP server implementer. # # All LDAP server implementations SHOULD maintain a vendorName, which # is generally the name of the company that wrote the LDAP Server code # like "Novell, Inc." attributetype ( 1.3.6.1.1.4 NAME 'vendorName' DESC 'RFC3045: name of implementation vendor' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) # 2.2 vendorVersion # # This attribute contains a string which represents the version of the # LDAP server implementation. # # All LDAP server implementations SHOULD maintain a vendorVersion. # Note that this value is typically a release value--comprised of a # string and/or a string of numbers--used by the developer of the LDAP # server product (as opposed to the supportedLDAPVersion, which # specifies the version of the LDAP protocol supported by this server). # This is single-valued so that it will only have one version value. # This string MUST be unique between two versions, but there are no # other syntactic restrictions on the value or the way it is formatted. attributetype ( 1.3.6.1.1.5 NAME 'vendorVersion' DESC 'RFC3045: version of implementation' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) # The intent behind the equality match on vendorVersion is to not allow # a less than or greater than type of query. Say release "LDAPv3 8.0" # has a problem that is fixed in the next release "LDAPv3 8.5", but in # the mean time there is also an update release say version "LDAPv3 # 8.01" that fixes the problem. This will hopefully stop the client # from saying it will not work with a version less than "LDAPv3 8.5" # when it would also work with "LDAPv3 8.01". With the equality match # the client would have to exactly match what it is looking for.