--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Meredith
+Request for Comments: 3045 Novell Inc.
+Category: Informational January 2001
+
+
+ Storing Vendor Information in the LDAP root DSE
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document specifies two Lightweight Directory Access Protocol
+ (LDAP) attributes, vendorName and vendorVersion that MAY be included
+ in the root DSA-specific Entry (DSE) to advertise vendor-specific
+ information. These two attributes supplement the attributes defined
+ in section 3.4 of RFC 2251.
+
+ The information held in these attributes MAY be used for display and
+ informational purposes and MUST NOT be used for feature advertisement
+ or discovery.
+
+Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2219]
+
+1. Overview
+
+ LDAP clients discover server-specific data--such as available
+ controls, extensions, etc.--by reading the root DSE. See section 3.4
+ of [RFC2251] for details.
+
+ For display, information, and limited function discovery, it is
+ desirable to be able to query an LDAP server to determine the vendor
+ name of that server and also to see what version of that vendor's
+ code is currently installed.
+
+
+
+
+
+
+Meredith Informational [Page 1]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+1.1 Function discovery
+
+ There are many ways in which a particular version of a vendor's LDAP
+ server implementation may be functionally incomplete, or may contain
+ software anomalies. It is impossible to identify every known
+ shortcoming of an LDAP server with the given set of server data
+ advertisement attributes. Furthermore, often times, the anomalies of
+ an implementation are not found until after the implementation has
+ been distributed, deployed, and is in use.
+
+ The attributes defined in this document MAY be used by client
+ implementations in order to identify a particular server
+ implementation so that it can 'work around' such anomalies.
+
+ The attributes defined in this document MUST NOT be used to gather
+ information related to supported features of an LDAP implementation.
+ All LDAP features, mechanisms, and capabilities--if advertised--MUST
+ be advertised through other mechanisms, preferably advertisement
+ mechanisms defined in concert with said features, mechanisms, and
+ capabilities.
+
+2. Attribute Types
+
+ These attributes are an addition to the Server-specific Data
+ Requirements defined in section 3.4 of [RFC2251]. The associated
+ syntaxes are defined in section 4 of [RFC2252].
+
+ Servers MAY restrict access to vendorName or vendorVersion and
+ clients MUST NOT expect these attributes to be available.
+
+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."
+
+ ( 1.3.6.1.1.4 NAME 'vendorName' 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.
+
+
+
+
+Meredith Informational [Page 2]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+ 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.
+
+ ( 1.3.6.1.1.5 NAME 'vendorVersion' 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.
+
+3. Notes to Server Implementers
+
+ Server implementers may consider tying the vendorVersion attribute
+ value to the build mechanism so that it is automatically updated when
+ the version value changes.
+
+4. Notes to Client Developers
+
+ As mentioned in section 2.1, the use of vendorName and vendorVersion
+ MUST NOT be used to discover features.
+
+ It should be noted that an anomalies often on affect subset of
+ implementations reporting the same version information. Most
+ implementations support multiple platforms, have numerous
+ configuration options, and often support plug-ins.
+
+ Client implementations SHOULD be written in such a way as to accept
+ any value in the vendorName and vendorVersion attributes. If a
+ client implementation does not recognize the specific vendorName or
+ vendorVersion as one it recognizes, then for the purposes of 'working
+ around' anomalies, the client MUST assume that the server is complete
+ and correct. The client MUST work with implementations that do not
+ publish these attributes.
+
+
+
+
+
+
+Meredith Informational [Page 3]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+5. Security Considerations
+
+ The vendorName and vendorVersion attributes are provided only as
+ display or informational mechanisms, or as anomaly identifying
+ mechanisms. Client and application implementers must consider that
+ the existence of a given value in the vendorName or vendorVersion
+ attribute is no guarantee that the server was actually built by the
+ asserted vendor or that its version is the asserted version and
+ should act accordingly.
+
+ Server implementers should be aware that this information could be
+ used to exploit a security hole a server provides either by feature
+ or flaw.
+
+6. IANA Considerations
+
+ This document seeks to create two attributes, vendorName and
+ vendorVersion, which the IANA will primarily be responsible. This is
+ a one time effort; there is no need for any recurring assignment
+ after this stage.
+
+7. References
+
+ [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+8. Acknowledgments
+
+ The author would like to thank the generous input and review by
+ individuals at Novell including but not limited to Jim Sermersheim,
+ Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF
+ contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong,
+ Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers.
+
+
+
+
+
+
+
+
+Meredith Informational [Page 4]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+9. Author's Address
+
+ Mark Meredith
+ Novell Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+
+ Phone: 801-861-2645
+ EMail: mark_meredith@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meredith Informational [Page 5]
+\f
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meredith Informational [Page 6]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3088 OpenLDAP Foundation
+Category: Experimental April 2001
+
+
+ OpenLDAP Root Service
+ An experimental LDAP referral service
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ The OpenLDAP Project is operating an experimental LDAP (Lightweight
+ Directory Access Protocol) referral service known as the "OpenLDAP
+ Root Service". The automated system generates referrals based upon
+ service location information published in DNS SRV RRs (Domain Name
+ System location of services resource records). This document
+ describes this service.
+
+1. Background
+
+ LDAP [RFC2251] directories use a hierarchical naming scheme inherited
+ from X.500 [X500]. Traditionally, X.500 deployments have used a
+ geo-political naming scheme (e.g., CN=Jane
+ Doe,OU=Engineering,O=Example,ST=CA,C=US). However, registration
+ infrastructure and location services in many portions of the naming
+ hierarchical are inadequate or nonexistent.
+
+ The construction of a global directory requires a robust registration
+ infrastructure and location service. Use of Internet domain-based
+ naming [RFC2247] (e.g., UID=jdoe,DC=eng,DC=example,DC=net) allows
+ LDAP directory services to leverage the existing DNS [RFC1034]
+ registration infrastructure and DNS SRV [RFC2782] resource records
+ can be used to locate services [LOCATE].
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 1]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+1.1. The Glue
+
+ Most existing LDAP implementations do not support location of
+ directory services using DNS SRV resource records. However, most
+ servers support generation of referrals to "superior" server(s).
+ This service provides a "root" LDAP service which servers may use as
+ their superior referral service.
+
+ Client may also use the service directly to locate services
+ associated with an arbitrary Distinguished Name [RFC2253] within the
+ domain based hierarchy.
+
+ Notice:
+ The mechanisms used by service are experimental. The descriptions
+ provided by this document are not definitive. Definitive
+ mechanisms shall be published in a Standard Track document(s).
+
+2. Generating Referrals based upon DNS SRV RRs
+
+ This service returns referrals generated from DNS SRV resource
+ records [RFC2782].
+
+2.1. DN to Domain Name Mapping
+
+ The service maps a DN [RFC2253] to a fully qualified domain name
+ using the following algorithm:
+
+ domain = null;
+ foreach RDN left-to-right // [1]
+
+ {
+ if not multi-valued RDN and
+ RDN.type == domainComponent
+ {
+ if ( domain == null || domain == "." )
+ { // start
+ domain = "";
+ }
+ else
+ { // append separator
+ domain .= ".";
+ }
+
+ if ( RDN.value == "." )
+ { // root
+ domain = ".";
+ }
+ else
+
+
+
+Zeilenga Experimental [Page 2]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+ { // append domainComponent
+ domain .= RDN.value;
+ }
+ continue;
+ }
+ domain = null;
+ }
+
+ Examples:
+
+ Distinguished Name Domain
+ ----------------------------- ------------
+ DC=example,DC=net example.net
+ UID=jdoe,DC=example,DC=net example.net
+ DC=. . [2]
+ DC=example,DC=net,DC=. . [3]
+ DC=example,DC=.,DC=net net [4]
+ DC=example.net example.net [5]
+ CN=Jane Doe,O=example,C=US null
+ UID=jdoe,DC=example,C=US null
+ DC=example,O=example,DC=net net
+ DC=example+O=example,DC=net net
+ DC=example,C=US+DC=net null
+
+ Notes:
+
+ 0) A later incarnation will use a Standard Track mechanism.
+
+ 1) A later incarnation of this service may use a right-to-left
+ algorithm.
+
+ 2) RFC 2247 does not state how one can map the domain representing
+ the root of the domain tree to a DN. We suggest the root of the
+ domain tree be mapped to "DC=." and that this be reversable.
+
+ 3) RFC 2247 states that domain "example.net" should be mapped to the
+ DN "DC=example,DC=net", not to "DC=example,DC=net,DC=.". As it is
+ not our intent to introduce or support an alternative domain to DN
+ mapping, the algorithm ignores domainComponents to the left of
+ "DC=.".
+
+ 4) RFC 2247 states that domain "example.net" should be mapped to the
+ DN "DC=example,DC=net", not to "DC=example,DC=.,DC=net". As it is
+ not our intent to introduce or support an alternative domain to DN
+ mapping, the algorithm ignores domainComponents to the left of
+ "DC=." and "DC=." itself if further domainComponents are found to
+ the right.
+
+
+
+
+Zeilenga Experimental [Page 3]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+ 5) RFC 2247 states that value of an DC attribute type is a domain
+ component. It should not contain multiple domain components. A
+ later incarnation of this service may map this domain to null or
+ be coded to return invalid DN error.
+
+ If the domain is null or ".", the service aborts further processing
+ and returns noSuchObject. Later incarnation of this service may
+ abort processing if the resulting domain is a top-level domain.
+
+2.2. Locating LDAP services
+
+ The root service locates services associated with a given fully
+ qualified domain name by querying the Domain Name System for LDAP SRV
+ resource records. For the domain example.net, the service would do a
+ issue a SRV query for the domain "_ldap._tcp.example.net". A
+ successful query will return one or more resource records of the
+ form:
+
+ _ldap._tcp.example.net. IN SRV 0 0 389 ldap.example.net.
+
+ If no LDAP SRV resource records are returned or any DNS error occurs,
+ the service aborts further processing and returns noSuchObject.
+ Later incarnations of this service will better handle transient
+ errors.
+
+2.3. Constructing an LDAP Referrals
+
+ For each DNS SRV resource record returned for the domain, a LDAP URL
+ [RFC2255] is constructed. For the above resource record, the URL
+ would be:
+
+ ldap://ldap.example.net:389/
+
+ These URLs are then returned in the referral. The URLs are currently
+ returned in resolver order. That is, the server itself does not make
+ use of priority or weight information in the SRV resource records. A
+ later incarnation of this service may.
+
+3. Protocol Operations
+
+ This section describes how the service performs basic LDAP
+ operations. The service supports operations extended through certain
+ controls as described in a later section.
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 4]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+3.1. Basic Operations
+
+ Basic (add, compare, delete, modify, rename, search) operations
+ return a referral result if the target (or base) DN can be mapped to
+ a set of LDAP URLs as described above. Otherwise a noSuchObject
+ response or other appropriate response is returned.
+
+3.2. Bind Operation
+
+ The service accepts "anonymous" bind specifying version 2 or version
+ 3 of the protocol. All other bind requests will return a non-
+ successful resultCode. In particular, clients which submit clear
+ text credentials will be sent an unwillingToPerform resultCode with a
+ cautionary text regarding providing passwords to strangers.
+
+ As this service is read-only, LDAPv3 authentication [RFC2829] is not
+ supported.
+
+3.3. Unbind Operations
+
+ Upon receipt of an unbind request, the server abandons all
+ outstanding requests made by client and disconnects.
+
+3.4. Extended Operations
+
+ The service currently does recognize any extended operation. Later
+ incarnations of the service may support Start TLS [RFC2830] and other
+ operations.
+
+3.5. Update Operations
+
+ A later incarnation of this service may return unwillingToPerform for
+ all update operations as this is an unauthenticated service.
+
+4. Controls
+
+ The service supports the ManageDSAit control. Unsupported controls
+ are serviced per RFC 2251.
+
+4.1. ManageDSAit Control
+
+ The server recognizes and honors the ManageDSAit control [NAMEDREF]
+ provided with operations.
+
+ If DNS location information is available for the base DN itself, the
+ service will return unwillingToPerform for non-search operations.
+ For search operations, an entry will be returned if within scope and
+ matches the provided filter. For example:
+
+
+
+Zeilenga Experimental [Page 5]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+ c: searchRequest {
+ base="DC=example,DC=net"
+ scope=base
+ filter=(objectClass=*)
+ ManageDSAit
+ }
+
+ s: searchEntry {
+ dn: DC=example,DC=net
+ objectClass: referral
+ objectClass: extensibleObject
+ dc: example
+ ref: ldap://ldap.example.net:389/
+ associatedDomain: example.net
+ }
+ s: searchResult {
+ success
+ }
+
+ If DNS location information is available for the DC portion of a
+ subordinate entry, the service will return noSuchObject with the
+ matchedDN set to the DC portion of the base for search and update
+ operations.
+
+ c: searchRequest {
+ base="CN=subordinate,DC=example,DC=net"
+ scope=base
+ filter=(objectClass=*)
+ ManageDSAit
+ }
+
+ s: searchResult {
+ noSuchObject
+ matchedDN="DC=example,DC=net"
+ }
+
+5. Using the Service
+
+ Servers may be configured to refer superior requests to
+ <ldap://root.openldap.org:389>.
+
+ Though clients may use the service directly, this is not encouraged.
+ Clients should use a local service and only use this service when
+ referred to it.
+
+ The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over
+ TCP/IPv4. Future incarnations of this service may support TCP/IPv6
+ or other transport/internet protocols.
+
+
+
+Zeilenga Experimental [Page 6]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+6. Lessons Learned
+
+6.1. Scaling / Reliability
+
+ This service currently runs on a single host. This host and
+ associated network resources are not yet exhausted. If they do
+ become exhausted, we believe we can easily scale to meet the demand
+ through common distributed load balancing technics. The service can
+ also easily be duplicated locally.
+
+6.2. Protocol interoperability
+
+ This service has able avoided known interoperability issues in
+ supporting variants of LDAP.
+
+6.2.1. LDAPv3
+
+ The server implements all features of LDAPv3 [RFC2251] necessary to
+ provide the service.
+
+6.2.2. LDAPv2
+
+ LDAPv2 [RFC1777] does not support the return of referrals and hence
+ may not be referred to this service. Though a LDAPv2 client could
+ connect and issue requests to this service, the client would treat
+ any referral returned to it as an unknown error.
+
+6.2.3. LDAPv2+
+
+ LDAPv2+ [LDAPv2+] provides a number of extensions to LDAPv2,
+ including referrals. LDAPv2+, like LDAPv3, does not require a bind
+ operation before issuing of other operations. As the referral
+ representation differ between LDAPv2+ and LDAPv3, the service returns
+ LDAPv3 referrals in this case. However, as commonly deployed LDAPv2+
+ clients issue bind requests (for compatibility with LDAPv2 servers),
+ this has not generated any interoperability issues (yet).
+
+ A future incarnation of this service may drop support for LDAPv2+
+ (and LDAPv2).
+
+6.2.4. CLDAP
+
+ CLDAP [RFC1798] does not support the return of referrals and hence is
+ not supported.
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 7]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+7. Security Considerations
+
+ This service provides information to "anonymous" clients. This
+ information is derived from the public directories, namely the Domain
+ Name System.
+
+ The use of authentication would require clients to disclose
+ information to the service. This would be an unnecessary invasion of
+ privacy.
+
+ The lack of encryption allows eavesdropping upon client requests and
+ responses. A later incarnation of this service may support
+ encryption (such as via Start TLS [RFC2830]).
+
+ Information integrity protection is not provided by the service. The
+ service is subject to varies forms of DNS spoofing and attacks. LDAP
+ session or operation integrity would provide false sense of security
+ concerning the integrity of DNS information. A later incarnation of
+ this service may support DNSSEC and provide integrity protection (via
+ SASL, TLS, or IPSEC).
+
+ The service is subject to a variety of denial of service attacks.
+ The service is capable of blocking access by a number of factors.
+ This capability have yet to be used and likely would be ineffective
+ in preventing sophisticated attacks. Later incarnations of this
+ service will likely need better protection from such attacks.
+
+8. Conclusions
+
+ DNS is good glue. By leveraging of the Domain Name System, global
+ LDAP directories may be built without requiring a protocol specific
+ registration infrastructures.
+
+ In addition, use of DNS service location allows global directories to
+ be built "ad hoc". That is, anyone with a domain name can
+ participate. There is no requirement that the superior domain
+ participate.
+
+9. Additional Information
+
+ Additional information about the OpenLDAP Project and the OpenLDAP
+ Root Service can be found at <http://www.openldap.org/>.
+
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 8]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+10. Author's Address
+
+ Kurt Zeilenga
+ OpenLDAP Foundation
+
+ EMail: kurt@openldap.org
+
+11. Acknowledgments
+
+ Internet hosting for this experiment is provided by the Internet
+ Software Consortium <http://www.isc.org/>. Computing resources were
+ provided by Net Boolean Incorporated <http://www.boolean.net/>. This
+ experiment would not have been possible without the contributions of
+ numerous volunteers of the open source community. Mechanisms
+ described in this document are based upon those introduced in
+ [RFC2247] and [LOCATE].
+
+References
+
+ [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1777] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol", RFC 1777, March 1995.
+
+ [RFC1798] Young, A., "Connection-less Lightweight Directory Access
+ Protocol", RFC 1798, June 1995.
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
+ Sataluri, "Using Domains in LDAP/X.500 Distinguished
+ Names", RFC 2247, January 1998.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+
+
+Zeilenga Experimental [Page 9]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+ [LOCATE] IETF LDAPext WG, "Discovering LDAP Services with DNS",
+ Work in Progress.
+
+ [LDAPv2+] University of Michigan LDAP Team, "Referrals within the
+ LDAPv2 Protocol", August 1996.
+
+ [NAMEDREF] Zeilenga, K. (editor), "Named Subordinate References in
+ LDAP Directories", Work in Progress.
+
+ [X500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 10]
+\f
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 11]
+\f
projects / thirdparty / openldap.git / commitdiff
