directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pamarce...@apache.org
Subject svn commit: r847618 [19/37] - in /websites/production/directory/content/studio/users-guide: ./ apache_directory_studio/ apache_directory_studio/css/ apache_directory_studio/images/ apacheds/ apacheds/css/ apacheds/images/ apacheds_configuration/ apache...
Date Wed, 23 Jan 2013 08:22:33 GMT
Added: websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4514.txt
==============================================================================
--- websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4514.txt (added)
+++ websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4514.txt Wed Jan 23 08:22:07 2013
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                   K. Zeilenga, Ed.
+Request for Comments: 4514                           OpenLDAP Foundation
+Obsoletes: 2253                                                June 2006
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+              String Representation of Distinguished Names
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The X.500 Directory uses distinguished names (DNs) as primary keys to
+   entries in the directory.  This document defines the string
+   representation used in the Lightweight Directory Access Protocol
+   (LDAP) to transfer distinguished names.  The string representation is
+   designed to give a clean representation of commonly used
+   distinguished names, while being able to represent any distinguished
+   name.
+
+1.  Background and Intended Usage
+
+   In X.500-based directory systems [X.500], including those accessed
+   using the Lightweight Directory Access Protocol (LDAP) [RFC4510],
+   distinguished names (DNs) are used to unambiguously refer to
+   directory entries [X.501][RFC4512].
+
+   The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
+   In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
+   directory protocols), DNs are encoded using the Basic Encoding Rules
+   (BER) [X.690].  In LDAP, DNs are represented in the string form
+   described in this document.
+
+   It is important to have a common format to be able to unambiguously
+   represent a distinguished name.  The primary goal of this
+   specification is ease of encoding and decoding.  A secondary goal is
+   to have names that are human readable.  It is not expected that LDAP
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+   implementations with a human user interface would display these
+   strings directly to the user, but that they would most likely be
+   performing translations (such as expressing attribute type names in
+   the local national language).
+
+   This document defines the string representation of Distinguished
+   Names used in LDAP [RFC4511][RFC4517].  Section 2 details the
+   RECOMMENDED algorithm for converting a DN from its ASN.1 structured
+   representation to a string.  Section 3 details how to convert a DN
+   from a string to an ASN.1 structured representation.
+
+   While other documents may define other algorithms for converting a DN
+   from its ASN.1 structured representation to a string, all algorithms
+   MUST produce strings that adhere to the requirements of Section 3.
+
+   This document does not define a canonical string representation for
+   DNs.  Comparison of DNs for equality is to be performed in accordance
+   with the distinguishedNameMatch matching rule [RFC4517].
+
+   This document is a integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.  This document obsoletes
+   RFC 2253.  Changes since RFC 2253 are summarized in Appendix B.
+
+   This specification assumes familiarity with X.500 [X.500] and the
+   concept of Distinguished Name [X.501][RFC4512].
+
+1.1.  Conventions
+
+   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 BCP 14 [RFC2119].
+
+   Character names in this document use the notation for code points and
+   names from the Unicode Standard [Unicode].  For example, the letter
+   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+   Note: a glossary of terms used in Unicode can be found in [Glossary].
+   Information on the Unicode character encoding model can be found in
+   [CharModel].
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+2.  Converting DistinguishedName from ASN.1 to a String
+
+   X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
+   name.  The following is a variant provided for discussion purposes.
+
+      DistinguishedName ::= RDNSequence
+
+      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+          AttributeTypeAndValue
+
+      AttributeTypeAndValue ::= SEQUENCE {
+          type  AttributeType,
+          value AttributeValue }
+
+   This section defines the RECOMMENDED algorithm for converting a
+   distinguished name from an ASN.1-structured representation to a UTF-8
+   [RFC3629] encoded Unicode [Unicode] character string representation.
+   Other documents may describe other algorithms for converting a
+   distinguished name to a string, but only strings that conform to the
+   grammar defined in Section 3 SHALL be produced by LDAP
+   implementations.
+
+2.1.  Converting the RDNSequence
+
+   If the RDNSequence is an empty sequence, the result is the empty or
+   zero-length string.
+
+   Otherwise, the output consists of the string encodings of each
+   RelativeDistinguishedName in the RDNSequence (according to Section
+   2.2), starting with the last element of the sequence and moving
+   backwards toward the first.
+
+   The encodings of adjoining RelativeDistinguishedNames are separated
+   by a comma (',' U+002C) character.
+
+2.2.  Converting RelativeDistinguishedName
+
+   When converting from an ASN.1 RelativeDistinguishedName to a string,
+   the output consists of the string encodings of each
+   AttributeTypeAndValue (according to Section 2.3), in any order.
+
+   Where there is a multi-valued RDN, the outputs from adjoining
+   AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
+   character.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+2.3.  Converting AttributeTypeAndValue
+
+   The AttributeTypeAndValue is encoded as the string representation of
+   the AttributeType, followed by an equals sign ('=' U+003D) character,
+   followed by the string representation of the AttributeValue.  The
+   encoding of the AttributeValue is given in Section 2.4.
+
+   If the AttributeType is defined to have a short name (descriptor)
+   [RFC4512] and that short name is known to be registered [REGISTRY]
+   [RFC4520] as identifying the AttributeType, that short name, a
+   <descr>, is used.  Otherwise the AttributeType is encoded as the
+   dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
+   The <descr> and <numericoid> are defined in [RFC4512].
+
+   Implementations are not expected to dynamically update their
+   knowledge of registered short names.  However, implementations SHOULD
+   provide a mechanism to allow their knowledge of registered short
+   names to be updated.
+
+2.4.  Converting an AttributeValue from ASN.1 to a String
+
+   If the AttributeType is of the dotted-decimal form, the
+   AttributeValue is represented by an number sign ('#' U+0023)
+   character followed by the hexadecimal encoding of each of the octets
+   of the BER encoding of the X.500 AttributeValue.  This form is also
+   used when the syntax of the AttributeValue does not have an LDAP-
+   specific ([RFC4517], Section 3.1) string encoding defined for it, or
+   the LDAP-specific string encoding is not restricted to UTF-8-encoded
+   Unicode characters.  This form may also be used in other cases, such
+   as when a reversible string representation is desired (see Section
+   5.2).
+
+   Otherwise, if the AttributeValue is of a syntax that has a LDAP-
+   specific string encoding, the value is converted first to a UTF-8-
+   encoded Unicode string according to its syntax specification (see
+   [RFC4517], Section 3.3, for examples).  If that UTF-8-encoded Unicode
+   string does not have any of the following characters that need
+   escaping, then that string can be used as the string representation
+   of the value.
+
+      - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
+        the beginning of the string;
+
+      - a space (' ' U+0020) character occurring at the end of the
+        string;
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+      - one of the characters '"', '+', ',', ';', '<', '>',  or '\'
+        (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
+        respectively);
+
+      - the null (U+0000) character.
+
+   Other characters may be escaped.
+
+   Each octet of the character to be escaped is replaced by a backslash
+   and two hex digits, which form a single octet in the code of the
+   character.  Alternatively, if and only if the character to be escaped
+   is one of
+
+      ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
+      (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
+       U+003C, U+003D, U+003E, U+005C, respectively)
+
+   it can be prefixed by a backslash ('\' U+005C).
+
+   Examples of the escaping mechanism are shown in Section 4.
+
+3.  Parsing a String Back to a Distinguished Name
+
+   The string representation of Distinguished Names is restricted to
+   UTF-8 [RFC3629] encoded Unicode [Unicode] characters.  The structure
+   of this string representation is specified using the following
+   Augmented BNF [RFC4234] grammar:
+
+      distinguishedName = [ relativeDistinguishedName
+          *( COMMA relativeDistinguishedName ) ]
+      relativeDistinguishedName = attributeTypeAndValue
+          *( PLUS attributeTypeAndValue )
+      attributeTypeAndValue = attributeType EQUALS attributeValue
+      attributeType = descr / numericoid
+      attributeValue = string / hexstring
+
+      ; The following characters are to be escaped when they appear
+      ; in the value to be encoded: ESC, one of <escaped>, leading
+      ; SHARP or SPACE, trailing SPACE, and NULL.
+      string =   [ ( leadchar / pair ) [ *( stringchar / pair )
+         ( trailchar / pair ) ] ]
+
+      leadchar = LUTF1 / UTFMB
+      LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
+         %x3D / %x3F-5B / %x5D-7F
+
+      trailchar  = TUTF1 / UTFMB
+      TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+         %x3D / %x3F-5B / %x5D-7F
+
+      stringchar = SUTF1 / UTFMB
+      SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
+         %x3D / %x3F-5B / %x5D-7F
+
+      pair = ESC ( ESC / special / hexpair )
+      special = escaped / SPACE / SHARP / EQUALS
+      escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
+      hexstring = SHARP 1*hexpair
+      hexpair = HEX HEX
+
+   where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
+   <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
+   <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
+
+   Each <attributeType>, either a <descr> or a <numericoid>, refers to
+   an attribute type of an attribute value assertion (AVA).  The
+   <attributeType> is followed by an <EQUALS> and an <attributeValue>.
+   The <attributeValue> is either in <string> or <hexstring> form.
+
+   If in <string> form, a LDAP string representation asserted value can
+   be obtained by replacing (left to right, non-recursively) each <pair>
+   appearing in the <string> as follows:
+
+      replace <ESC><ESC> with <ESC>;
+      replace <ESC><special> with <special>;
+      replace <ESC><hexpair> with the octet indicated by the <hexpair>.
+
+   If in <hexstring> form, a BER representation can be obtained from
+   converting each <hexpair> of the <hexstring> to the octet indicated
+   by the <hexpair>.
+
+   There is one or more attribute value assertions, separated by <PLUS>,
+   for a relative distinguished name.
+
+   There is zero or more relative distinguished names, separated by
+   <COMMA>, for a distinguished name.
+
+   Implementations MUST recognize AttributeType name strings
+   (descriptors) listed in the following table, but MAY recognize other
+   name strings.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+      String  X.500 AttributeType
+      ------  --------------------------------------------
+      CN      commonName (2.5.4.3)
+      L       localityName (2.5.4.7)
+      ST      stateOrProvinceName (2.5.4.8)
+      O       organizationName (2.5.4.10)
+      OU      organizationalUnitName (2.5.4.11)
+      C       countryName (2.5.4.6)
+      STREET  streetAddress (2.5.4.9)
+      DC      domainComponent (0.9.2342.19200300.100.1.25)
+      UID     userId (0.9.2342.19200300.100.1.1)
+
+   These attribute types are described in [RFC4519].
+
+   Implementations MAY recognize other DN string representations.
+   However, as there is no requirement that alternative DN string
+   representations be recognized (and, if so, how), implementations
+   SHOULD only generate DN strings in accordance with Section 2 of this
+   document.
+
+4.  Examples
+
+   This notation is designed to be convenient for common forms of name.
+   This section gives a few examples of distinguished names written
+   using this notation.  First is a name containing three relative
+   distinguished names (RDNs):
+
+      UID=jsmith,DC=example,DC=net
+
+   Here is an example of a name containing three RDNs, in which the
+   first RDN is multi-valued:
+
+      OU=Sales+CN=J.  Smith,DC=example,DC=net
+
+   This example shows the method of escaping of a special characters
+   appearing in a common name:
+
+      CN=James \"Jim\" Smith\, III,DC=example,DC=net
+
+   The following shows the method for encoding a value that contains a
+   carriage return character:
+
+      CN=Before\0dAfter,DC=example,DC=net
+
+   In this RDN example, the type in the RDN is unrecognized, and the
+   value is the BER encoding of an OCTET STRING containing two octets,
+   0x48 and 0x69.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+      1.3.6.1.4.1.1466.0=#04024869
+
+   Finally, this example shows an RDN whose commonName value consists of
+   5 letters:
+
+      Unicode Character                Code       UTF-8   Escaped
+      -------------------------------  ------     ------  --------
+      LATIN CAPITAL LETTER L           U+004C     0x4C    L
+      LATIN SMALL LETTER U             U+0075     0x75    u
+      LATIN SMALL LETTER C WITH CARON  U+010D     0xC48D  \C4\8D
+      LATIN SMALL LETTER I             U+0069     0x69    i
+      LATIN SMALL LETTER C WITH ACUTE  U+0107     0xC487  \C4\87
+
+   This could be encoded in printable ASCII [ASCII] (useful for
+   debugging purposes) as:
+
+      CN=Lu\C4\8Di\C4\87
+
+5.  Security Considerations
+
+   The following security considerations are specific to the handling of
+   distinguished names.  LDAP security considerations are discussed in
+   [RFC4511] and other documents comprising the LDAP Technical
+   Specification [RFC4510].
+
+5.1.  Disclosure
+
+   Distinguished Names typically consist of descriptive information
+   about the entries they name, which can be people, organizations,
+   devices, or other real-world objects.  This frequently includes some
+   of the following kinds of information:
+
+      - the common name of the object (i.e., a person's full name)
+      - an email or TCP/IP address
+      - its physical location (country, locality, city, street address)
+      - organizational attributes (such as department name or
+        affiliation)
+
+   In some cases, such information can be considered sensitive.  In many
+   countries, privacy laws exist that prohibit disclosure of certain
+   kinds of descriptive information (e.g., email addresses).  Hence,
+   server implementers are encouraged to support Directory Information
+   Tree (DIT) structural rules and name forms [RFC4512], as these
+   provide a mechanism for administrators to select appropriate naming
+   attributes for entries.  Administrators are encouraged to use
+   mechanisms, access controls, and other administrative controls that
+   may be available to restrict use of attributes containing sensitive
+   information in naming of entries.   Additionally, use of
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+   authentication and data security services in LDAP [RFC4513][RFC4511]
+   should be considered.
+
+5.2.  Use of Distinguished Names in Security Applications
+
+   The transformations of an AttributeValue value from its X.501 form to
+   an LDAP string representation are not always reversible back to the
+   same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
+   form.  An example of a situation that requires the DER form of a
+   distinguished name is the verification of an X.509 certificate.
+
+   For example, a distinguished name consisting of one RDN with one AVA,
+   in which the type is commonName and the value is of the TeletexString
+   choice with the letters 'Sam', would be represented in LDAP as the
+   string <CN=Sam>.  Another distinguished name in which the value is
+   still 'Sam', but is of the PrintableString choice, would have the
+   same representation <CN=Sam>.
+
+   Applications that require the reconstruction of the DER form of the
+   value SHOULD NOT use the string representation of attribute syntaxes
+   when converting a distinguished name to the LDAP format.  Instead,
+   they SHOULD use the hexadecimal form prefixed by the number sign ('#'
+   U+0023) as described in the first paragraph of Section 2.4.
+
+6.  Acknowledgements
+
+   This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
+   Steve Kille.  RFC 2253 was a product of the IETF ASID Working Group.
+
+   This document is a product of the IETF LDAPBIS Working Group.
+
+7.  References
+
+7.1.  Normative References
+
+   [REGISTRY]    IANA, Object Identifier Descriptors Registry,
+                 <http://www.iana.org/assignments/ldap-parameters>.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Schema for User Applications", RFC
+                 4519, June 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+7.2.  Informative References
+
+   [ASCII]       Coded Character Set--7-bit American Standard Code for
+                 Information Interchange, ANSI X3.4-1986.
+
+   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
+                 #17, Character Encoding Model", UTR17,
+                 <http://www.unicode.org/unicode/reports/tr17/>, August
+                 2000.
+
+   [Glossary]    The Unicode Consortium, "Unicode Glossary",
+                 <http://www.unicode.org/glossary/>.
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.511]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Abstract Service Definition", X.511(1993)
+                 (also ISO/IEC 9594-3:1993).
+
+   [X.690]       International Telecommunication Union -
+                 Telecommunication Standardization Sector,
+                 "Specification of ASN.1 encoding rules: Basic Encoding
+                 Rules (BER), Canonical Encoding Rules (CER), and
+                 Distinguished Encoding Rules (DER)", X.690(1997) (also
+                 ISO/IEC 8825-1:1998).
+
+   [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
+                 Technical Specification", RFC 2849, June 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+Appendix A.  Presentation Issues
+
+   This appendix is provided for informational purposes only; it is not
+   a normative part of this specification.
+
+   The string representation described in this document is not intended
+   to be presented to humans without translation.  However, at times it
+   may be desirable to present non-translated DN strings to users.  This
+   section discusses presentation issues associated with non-translated
+   DN strings.  Issues with presentation of translated DN strings are
+   not discussed in this appendix.  Transcoding issues are also not
+   discussed in this appendix.
+
+   This appendix provides guidance for applications presenting DN
+   strings to users.  This section is not comprehensive; it does not
+   discuss all presentation issues that implementers may face.
+
+   Not all user interfaces are capable of displaying the full set of
+   Unicode characters.  Some Unicode characters are not displayable.
+
+   It is recommended that human interfaces use the optional hex pair
+   escaping mechanism (Section 2.3) to produce a string representation
+   suitable for display to the user.  For example, an application can
+   generate a DN string for display that escapes all non-printable
+   characters appearing in the AttributeValue's string representation
+   (as demonstrated in the final example of Section 4).
+
+   When a DN string is displayed in free-form text, it is often
+   necessary to distinguish the DN string from surrounding text.  While
+   this is often done with whitespace (as demonstrated in Section 4), it
+   is noted that DN strings may end with whitespace.  Careful readers of
+   Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
+   may only appear in the DN string if escaped.  These characters are
+   intended to be used in free-form text to distinguish a DN string from
+   surrounding text.  For example, <CN=Sam\ > distinguishes the string
+   representation of the DN composed of one RDN consisting of the AVA
+   (the commonName (CN) value 'Sam ') from the surrounding text.  It
+   should be noted to the user that the wrapping '<' and '>' characters
+   are not part of the DN string.
+
+   DN strings can be quite long.  It is often desirable to line-wrap
+   overly long DN strings in presentations.  Line wrapping should be
+   done by inserting whitespace after the RDN separator character or, if
+   necessary, after the AVA separator character.  It should be noted to
+   the user that the inserted whitespace is not part of the DN string
+   and is to be removed before use in LDAP.  For example, the following
+   DN string is long:
+
+
+
+
+Zeilenga                    Standards Track                    [Page 12]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+         CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
+         O=OpenLDAP Foundation,ST=California,C=US
+
+   So it has been line-wrapped for readability.  The extra whitespace is
+   to be removed before the DN string is used in LDAP.
+
+   Inserting whitespace is not advised because it may not be obvious to
+   the user which whitespace is part of the DN string and which
+   whitespace was added for readability.
+
+   Another alternative is to use the LDAP Data Interchange Format (LDIF)
+   [RFC2849].  For example:
+
+         # This entry has a long DN...
+         dn: CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
+          O=OpenLDAP Foundation,ST=California,C=US
+         CN: Kurt D.  Zeilenga
+         SN: Zeilenga
+         objectClass: person
+
+Appendix B.  Changes Made since RFC 2253
+
+   This appendix is provided for informational purposes only, it is not
+   a normative part of this specification.
+
+   The following substantive changes were made to RFC 2253:
+
+      - Removed IESG Note.  The IESG Note has been addressed.
+      - Replaced all references to ISO 10646-1 with [Unicode].
+      - Clarified (in Section 1) that this document does not define a
+        canonical string representation.
+      - Clarified that Section 2 describes the RECOMMENDED encoding
+        algorithm and that alternative algorithms are allowed.  Some
+        encoding options described in RFC 2253 are now treated as
+        alternative algorithms in this specification.
+      - Revised specification (in Section 2) to allow short names of any
+        registered attribute type to appear in string representations of
+        DNs instead of being restricted to a "published table".  Removed
+        "as an example" language.  Added statement (in Section 3)
+        allowing recognition of additional names but require recognition
+        of those names in the published table.  The table now appears in
+        Section 3.
+      - Removed specification of additional requirements for LDAPv2
+        implementations which also support LDAPv3 (RFC 2253, Section 4)
+        as LDAPv2 is now Historic.
+      - Allowed recognition of alternative string representations.
+      - Updated Section 2.4 to allow hex pair escaping of all characters
+        and clarified escaping for when multiple octet UTF-8 encodings
+
+
+
+Zeilenga                    Standards Track                    [Page 13]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+        are present.  Indicated that null (U+0000) character is to be
+        escaped.  Indicated that equals sign ('=' U+003D) character may
+        be escaped as '\='.
+      - Rewrote Section 3 to use ABNF as defined in RFC 4234.
+      - Updated the Section 3 ABNF.  Changes include:
+        + allowed AttributeType short names of length 1 (e.g., 'L'),
+        + used more restrictive <oid> production in AttributeTypes,
+        + did not require escaping of equals sign ('=' U+003D)
+          characters,
+        + did not require escaping of non-leading number sign ('#'
+          U+0023) characters,
+        + allowed space (' ' U+0020) to be escaped as '\ ',
+        + required hex escaping of null (U+0000) characters, and
+        + removed LDAPv2-only constructs.
+      - Updated Section 3 to describe how to parse elements of the
+        grammar.
+      - Rewrote examples.
+      - Added reference to documentations containing general LDAP
+        security considerations.
+      - Added discussion of presentation issues (Appendix A).
+      - Added this appendix.
+
+   In addition, numerous editorial changes were made.
+
+Editor's Address
+
+   Kurt D.  Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 14]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 15]
+

Added: websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4515.txt
==============================================================================
--- websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4515.txt (added)
+++ websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4515.txt Wed Jan 23 08:22:07 2013
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                      M. Smith, Ed.
+Request for Comments: 4515                           Pearl Crescent, LLC
+Obsoletes: 2254                                                 T. Howes
+Category: Standards Track                                  Opsware, Inc.
+                                                               June 2006
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                String Representation of Search Filters
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Lightweight Directory Access Protocol (LDAP) search filters are
+   transmitted in the LDAP protocol using a binary representation that
+   is appropriate for use on the network.  This document defines a
+   human-readable string representation of LDAP search filters that is
+   appropriate for use in LDAP URLs (RFC 4516) and in other
+   applications.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. LDAP Search Filter Definition ...................................2
+   3. String Search Filter Definition .................................3
+   4. Examples ........................................................5
+   5. Security Considerations .........................................7
+   6. Normative References ............................................7
+   7. Informative References ..........................................8
+   8. Acknowledgements ................................................8
+   Appendix A: Changes Since RFC 2254 .................................9
+      A.1. Technical Changes ..........................................9
+      A.2. Editorial Changes ..........................................9
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 1]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+1.  Introduction
+
+   The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a
+   network representation of a search filter transmitted to an LDAP
+   server.  Some applications may find it useful to have a common way of
+   representing these search filters in a human-readable form; LDAP URLs
+   [RFC4516] are an example of one such application.  This document
+   defines a human-readable string format for representing the full
+   range of possible LDAP version 3 search filters, including extended
+   match filters.
+
+   This document is a integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+   This document replaces RFC 2254.  Changes to RFC 2254 are summarized
+   in Appendix A.
+
+   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 BCP 14 [RFC2119].
+
+2.  LDAP Search Filter Definition
+
+   An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
+   follows:
+
+        Filter ::= CHOICE {
+            and                [0] SET SIZE (1..MAX) OF filter Filter,
+            or                 [1] SET SIZE (1..MAX) OF filter Filter,
+            not                [2] Filter,
+            equalityMatch      [3] AttributeValueAssertion,
+            substrings         [4] SubstringFilter,
+            greaterOrEqual     [5] AttributeValueAssertion,
+            lessOrEqual        [6] AttributeValueAssertion,
+            present            [7] AttributeDescription,
+            approxMatch        [8] AttributeValueAssertion,
+            extensibleMatch    [9] MatchingRuleAssertion }
+
+        SubstringFilter ::= SEQUENCE {
+            type    AttributeDescription,
+            -- initial and final can occur at most once
+            substrings    SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+             initial        [0] AssertionValue,
+             any            [1] AssertionValue,
+             final          [2] AssertionValue } }
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 2]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+        AttributeValueAssertion ::= SEQUENCE {
+            attributeDesc   AttributeDescription,
+            assertionValue  AssertionValue }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+            matchingRule    [1] MatchingRuleId OPTIONAL,
+            type            [2] AttributeDescription OPTIONAL,
+            matchValue      [3] AssertionValue,
+            dnAttributes    [4] BOOLEAN DEFAULT FALSE }
+
+        AttributeDescription ::= LDAPString
+                        -- Constrained to <attributedescription>
+                        -- [RFC4512]
+
+        AttributeValue ::= OCTET STRING
+
+        MatchingRuleId ::= LDAPString
+
+        AssertionValue ::= OCTET STRING
+
+        LDAPString ::= OCTET STRING -- UTF-8 encoded,
+                                    -- [Unicode] characters
+
+   The AttributeDescription, as defined in [RFC4511], is a string
+   representation of the attribute description that is discussed in
+   [RFC4512].  The AttributeValue and AssertionValue OCTET STRING have
+   the form defined in [RFC4517].  The Filter is encoded for
+   transmission over a network using the Basic Encoding Rules (BER)
+   defined in [X.690], with simplifications described in [RFC4511].
+
+3.  String Search Filter Definition
+
+   The string representation of an LDAP search filter is a string of
+   UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
+   by the following grammar, following the ABNF notation defined in
+   [RFC4234].  The productions used that are not defined here are
+   defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless
+   otherwise noted.  The filter format uses a prefix notation.
+
+      filter         = LPAREN filtercomp RPAREN
+      filtercomp     = and / or / not / item
+      and            = AMPERSAND filterlist
+      or             = VERTBAR filterlist
+      not            = EXCLAMATION filter
+      filterlist     = 1*filter
+      item           = simple / present / substring / extensible
+      simple         = attr filtertype assertionvalue
+      filtertype     = equal / approx / greaterorequal / lessorequal
+
+
+
+Smith and Howes             Standards Track                     [Page 3]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+      equal          = EQUALS
+      approx         = TILDE EQUALS
+      greaterorequal = RANGLE EQUALS
+      lessorequal    = LANGLE EQUALS
+      extensible     = ( attr [dnattrs]
+                           [matchingrule] COLON EQUALS assertionvalue )
+                       / ( [dnattrs]
+                            matchingrule COLON EQUALS assertionvalue )
+      present        = attr EQUALS ASTERISK
+      substring      = attr EQUALS [initial] any [final]
+      initial        = assertionvalue
+      any            = ASTERISK *(assertionvalue ASTERISK)
+      final          = assertionvalue
+      attr           = attributedescription
+                         ; The attributedescription rule is defined in
+                         ; Section 2.5 of [RFC4512].
+      dnattrs        = COLON "dn"
+      matchingrule   = COLON oid
+      assertionvalue = valueencoding
+      ; The <valueencoding> rule is used to encode an <AssertionValue>
+      ; from Section 4.1.6 of [RFC4511].
+      valueencoding  = 0*(normal / escaped)
+      normal         = UTF1SUBSET / UTFMB
+      escaped        = ESC HEX HEX
+      UTF1SUBSET     = %x01-27 / %x2B-5B / %x5D-7F
+                          ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
+                          ; RPAREN, ASTERISK, and ESC.
+      EXCLAMATION    = %x21 ; exclamation mark ("!")
+      AMPERSAND      = %x26 ; ampersand (or AND symbol) ("&")
+      ASTERISK       = %x2A ; asterisk ("*")
+      COLON          = %x3A ; colon (":")
+      VERTBAR        = %x7C ; vertical bar (or pipe) ("|")
+      TILDE          = %x7E ; tilde ("~")
+
+   Note that although both the <substring> and <present> productions in
+   the grammar above can produce the "attr=*" construct, this construct
+   is used only to denote a presence filter.
+
+   The <valueencoding> rule ensures that the entire filter string is a
+   valid UTF-8 string and provides that the octets that represent the
+   ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
+   0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
+   backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
+   representing the value of the encoded octet.
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 4]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+   This simple escaping mechanism eliminates filter-parsing ambiguities
+   and allows any filter that can be represented in LDAP to be
+   represented as a NUL-terminated string.  Other octets that are part
+   of the <normal> set may be escaped using this mechanism, for example,
+   non-printing ASCII characters.
+
+   For AssertionValues that contain UTF-8 character data, each octet of
+   the character to be escaped is replaced by a backslash and two hex
+   digits, which form a single octet in the code of the character.  For
+   example, the filter checking whether the "cn" attribute contained a
+   value with the character "*" anywhere in it would be represented as
+   "(cn=*\2a*)".
+
+   As indicated by the <valueencoding> rule, implementations MUST escape
+   all octets greater than 0x7F that are not part of a valid UTF-8
+   encoding sequence when they generate a string representation of a
+   search filter.  Implementations SHOULD accept as input strings that
+   are not valid UTF-8 strings.  This is necessary because RFC 2254 did
+   not clearly define the term "string representation" (and in
+   particular did not mention that the string representation of an LDAP
+   search filter is a string of UTF-8-encoded Unicode characters).
+
+4.  Examples
+
+   This section gives a few examples of search filters written using
+   this notation.
+
+        (cn=Babs Jensen)
+        (!(cn=Tim Howes))
+        (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+        (o=univ*of*mich*)
+        (seeAlso=)
+
+   The following examples illustrate the use of extensible matching.
+
+        (cn:caseExactMatch:=Fred Flintstone)
+        (cn:=Betty Rubble)
+        (sn:dn:2.4.6.8.10:=Barney Rubble)
+        (o:dn:=Ace Industry)
+        (:1.2.3:=Wilma Flintstone)
+        (:DN:2.4.6.8.10:=Dino)
+
+   The first example shows use of the matching rule "caseExactMatch."
+
+   The second example demonstrates use of a MatchingRuleAssertion form
+   without a matchingRule.
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 5]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+   The third example illustrates the use of the ":oid" notation to
+   indicate that the matching rule identified by the OID "2.4.6.8.10"
+   should be used when making comparisons, and that the attributes of an
+   entry's distinguished name should be considered part of the entry
+   when evaluating the match (indicated by the use of ":dn").
+
+   The fourth example denotes an equality match, except that DN
+   components should be considered part of the entry when doing the
+   match.
+
+   The fifth example is a filter that should be applied to any attribute
+   supporting the matching rule given (since the <attr> has been
+   omitted).
+
+   The sixth and final example is also a filter that should be applied
+   to any attribute supporting the matching rule given.  Attributes
+   supporting the matching rule contained in the DN should also be
+   considered.
+
+   The following examples illustrate the use of the escaping mechanism.
+
+        (o=Parens R Us \28for all your parenthetical needs\29)
+        (cn=*\2A*)
+        (filename=C:\5cMyFile)
+        (bin=\00\00\00\04)
+        (sn=Lu\c4\8di\c4\87)
+        (1.3.6.1.4.1.1466.0=\04\02\48\69)
+
+   The first example shows the use of the escaping mechanism to
+   represent parenthesis characters.  The second shows how to represent
+   a "*" in an assertion value, preventing it from being interpreted as
+   a substring indicator.  The third illustrates the escaping of the
+   backslash character.
+
+   The fourth example shows a filter searching for the four-octet value
+   00 00 00 04 (hex), illustrating the use of the escaping mechanism to
+   represent arbitrary data, including NUL characters.
+
+   The fifth example illustrates the use of the escaping mechanism to
+   represent various non-ASCII UTF-8 characters.  Specifically, there
+   are 5 characters in the <assertionvalue> portion of this example:
+   LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN
+   SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069),
+   and LATIN SMALL LETTER C WITH ACUTE (U+0107).
+
+   The sixth and final example demonstrates assertion of a BER-encoded
+   value.
+
+
+
+
+Smith and Howes             Standards Track                     [Page 6]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+5.  Security Considerations
+
+   This memo describes a string representation of LDAP search filters.
+   While the representation itself has no known security implications,
+   LDAP search filters do.  They are interpreted by LDAP servers to
+   select entries from which data is retrieved.  LDAP servers should
+   take care to protect the data they maintain from unauthorized access.
+
+   Please refer to the Security Considerations sections of [RFC4511] and
+   [RFC4513] for more information.
+
+6.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+               (LDAP): Technical Specification Road Map", RFC 4510, June
+               2006.
+
+   [RFC4511]   Sermersheim, J., Ed., "Lightweight Directory Access
+               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]   Zeilenga, K., "Lightweight Directory Access Protocol
+               (LDAP): Directory Information Models", RFC 4512, June
+               2006.
+
+   [RFC4513]   Harrison, R., Ed., "Lightweight Directory Access Protocol
+               (LDAP): Authentication Methods and Security Mechanisms",
+               RFC 4513, June 2006.
+
+   [RFC4517]   Legg, S., Ed., "Lightweight Directory Access Protocol
+               (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+               2006.
+
+   [Unicode]   The Unicode Consortium, "The Unicode Standard, Version
+               3.2.0" is defined by "The Unicode Standard, Version 3.0"
+               (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+               as amended by the "Unicode Standard Annex #27: Unicode
+               3.1" (http://www.unicode.org/reports/tr27/) and by the
+               "Unicode Standard Annex #28: Unicode 3.2."
+
+
+
+
+Smith and Howes             Standards Track                     [Page 7]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+7.  Informative References
+
+   [RFC4516]   Smith, M., Ed. and T. Howes, "Lightweight Directory
+               Access Protocol (LDAP): Uniform Resource Locator", RFC
+               4516, June 2006.
+
+   [X.690]     Specification of ASN.1 encoding rules: Basic, Canonical,
+               and Distinguished Encoding Rules, ITU-T Recommendation
+               X.690, 1994.
+
+8.  Acknowledgements
+
+   This document replaces RFC 2254 by Tim Howes.  RFC 2254 was a product
+   of the IETF ASID Working Group.
+
+   Changes included in this revised specification are based upon
+   discussions among the authors, discussions within the LDAP (v3)
+   Revision Working Group (ldapbis), and discussions within other IETF
+   Working Groups.  The contributions of individuals in these working
+   groups is gratefully acknowledged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 8]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+Appendix A: Changes Since RFC 2254
+
+A.1.  Technical Changes
+
+   Replaced [ISO 10646] reference with [Unicode].
+
+   The following technical changes were made to the contents of the
+   "String Search Filter Definition" section:
+
+   Added statement that the string representation is a string of UTF-8-
+   encoded Unicode characters.
+
+   Revised all of the ABNF to use common productions from [RFC4512].
+
+   Replaced the "value" rule with a new "assertionvalue" rule within the
+   "simple", "extensible", and "substring" ("initial", "any", and
+   "final") rules.  This matches a change made in [RFC4517].
+
+   Added "(" and ")" around the components of the <extensible>
+   subproductions for clarity.
+
+   Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
+   precisely reference productions from the [RFC4512] and [RFC4511]
+   documents.
+
+   "String Search Filter Definition" section: replaced "greater" and
+   "less" with "greaterorequal" and "lessorequal" to avoid confusion.
+
+   Introduced the "valueencoding" and associated "normal" and "escaped"
+   rules to reduce the dependence on descriptive text.  The "normal"
+   production restricts filter strings to valid UTF-8 sequences.
+
+   Added a statement about expected behavior in light of RFC 2254's lack
+   of a clear definition of "string representation."
+
+A.2.  Editorial Changes
+
+   Changed document title to include "LDAP:" prefix.
+
+   IESG Note: removed note about lack of satisfactory mandatory
+   authentication mechanisms.
+
+   Header and "Authors' Addresses" sections: added Mark Smith as the
+   document editor and updated affiliation and contact information.
+
+   "Table of Contents" and "Intellectual Property" sections: added.
+
+   Copyright: updated per latest IETF guidelines.
+
+
+
+Smith and Howes             Standards Track                     [Page 9]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+   "Abstract" section: separated from introductory material.
+
+   "Introduction" section: new section; separated from the Abstract.
+   Updated second paragraph to indicate that RFC 2254 is replaced by
+   this document (instead of RFC 1960).  Added reference to the
+   [RFC4510] document.
+
+   "LDAP Search Filter Definition" section: made corrections to the LDAP
+   search filter ABNF so it matches that used in [RFC4511].
+
+   Clarified the definition of 'value' (now 'assertionvalue') to take
+   into account the fact that it is not precisely an AttributeAssertion
+   from [RFC4511] Section 4.1.6 (special handling is required for some
+   characters).  Added a note that each octet of a character to be
+   escaped is replaced by a backslash and two hex digits, which
+   represent a single octet.
+
+   "Examples" section: added four additional examples: (seeAlso=),
+   (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
+   (1.3.6.1.4.1.1466.0=\04\02\48\69).  Replaced one occurrence of "a
+   value" with "an assertion value".  Corrected the description of this
+   example: (sn:dn:2.4.6.8.10:=Barney Rubble).  Replaced the numeric OID
+   in the first extensible match example with "caseExactMatch" to
+   demonstrate use of the descriptive form.  Used "DN" (uppercase) in
+   the last extensible match example to remind the reader to treat the
+   <dnattrs> production as case insensitive.  Reworded the description
+   of the fourth escaping mechanism example to avoid making assumptions
+   about byte order.  Added text to the fifth escaping mechanism example
+   to spell out what the non-ASCII characters are in Unicode terms.
+
+   "Security Considerations" section: added references to [RFC4511] and
+   [RFC4513].
+
+   "Normative References" section: renamed from "References" per new RFC
+   guidelines.  Changed from [1] style to [RFC4511] style throughout the
+   document.  Added entries for [Unicode], [RFC2119], [RFC4513],
+   [RFC4512], and [RFC4510] and updated the UTF-8 reference.  Replaced
+   RFC 822 reference with a reference to RFC 4234.
+
+   "Informative References" section: (new section) moved [X.690] to this
+   section.  Added a reference to [RFC4516].
+
+   "Acknowledgements" section: added.
+
+   "Appendix A: Changes Since RFC 2254" section: added.
+
+   Surrounded the names of all ABNF productions with "<" and ">" where
+   they are used in descriptive text.
+
+
+
+Smith and Howes             Standards Track                    [Page 10]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+   Replaced all occurrences of "LDAPv3" with "LDAP."
+
+Authors' Addresses
+
+   Mark Smith, Editor
+   Pearl Crescent, LLC
+   447 Marlpool Dr.
+   Saline, MI 48176
+   USA
+
+   Phone: +1 734 944-2856
+   EMail: mcs@pearlcrescent.com
+
+
+   Tim Howes
+   Opsware, Inc.
+   599 N. Mathilda Ave.
+   Sunnyvale, CA 94085
+   USA
+
+   Phone: +1 408 744-7509
+   EMail: howes@opsware.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                    [Page 11]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                    [Page 12]
+

Added: websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4516.txt
==============================================================================
--- websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4516.txt (added)
+++ websites/production/directory/content/studio/users-guide/ldap_browser/rfc/rfc4516.txt Wed Jan 23 08:22:07 2013
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                      M. Smith, Ed.
+Request for Comments: 4516                           Pearl Crescent, LLC
+Obsoletes: 2255                                                 T. Howes
+Category: Standards Track                                  Opsware, Inc.
+                                                               June 2006
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                        Uniform Resource Locator
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a format for a Lightweight Directory Access
+   Protocol (LDAP) Uniform Resource Locator (URL).  An LDAP URL
+   describes an LDAP search operation that is used to retrieve
+   information from an LDAP directory, or, in the context of an LDAP
+   referral or reference, an LDAP URL describes a service where an LDAP
+   operation may be progressed.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. URL Definition ..................................................2
+      2.1. Percent-Encoding ...........................................4
+   3. Defaults for Fields of the LDAP URL .............................5
+   4. Examples ........................................................6
+   5. Security Considerations .........................................8
+   6. Normative References ............................................9
+   7. Informative References .........................................10
+   8. Acknowledgements ...............................................10
+   Appendix A: Changes Since RFC 2255 ................................11
+      A.1. Technical Changes .........................................11
+      A.2. Editorial Changes .........................................11
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 1]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+1.  Introduction
+
+   LDAP is the Lightweight Directory Access Protocol [RFC4510].  This
+   document specifies the LDAP URL format for version 3 of LDAP and
+   clarifies how LDAP URLs are resolved.  This document also defines an
+   extension mechanism for LDAP URLs.  This mechanism may be used to
+   provide access to new LDAP extensions.
+
+   Note that not all the parameters of the LDAP search operation
+   described in [RFC4511] can be expressed using the format defined in
+   this document.  Note also that URLs may be used to represent
+   reference knowledge, including that for non-search operations.
+
+   This document is an integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+   This document replaces RFC 2255.  See Appendix A for a list of
+   changes relative to RFC 2255.
+
+   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 BCP 14 [RFC2119].
+
+2.  URL Definition
+
+   An LDAP URL begins with the protocol prefix "ldap" and is defined by
+   the following grammar, following the ABNF notation defined in
+   [RFC4234].
+
+      ldapurl     = scheme COLON SLASH SLASH [host [COLON port]]
+                       [SLASH dn [QUESTION [attributes]
+                       [QUESTION [scope] [QUESTION [filter]
+                       [QUESTION extensions]]]]]
+                                      ; <host> and <port> are defined
+                                      ;   in Sections 3.2.2 and 3.2.3
+                                      ;   of [RFC3986].
+                                      ; <filter> is from Section 3 of
+                                      ;   [RFC4515], subject to the
+                                      ;   provisions of the
+                                      ;   "Percent-Encoding" section
+                                      ;   below.
+
+      scheme      = "ldap"
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 2]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+      dn          = distinguishedName ; From Section 3 of [RFC4514],
+                                      ; subject to the provisions of
+                                      ; the "Percent-Encoding"
+                                      ; section below.
+
+      attributes  = attrdesc *(COMMA attrdesc)
+      attrdesc    = selector *(COMMA selector)
+      selector    = attributeSelector ; From Section 4.5.1 of
+                                      ; [RFC4511], subject to the
+                                      ; provisions of the
+                                      ; "Percent-Encoding" section
+                                      ; below.
+
+      scope       = "base" / "one" / "sub"
+      extensions  = extension *(COMMA extension)
+      extension   = [EXCLAMATION] extype [EQUALS exvalue]
+      extype      = oid               ; From section 1.4 of [RFC4512].
+
+      exvalue     = LDAPString        ; From section 4.1.2 of
+                                      ; [RFC4511], subject to the
+                                      ; provisions of the
+                                      ; "Percent-Encoding" section
+                                      ; below.
+
+      EXCLAMATION = %x21              ; exclamation mark ("!")
+      SLASH       = %x2F              ; forward slash ("/")
+      COLON       = %x3A              ; colon (":")
+      QUESTION    = %x3F              ; question mark ("?")
+
+   The "ldap" prefix indicates an entry or entries accessible from the
+   LDAP server running on the given hostname at the given portnumber.
+   Note that the <host> may contain literal IPv6 addresses as specified
+   in Section 3.2.2 of [RFC3986].
+
+   The <dn> is an LDAP Distinguished Name using the string format
+   described in [RFC4514].  It identifies the base object of the LDAP
+   search or the target of a non-search operation.
+
+   The <attributes> construct is used to indicate which attributes
+   should be returned from the entry or entries.
+
+   The <scope> construct is used to specify the scope of the search to
+   perform in the given LDAP server.  The allowable scopes are "base"
+   for a base object search, "one" for a one-level search, or "sub" for
+   a subtree search.
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 3]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   The <filter> is used to specify the search filter to apply to entries
+   within the specified scope during the search.  It has the format
+   specified in [RFC4515].
+
+   The <extensions> construct provides the LDAP URL with an
+   extensibility mechanism, allowing the capabilities of the URL to be
+   extended in the future.  Extensions are a simple comma-separated list
+   of type=value pairs, where the =value portion MAY be omitted for
+   options not requiring it.  Each type=value pair is a separate
+   extension.  These LDAP URL extensions are not necessarily related to
+   any of the LDAP extension mechanisms.  Extensions may be supported or
+   unsupported by the client resolving the URL.  An extension prefixed
+   with a '!' character (ASCII 0x21) is critical.  An extension not
+   prefixed with a '!' character is non-critical.
+
+   If an LDAP URL extension is implemented (that is, if the
+   implementation understands it and is able to use it), the
+   implementation MUST make use of it.  If an extension is not
+   implemented and is marked critical, the implementation MUST NOT
+   process the URL.  If an extension is not implemented and is not
+   marked critical, the implementation MUST ignore the extension.
+
+   The extension type (<extype>) MAY be specified using the numeric OID
+   <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
+   (e.g., myLDAPURLExtension).  Use of the <descr> form SHOULD be
+   restricted to registered object identifier descriptive names.  See
+   [RFC4520] for registration details and usage guidelines for
+   descriptive names.
+
+   No LDAP URL extensions are defined in this document.  Other documents
+   or a future version of this document MAY define one or more
+   extensions.
+
+2.1.  Percent-Encoding
+
+   A generated LDAP URL MUST consist only of the restricted set of
+   characters included in one of the following three productions defined
+   in [RFC3986]:
+
+         <reserved>
+         <unreserved>
+         <pct-encoded>
+
+   Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
+   input.  An octet MUST be encoded using the percent-encoding mechanism
+   described in section 2.1 of [RFC3986] in any of these situations:
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 4]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+      The octet is not in the reserved set defined in section 2.2 of
+      [RFC3986] or in the unreserved set defined in section 2.3 of
+      [RFC3986].
+
+      It is the single Reserved character '?' and occurs inside a <dn>,
+      <filter>, or other element of an LDAP URL.
+
+      It is a comma character ',' that occurs inside an <exvalue>.
+
+   Note that before the percent-encoding mechanism is applied, the
+   extensions component of the LDAP URL may contain one or more null
+   (zero) bytes.  No other component may.
+
+3.  Defaults for Fields of the LDAP URL
+
+   Some fields of the LDAP URL are optional, as described above.  In the
+   absence of any other specification, the following general defaults
+   SHOULD be used when a field is absent.  Note that other documents MAY
+   specify different defaulting rules; for example, section 4.1.10 of
+   [RFC4511] specifies a different rule for determining the correct DN
+   to use when it is absent in an LDAP URL that is returned as a
+   referral.
+
+   <host>
+      If no <host> is given, the client must have some a priori
+      knowledge of an appropriate LDAP server to contact.
+
+   <port>
+      The default LDAP port is TCP port 389.
+
+   <dn>
+      If no <dn> is given, the default is the zero-length DN, "".
+
+   <attributes>
+      If the <attributes> part is omitted, all user attributes of the
+      entry or entries should be requested (e.g., by setting the
+      attributes field AttributeDescriptionList in the LDAP search
+      request to a NULL list, or by using the special <alluserattrs>
+      selector "*").
+
+   <scope>
+      If <scope> is omitted, a <scope> of "base" is assumed.
+
+   <filter>
+      If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
+
+   <extensions>
+      If <extensions> is omitted, no extensions are assumed.
+
+
+
+Smith & Howes               Standards Track                     [Page 5]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+4.  Examples
+
+   The following are some example LDAP URLs that use the format defined
+   above.  The first example is an LDAP URL referring to the University
+   of Michigan entry, available from an LDAP server of the client's
+   choosing:
+
+      ldap:///o=University%20of%20Michigan,c=US
+
+   The next example is an LDAP URL referring to the University of
+   Michigan entry in a particular ldap server:
+
+      ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
+
+   Both of these URLs correspond to a base object search of the
+   "o=University of Michigan,c=US" entry using a filter of
+   "(objectclass=*)", requesting all attributes.
+
+   The next example is an LDAP URL referring to only the postalAddress
+   attribute of the University of Michigan entry:
+
+      ldap://ldap1.example.net/o=University%20of%20Michigan,
+             c=US?postalAddress
+
+   The corresponding LDAP search operation is the same as in the
+   previous example, except that only the postalAddress attribute is
+   requested.
+
+   The next example is an LDAP URL referring to the set of entries found
+   by querying the given LDAP server on port 6666 and doing a subtree
+   search of the University of Michigan for any entry with a common name
+   of "Babs Jensen", retrieving all attributes:
+
+      ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
+             c=US??sub?(cn=Babs%20Jensen)
+
+   The next example is an LDAP URL referring to all children of the c=GB
+   entry:
+
+      LDAP://ldap1.example.com/c=GB?objectClass?ONE
+
+   The objectClass attribute is requested to be returned along with the
+   entries, and the default filter of "(objectclass=*)" is used.
+
+   The next example is an LDAP URL to retrieve the mail attribute for
+   the LDAP entry named "o=Question?,c=US", illustrating the use of the
+   percent-encoding mechanism on the reserved character '?'.
+
+
+
+
+Smith & Howes               Standards Track                     [Page 6]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+      ldap://ldap2.example.com/o=Question%3f,c=US?mail
+
+   The next example (which is broken into two lines for readability)
+   illustrates the interaction between the LDAP string representation of
+   the filters-quoting mechanism and the URL-quoting mechanisms.
+
+      ldap://ldap3.example.com/o=Babsco,c=US
+              ???(four-octet=%5c00%5c00%5c00%5c04)
+
+   The filter in this example uses the LDAP escaping mechanism of \ to
+   encode three zero or null bytes in the value.  In LDAP, the filter
+   would be written as (four-octet=\00\00\00\04).  Because the \
+   character must be escaped in a URL, the \s are percent-encoded as %5c
+   (or %5C) in the URL encoding.
+
+   The next example illustrates the interaction between the LDAP string
+   representation of the DNs-quoting mechanism and URL-quoting
+   mechanisms.
+
+      ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
+
+   The DN encoded in the above URL is:
+
+      o=An Example\2C Inc.,c=US
+
+   That is, the left-most RDN value is:
+
+      An Example, Inc.
+
+   The following three URLs are equivalent, assuming that the defaulting
+   rules specified in Section 3 of this document are used:
+
+      ldap://ldap.example.net
+      ldap://ldap.example.net/
+      ldap://ldap.example.net/?
+
+   These three URLs point to the root DSE on the ldap.example.net
+   server.
+
+   The final two examples show use of a hypothetical, experimental bind
+   name extension (the value associated with the extension is an LDAP
+   DN).
+
+      ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
+      ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 7]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   The two URLs are the same, except that the second one marks the
+   e-bindname extension as critical.  Notice the use of the percent-
+   encoding mechanism to encode the commas within the distinguished name
+   value in the e-bindname extension.
+
+5.  Security Considerations
+
+   The general URL security considerations discussed in [RFC3986] are
+   relevant for LDAP URLs.
+
+   The use of security mechanisms when processing LDAP URLs requires
+   particular care, since clients may encounter many different servers
+   via URLs, and since URLs are likely to be processed automatically,
+   without user intervention.  A client SHOULD have a user-configurable
+   policy that controls which servers the client will establish LDAP
+   sessions with and with which security mechanisms, and SHOULD NOT
+   establish LDAP sessions that are inconsistent with this policy.  If a
+   client chooses to reuse an existing LDAP session when resolving one
+   or more LDAP URLs, it MUST ensure that the session is compatible with
+   the URL and that no security policies are violated.
+
+   Sending authentication information, no matter the mechanism, may
+   violate a user's privacy requirements.  In the absence of specific
+   policy permitting authentication information to be sent to a server,
+   a client should use an anonymous LDAP session.  (Note that clients
+   conforming to previous LDAP URL specifications, where all LDAP
+   sessions are anonymous and unprotected, are consistent with this
+   specification; they simply have the default security policy.)  Simply
+   opening a transport connection to another server may violate some
+   users' privacy requirements, so clients should provide the user with
+   a way to control URL processing.
+
+   Some authentication methods, in particular, reusable passwords sent
+   to the server, may reveal easily-abused information to the remote
+   server or to eavesdroppers in transit and should not be used in URL
+   processing unless they are explicitly permitted by policy.
+   Confirmation by the human user of the use of authentication
+   information is appropriate in many circumstances.  Use of strong
+   authentication methods that do not reveal sensitive information is
+   much preferred.  If the URL represents a referral for an update
+   operation, strong authentication methods SHOULD be used.  Please
+   refer to the Security Considerations section of [RFC4513] for more
+   information.
+
+   The LDAP URL format allows the specification of an arbitrary LDAP
+   search operation to be performed when evaluating the LDAP URL.
+   Following an LDAP URL may cause unexpected results, for example, the
+   retrieval of large amounts of data or the initiation of a long-lived
+
+
+
+Smith & Howes               Standards Track                     [Page 8]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   search.  The security implications of resolving an LDAP URL are the
+   same as those of resolving an LDAP search query.
+
+6.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005.
+
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510, June
+              2006.
+
+   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
+              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Authentication Methods and Security Mechanisms",
+              RFC 4513, June 2006.
+
+   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): String Representation of Distinguished Names", RFC
+              4514, June 2006.
+
+   [RFC4515]  Smith, M. Ed. and T. Howes, "Lightweight Directory Access
+              Protocol (LDAP): String Representation of Search Filters",
+              RFC 4515, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 9]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+7.  Informative References
+
+   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifiers (URI): Generic Syntax", RFC 2396,
+              August 1998.
+
+   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+              Considerations for the Lightweight Directory Access
+              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+8.  Acknowledgements
+
+   The LDAP URL format was originally defined at the University of
+   Michigan.  This material is based upon work supported by the National
+   Science Foundation under Grant No. NCR-9416667.  The support of both
+   the University of Michigan and the National Science Foundation is
+   gratefully acknowledged.
+
+   This document obsoletes RFC 2255 by Tim Howes and Mark Smith.
+   Changes included in this revised specification are based upon
+   discussions among the authors, discussions within the LDAP (v3)
+   Revision Working Group (ldapbis), and discussions within other IETF
+   Working Groups.  The contributions of individuals in these working
+   groups is gratefully acknowledged.  Several people in particular have
+   made valuable comments on this document: RL "Bob" Morgan, Mark Wahl,
+   Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
+   thanks for their contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                    [Page 10]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+Appendix A: Changes Since RFC 2255
+
+A.1.  Technical Changes
+
+   The following technical changes were made to the contents of the "URL
+   Definition" section:
+
+   Revised all of the ABNF to use common productions from [RFC4512].
+
+   Replaced references to [RFC2396] with a reference to [RFC3986] (this
+   allows literal IPv6 addresses to be used inside the <host> portion of
+   the URL, and a note was added to remind the reader of this
+   enhancement).  Referencing [RFC3986] required changes to the ABNF and
+   text so that productions that are no longer defined by [RFC3986] are
+   not used.  For example, <hostport> is not defined by [RFC3986] so it
+   has been replaced with host [COLON port].  Note that [RFC3986]
+   includes new definitions for the "Reserved" and "Unreserved" sets of
+   characters, and the net result is that the following two additional
+   characters should be percent-encoded when they appear anywhere in the
+   data used to construct an LDAP URL: "[" and "]" (these two characters
+   were first added to the Reserved set by RFC 2732).
+
+   Changed the definition of <attrdesc> to refer to <attributeSelector>
+   from [RFC4511].  This allows the use of "*" in the <attrdesc> part of
+   the URL.  It is believed that existing implementations of RFC 2255
+   already support this.
+
+   Avoided use of <prose-val> (bracketed-string) productions in the
+   <dn>, <host>, <attrdesc>, and <exvalue> rules.
+
+   Changed the ABNF for <ldapurl> to group the <dn> component with the
+   preceding <SLASH>.
+
+   Changed the <extype> rule to be an <oid> from [RFC4512].
+
+   Changed the text about extension types so it references [RFC4520].
+   Reordered rules to more closely follow the order in which the
+   elements appear in the URL.
+
+   "Bindname Extension": removed due to lack of known implementations.
+
+A.2.  Editorial Changes
+
+   Changed document title to include "LDAP:" prefix.
+
+   IESG Note: removed note about lack of satisfactory mandatory
+   authentication mechanisms.
+
+
+
+
+Smith & Howes               Standards Track                    [Page 11]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   "Status of this Memo" section: updated boilerplate to match current
+   I-D guidelines.
+
+   "Abstract" section: separated from introductory material.
+
+   "Table of Contents" and "Intellectual Property" sections: added.
+
+   "Introduction" section: new section; separated from the Abstract.
+   Changed the text indicate that RFC 2255 is replaced by this document
+   (instead of RFC 1959).  Added text to indicate that LDAP URLs are
+   used for references and referrals.  Fixed typo (replaced the nonsense
+   phrase "to perform to retrieve" with "used to retrieve").  Added a
+   note to let the reader know that not all of the parameters of the
+   LDAP search operation described in [RFC4511] can be expressed using
+   this format.
+
+   "URL Definition" section: removed second copy of <ldapurl> grammar
+   and following two paragraphs (editorial error in RFC 2255).  Fixed
+   line break within '!' sequence.  Reformatted the ABNF to improve
+   readability by aligning comments and adding some blank lines.
+   Replaced "residing in the LDAP server" with "accessible from the LDAP
+   server" in the sentence immediately following the ABNF.  Removed the
+   sentence "Individual attrdesc names are as defined for
+   AttributeDescription in [RFC4511]."  because [RFC4511]'s
+   <attributeSelector> is now used directly in the ABNF.  Reworded last
+   paragraph to clarify which characters must be percent-encoded.  Added
+   text to indicate that LDAP URLs are used for references and
+   referrals.  Added text that refers to the ABNF from RFC 4234.
+   Clarified and strengthened the requirements with respect to
+   processing of URLs that contain implemented and not implemented
+   extensions (the approach now closely matches that specified in
+   [RFC4511] for LDAP controls).
+
+   "Defaults for Fields of the LDAP URL" section: added; formed by
+   moving text about defaults out of the "URL Definition" section.
+   Replaced direct reference to the attribute name "*" with a reference
+   to the special <alluserattrs> selector "*" defined in [RFC4511].
+
+   "URL Processing" section: removed.
+
+   "Examples" section: Modified examples to use example.com and
+   example.net hostnames.  Added missing '?' to the LDAP URL example
+   whose filter contains three null bytes.  Removed space after one
+   comma within a DN.  Revised the bindname example to use e-bindname.
+   Changed the name of an attribute used in one example from "int" to
+   "four-octet" to avoid potential confusion.  Added an example that
+   demonstrates the interaction between DN escaping and URL percent-
+   encoding.  Added some examples to show URL equivalence with respect
+
+
+
+Smith & Howes               Standards Track                    [Page 12]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   to the <dn> portion of the URL.  Used uppercase in some examples to
+   remind the reader that some tokens are case-insensitive.
+
+   "Security Considerations" section: Added a note about connection
+   reuse.  Added a note about using strong authentication methods for
+   updates.  Added a reference to [RFC4513].  Added note that simply
+   opening a connection may violate some users' privacy requirements.
+   Adopted the working group's revised LDAP terminology specification by
+   replacing the word "connection" with "LDAP session" or "LDAP
+   connection" as appropriate.
+
+   "Acknowledgements" section: added statement that this document
+   obsoletes RFC 2255.  Added Kurt Zeilenga, Jim Sermersheim, and
+   Hallvard Furuseth.
+
+   "Normative References" section: renamed from "References" per new RFC
+   guidelines.  Changed from [1] style to [RFC4511] style throughout the
+   document.  Added references to RFC 4234 and RFC 3629.  Updated all
+   RFC 1738 references to point to the appropriate sections within
+   [RFC3986].  Updated the LDAP references to refer to LDAPBis WG
+   documents.  Removed the reference to the LDAP Attribute Syntaxes
+   document and added references to the [RFC4513], [RFC4520], and
+   [RFC4510] documents.
+
+   "Informative References" section: added.
+
+   Header and "Authors' Addresses" sections: added "editor" next to Mark
+   Smith's name.  Updated affiliation and contact information.
+
+   Copyright: updated the year.
+
+   Throughout the document: surrounded the names of all ABNF productions
+   with "<" and ">" where they are used in descriptive text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                    [Page 13]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+Authors' Addresses
+
+   Mark Smith, Editor
+   Pearl Crescent, LLC
+   447 Marlpool Dr.
+   Saline, MI 48176
+   USA
+
+   Phone: +1 734 944-2856
+   EMail: mcs@pearlcrescent.com
+
+
+   Tim Howes
+   Opsware, Inc.
+   599 N. Mathilda Ave.
+   Sunnyvale, CA 94085
+   USA
+
+   Phone: +1 408 744-7509
+   EMail: howes@opsware.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                    [Page 14]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                    [Page 15]
+



Mime
View raw message