directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fel...@apache.org
Subject svn commit: r592038 [11/22] - in /directory/sandbox/felixk/studio-ldapbrowser-help: ./ META-INF/ src/ src/main/ src/main/docbook/ src/main/resources/ src/main/resources/about_files/ src/main/resources/html/ src/main/resources/html/css/ src/main/resourc...
Date Mon, 05 Nov 2007 15:17:15 GMT
Added: directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2254.txt
URL: http://svn.apache.org/viewvc/directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2254.txt?rev=592038&view=auto
==============================================================================
--- directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2254.txt (added)
+++ directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2254.txt Mon Nov  5 07:16:53 2007
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          T. Howes
+Request for Comments: 2254                Netscape Communications Corp.
+Category: Standards Track                                 December 1997
+
+
+            The String Representation of LDAP Search Filters
+
+1. 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 (1997).  All Rights Reserved.
+
+IESG Note
+
+   This document describes a directory access protocol that provides
+   both read and update access.  Update access requires secure
+   authentication, but this document does not mandate implementation of
+   any satisfactory authentication mechanisms.
+
+   In accordance with RFC 2026, section 4.4.1, this specification is
+   being approved by IESG as a Proposed Standard despite this
+   limitation, for the following reasons:
+
+   a. to encourage implementation and interoperability testing of
+      these protocols (with or without update access) before they
+      are deployed, and
+
+   b. to encourage deployment and use of these protocols in read-only
+      applications.  (e.g. applications where LDAPv3 is used as
+      a query language for directories which are updated by some
+      secure mechanism other than LDAP), and
+
+   c. to avoid delaying the advancement and deployment of other Internet
+      standards-track protocols which require the ability to query, but
+      not update, LDAPv3 directory servers.
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 1]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+   Readers are hereby warned that until mandatory authentication
+   mechanisms are standardized, clients and servers written according to
+   this specification which make use of update functionality are
+   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+   Implementors are hereby discouraged from deploying LDAPv3 clients or
+   servers which implement the update functionality, until a Proposed
+   Standard for mandatory authentication in LDAPv3 has been approved and
+   published as an RFC.
+
+2. Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) [1] 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.  This
+   document defines a human-readable string format for representing LDAP
+   search filters.
+
+   This document replaces RFC 1960, extending the string LDAP filter
+   definition to include support for LDAP version 3 extended match
+   filters, and including support for representing the full range of
+   possible LDAP search filters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 2]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+3. LDAP Search Filter Definition
+
+   An LDAPv3 search filter is defined in Section 4.5.1 of [1] as
+   follows:
+
+        Filter ::= CHOICE {
+                and                [0] SET OF Filter,
+                or                 [1] SET OF 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,
+                SEQUENCE OF CHOICE {
+                        initial        [0] LDAPString,
+                        any            [1] LDAPString,
+                        final          [2] LDAPString
+                }
+        }
+
+        AttributeValueAssertion ::= SEQUENCE {
+                attributeDesc   AttributeDescription,
+                attributeValue  AttributeValue
+        }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+                matchingRule    [1] MatchingRuleID OPTIONAL,
+                type            [2] AttributeDescription OPTIONAL,
+                matchValue      [3] AssertionValue,
+                dnAttributes    [4] BOOLEAN DEFAULT FALSE
+        }
+
+        AttributeDescription ::= LDAPString
+
+        AttributeValue ::= OCTET STRING
+
+        MatchingRuleID ::= LDAPString
+
+        AssertionValue ::= OCTET STRING
+
+        LDAPString ::= OCTET STRING
+
+
+
+Howes                       Standards Track                     [Page 3]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+   where the LDAPString above is limited to the UTF-8 encoding of the
+   ISO 10646 character set [4].  The AttributeDescription is a string
+   representation of the attribute description and is defined in [1].
+   The AttributeValue and AssertionValue OCTET STRING have the form
+   defined in [2].  The Filter is encoded for transmission over a
+   network using the Basic Encoding Rules defined in [3], with
+   simplifications described in [1].
+
+4. String Search Filter Definition
+
+   The string representation of an LDAP search filter is defined by the
+   following grammar, following the ABNF notation defined in [5].  The
+   filter format uses a prefix notation.
+
+        filter     = "(" filtercomp ")"
+        filtercomp = and / or / not / item
+        and        = "&" filterlist
+        or         = "|" filterlist
+        not        = "!" filter
+        filterlist = 1*filter
+        item       = simple / present / substring / extensible
+        simple     = attr filtertype value
+        filtertype = equal / approx / greater / less
+        equal      = "="
+        approx     = "~="
+        greater    = ">="
+        less       = "<="
+        extensible = attr [":dn"] [":" matchingrule] ":=" value
+                     / [":dn"] ":" matchingrule ":=" value
+        present    = attr "=*"
+        substring  = attr "=" [initial] any [final]
+        initial    = value
+        any        = "*" *(value "*")
+        final      = value
+        attr       = AttributeDescription from Section 4.1.5 of [1]
+        matchingrule = MatchingRuleId from Section 4.1.9 of [1]
+        value      = AttributeValue from Section 4.1.6 of [1]
+
+   The attr, matchingrule, and value constructs are as described in the
+   corresponding section of [1] given above.
+
+
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 4]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+   If a value should contain any of the following characters
+
+           Character       ASCII value
+           ---------------------------
+           *               0x2a
+           (               0x28
+           )               0x29
+           \               0x5c
+           NUL             0x00
+
+   the character must be encoded as the backslash '\' character (ASCII
+   0x5c) followed by the two hexadecimal digits representing the ASCII
+   value of the encoded character. The case of the two hexadecimal
+   digits is not significant.
+
+   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 characters besides the
+   ones listed above may be escaped using this mechanism, for example,
+   non-printing characters.
+
+   For example, the filter checking whether the "cn" attribute contained
+   a value with the character "*" anywhere in it would be represented as
+   "(cn=*\2a*)".
+
+   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.
+
+5. 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*)
+
+   The following examples illustrate the use of extensible matching.
+
+        (cn:1.2.3.4.5:=Fred Flintstone)
+        (sn:dn:2.4.6.8.10:=Barney Rubble)
+        (o:dn:=Ace Industry)
+        (:dn:2.4.6.8.10:=Dino)
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 5]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+   The second example illustrates the use of the ":dn" notation to
+   indicate that matching rule "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.
+
+   The third example denotes an equality match, except that DN
+   components should be considered part of the entry when doing the
+   match.
+
+   The fourth example is a filter that should be applied to any
+   attribute supporting the matching rule given (since the attr has been
+   left off). 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)
+
+   The first example shows the use of the escaping mechanism to
+   represent parenthesis characters. The second shows how to represent a
+   "*" in a 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-byte value
+   0x00000004, illustrating the use of the escaping mechanism to
+   represent arbitrary data, including NUL characters.
+
+   The final example illustrates the use of the escaping mechanism to
+   represent various non-ASCII UTF-8 characters.
+
+6. 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.
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 6]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+7. References
+
+   [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+   Protocol (v3)", RFC 2251, December 1997.
+
+   [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+   Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+   2252, December 1997.
+
+   [3] Specification of ASN.1 encoding rules: Basic, Canonical, and
+   Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
+
+   [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+   10646", RFC 2044, October 1996.
+
+   [5] Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", STD 11, RFC 822, August 1982.
+
+8. Author's Address
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 E. Middlefield Road
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 415 937-3419
+   EMail: howes@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 7]
+
+RFC 2254             String Representation of LDAP         December 1997
+
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes                       Standards Track                     [Page 8]
+

Propchange: directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2254.txt
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2255.txt
URL: http://svn.apache.org/viewvc/directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2255.txt?rev=592038&view=auto
==============================================================================
--- directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2255.txt (added)
+++ directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2255.txt Mon Nov  5 07:16:53 2007
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         T. Howes
+Request for Comments: 2255                                    M. Smith
+Category: Standards Track                Netscape Communications Corp.
+                                                         December 1997
+
+
+                          The LDAP URL Format
+
+1. 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 (1997).  All Rights Reserved.
+
+IESG NOTE
+
+   This document describes a directory access protocol that provides
+   both read and update access.  Update access requires secure
+   authentication, but this document does not mandate implementation of
+   any satisfactory authentication mechanisms.
+
+   In accordance with RFC 2026, section 4.4.1, this specification is
+   being approved by IESG as a Proposed Standard despite this
+   limitation, for the following reasons:
+
+   a. to encourage implementation and interoperability testing of
+      these protocols (with or without update access) before they
+      are deployed, and
+
+   b. to encourage deployment and use of these protocols in read-only
+      applications.  (e.g. applications where LDAPv3 is used as
+      a query language for directories which are updated by some
+      secure mechanism other than LDAP), and
+
+   c. to avoid delaying the advancement and deployment of other Internet
+      standards-track protocols which require the ability to query, but
+      not update, LDAPv3 directory servers.
+
+
+
+
+
+
+
+
+Howes & Smith               Standards Track                     [Page 1]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+   Readers are hereby warned that until mandatory authentication
+   mechanisms are standardized, clients and servers written according to
+   this specification which make use of update functionality are
+   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+   Implementors are hereby discouraged from deploying LDAPv3 clients or
+   servers which implement the update functionality, until a Proposed
+   Standard for mandatory authentication in LDAPv3 has been approved and
+   published as an RFC.
+
+2. Abstract
+
+   LDAP is the Lightweight Directory Access Protocol, defined in [1],
+   [2] and [3].  This document describes a format for an LDAP Uniform
+   Resource Locator.  The format describes an LDAP search operation to
+   perform to retrieve information from an LDAP directory. This document
+   replaces RFC 1959. It updates 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, so that future
+   documents can extend their functionality, for example, to provide
+   access to new LDAPv3 extensions as they are defined.
+
+   The key words "MUST", "MAY", and "SHOULD" used in this document are
+   to be interpreted as described in [6].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes & Smith               Standards Track                     [Page 2]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+3. URL Definition
+
+   An LDAP URL begins with the protocol prefix "ldap" and is defined by
+   the following grammar.
+
+       ldapurl    = scheme "://" [hostport] ["/"
+                    [dn ["?" [attributes] ["?" [scope]
+                    ["?" [filter] ["?" extensions]]]]]]
+       scheme     = "ldap"
+       attributes = attrdesc *("," attrdesc)
+       scope      = "base" / "one" / "sub"
+       dn         = distinguishedName from Section 3 of [1]
+       hostport   = hostport from Section 5 of RFC 1738 [5]
+       attrdesc   = AttributeDescription from Section 4.1.5 of [2]
+       filter     = filter from Section 4 of [4]
+       extensions = extension *("," extension)
+       extension  = ["!"] extype ["=" exvalue]
+       extype     = token / xtoken
+       exvalue    = LDAPString from section 4.1.2 of [2]
+       token      = oid from section 4.1 of [3]
+       xtoken     = ("X-" / "x-") token
+
+   The "ldap" prefix indicates an entry or entries residing in the LDAP
+   server running on the given hostname at the given portnumber. The
+   default LDAP port is TCP port 389. If no hostport is given, the
+   client must have some apriori knowledge of an appropriate LDAP server
+   to contact.
+
+   The dn is an LDAP Distinguished Name using the string format
+   described in [1]. It identifies the base object of the LDAP search.
+
+   ldapurl    = scheme "://" [hostport] ["/"
+                    [dn ["?" [attributes] ["?" [scope]
+                    ["?" [filter] ["?" extensions]]]]]]
+       scheme     = "ldap"
+       attributes = attrdesc *("," attrdesc)
+       scope      = "base" / "one" / "sub"
+       dn         = distinguishedName from Section 3 of [1]
+       hostport   = hostport from Section 5 of RFC 1738 [5]
+       attrdesc   = AttributeDescription from Section 4.1.5 of [2]
+       filter     = filter from Section 4 of [4]
+       extensions = extension *("," extension)
+       extension  = ["!"] extype ["=" exvalue]
+       extype     = token / xtoken
+       exvalue    = LDAPString from section 4.1.2 of [2]
+       token      = oid from section 4.1 of [3]
+       xtoken     = ("X-" / "x-") token
+
+
+
+
+Howes & Smith               Standards Track                     [Page 3]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+   The "ldap" prefix indicates an entry or entries residing in the LDAP
+   server running on the given hostname at the given portnumber. The
+   default LDAP port is TCP port 389. If no hostport is given, the
+   client must have some apriori knowledge of an appropriate LDAP server
+   to contact.
+
+   The dn is an LDAP Distinguished Name using the string format
+   described in [1]. It identifies the base object of the LDAP search.
+
+   The attributes construct is used to indicate which attributes should
+   be returned from the entry or entries.  Individual attrdesc names are
+   as defined for AttributeDescription in [2].  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 (in LDAPv3) by requesting the special attribute name "*").
+
+   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.  If scope is omitted, a scope of "base" is assumed.
+
+   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 [4].  If filter is omitted, a filter of
+   "(objectClass=*)" is assumed.
+
+   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 LDAPv3
+   extension mechanisms. Extensions may be supported or unsupported by
+   the client resolving the URL. An extension prefixed with a '!'
+   character (ASCII 33) is critical. An extension not prefixed with a '
+   !'  character is non-critical.
+
+   If an extension is supported by the client, the client MUST obey the
+   extension if the extension is critical. The client SHOULD obey
+   supported extensions that are non-critical.
+
+   If an extension is unsupported by the client, the client MUST NOT
+   process the URL if the extension is critical.  If an unsupported
+   extension is non-critical, the client MUST ignore the extension.
+
+
+
+
+
+
+Howes & Smith               Standards Track                     [Page 4]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+   If a critical extension cannot be processed successfully by the
+   client, the client MUST NOT process the URL. If a non-critical
+   extension cannot be processed successfully by the client, the client
+   SHOULD ignore the extension.
+
+   Extension types prefixed by "X-" or "x-" are reserved for use in
+   bilateral agreements between communicating parties. Other extension
+   types MUST be defined in this document, or in other standards-track
+   documents.
+
+   One LDAP URL extension is defined in this document in the next
+   section.  Other documents or a future version of this document MAY
+   define other extensions.
+
+   Note that any URL-illegal characters (e.g., spaces), URL special
+   characters (as defined in section 2.2 of RFC 1738) and the reserved
+   character '?' (ASCII 63) occurring inside a dn, filter, or other
+   element of an LDAP URL MUST be escaped using the % method described
+   in RFC 1738 [5]. If a comma character ',' occurs inside an extension
+   value, the character MUST also be escaped using the % method.
+
+4. The Bindname Extension
+
+   This section defines an LDAP URL extension for representing the
+   distinguished name for a client to use when authenticating to an LDAP
+   directory during resolution of an LDAP URL. Clients MAY implement
+   this extension.
+
+   The extension type is "bindname". The extension value is the
+   distinguished name of the directory entry to authenticate as, in the
+   same form as described for dn in the grammar above. The dn may be the
+   NULL string to specify unauthenticated access. The extension may be
+   either critical (prefixed with a '!' character) or non-critical (not
+   prefixed with a '!' character).
+
+   If the bindname extension is critical, the client resolving the URL
+   MUST authenticate to the directory using the given distinguished name
+   and an appropriate authentication method. Note that for a NULL
+   distinguished name, no bind MAY be required to obtain anonymous
+   access to the directory. If the extension is non-critical, the client
+   MAY bind to the directory using the given distinguished name.
+
+5. URL Processing
+
+   This section describes how an LDAP URL SHOULD be resolved by a
+   client.
+
+
+
+
+
+Howes & Smith               Standards Track                     [Page 5]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+   First, the client obtains a connection to the LDAP server referenced
+   in the URL, or an LDAP server of the client's choice if no LDAP
+   server is explicitly referenced.  This connection MAY be opened
+   specifically for the purpose of resolving the URL or the client MAY
+   reuse an already open connection. The connection MAY provide
+   confidentiality, integrity, or other services, e.g., using TLS. Use
+   of security services is at the client's discretion if not specified
+   in the URL.
+
+   Next, the client authenticates itself to the LDAP server.  This step
+   is optional, unless the URL contains a critical bindname extension
+   with a non-NULL value. If a bindname extension is given, the client
+   proceeds according to the section above.
+
+   If a bindname extension is not specified, the client MAY bind to the
+   directory using a appropriate dn and authentication method of its own
+   choosing (including NULL authentication).
+
+   Next, the client performs the LDAP search operation specified in the
+   URL. Additional fields in the LDAP protocol search request, such as
+   sizelimit, timelimit, deref, and anything else not specified or
+   defaulted in the URL specification, MAY be set at the client's
+   discretion.
+
+   Once the search has completed, the client MAY close the connection to
+   the LDAP server, or the client MAY keep the connection open for
+   future use.
+
+6. Examples
+
+   The following are some example LDAP URLs using 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://ldap.itd.umich.edu/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:
+
+
+
+Howes & Smith               Standards Track                     [Page 6]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+     ldap://ldap.itd.umich.edu/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://host.com: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://ldap.itd.umich.edu/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" is given below, illustrating
+   the use of the escaping mechanism on the reserved character '?'.
+
+     ldap://ldap.question.com/o=Question%3f,c=US?mail
+
+   The next example illustrates the interaction between LDAP and URL
+   quoting mechanisms.
+
+     ldap://ldap.netscape.com/o=Babsco,c=US??(int=%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 (int=\00\00\00\04). Because the \ character must
+   be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
+
+   The final example shows the use of the bindname extension to specify
+   the dn a client should use for authentication when resolving the URL.
+
+     ldap:///??sub??bindname=cn=Manager%2co=Foo
+     ldap:///??sub??!bindname=cn=Manager%2co=Foo
+
+   The two URLs are the same, except that the second one marks the
+   bindname extension as critical. Notice the use of the % encoding
+   method to encode the comma in the distinguished name value in the
+
+
+
+Howes & Smith               Standards Track                     [Page 7]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+   bindname extension.
+
+7. Security Considerations
+
+   General URL security considerations discussed in [5] 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 about which servers to connect to using which security
+   mechanisms, and SHOULD NOT make connections that are inconsistent
+   with this policy.
+
+   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 connection.  (Note that clients
+   conforming to previous LDAP URL specifications, where all connections
+   are anonymous and unprotected, are consistent with this
+   specification; they simply have the default security policy.)
+
+   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 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.
+
+   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, the initiation of a long-lived
+   search, etc.  The security implications of resolving an LDAP URL are
+   the same as those of resolving an LDAP search query.
+
+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.
+
+
+
+
+
+
+Howes & Smith               Standards Track                     [Page 8]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+   Several people have made valuable comments on this document.  In
+   particular RL "Bob" Morgan and Mark Wahl deserve special thanks for
+   their contributions.
+
+9. References
+
+   [1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
+   Protocol (v3): UTF-8 String Representation of Distinguished Names",
+   RFC 2253, December 1997.
+
+   [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+   Protocol (v3)", RFC 2251, December 1997.
+
+   [3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+   Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+   2252, December 1997.
+
+   [4] Howes, T., "A String Representation of LDAP Search Filters", RFC
+   2254, December 1997.
+
+   [5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+   Locators (URL)," RFC 1738, December 1994.
+
+   [6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+   Levels," RFC 2119, March 1997.
+
+Authors' Addresses
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 E. Middlefield Rd.
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 415 937-3419
+   EMail: howes@netscape.com
+
+
+   Mark Smith
+   Netscape Communications Corp.
+   501 E. Middlefield Rd.
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 415 937-3477
+   EMail: mcs@netscape.com
+
+
+
+
+
+Howes & Smith               Standards Track                     [Page 9]
+
+RFC 2255                    LDAP URL Format                December 1997
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes & Smith               Standards Track                    [Page 10]
+

Propchange: directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2255.txt
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2256.txt
URL: http://svn.apache.org/viewvc/directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2256.txt?rev=592038&view=auto
==============================================================================
--- directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2256.txt (added)
+++ directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2256.txt Mon Nov  5 07:16:53 2007
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                            M. Wahl
+Request for Comments: 2256                           Critical Angle Inc.
+Category: Standards Track                                  December 1997
+
+
+       A Summary of the X.500(96) User Schema for use with LDAPv3
+
+1. 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 (1997).  All Rights Reserved.
+
+IESG Note
+
+   This document describes a directory access protocol that provides
+   both read and update access.  Update access requires secure
+   authentication, but this document does not mandate implementation of
+   any satisfactory authentication mechanisms.
+
+   In accordance with RFC 2026, section 4.4.1, this specification is
+   being approved by IESG as a Proposed Standard despite this
+   limitation, for the following reasons:
+
+   a. to encourage implementation and interoperability testing of
+      these protocols (with or without update access) before they
+      are deployed, and
+
+   b. to encourage deployment and use of these protocols in read-only
+      applications.  (e.g. applications where LDAPv3 is used as
+      a query language for directories which are updated by some
+      secure mechanism other than LDAP), and
+
+   c. to avoid delaying the advancement and deployment of other Internet
+      standards-track protocols which require the ability to query, but
+      not update, LDAPv3 directory servers.
+
+   Readers are hereby warned that until mandatory authentication
+   mechanisms are standardized, clients and servers written according to
+   this specification which make use of update functionality are
+   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+
+
+Wahl                        Standards Track                     [Page 1]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+   Implementors are hereby discouraged from deploying LDAPv3 clients or
+   servers which implement the update functionality, until a Proposed
+   Standard for mandatory authentication in LDAPv3 has been approved and
+   published as an RFC.
+
+2. Abstract
+
+   This document provides an overview of the attribute types and object
+   classes defined by the ISO and ITU-T committees in the X.500
+   documents, in particular those intended for use by directory clients.
+   This is the most widely used schema for LDAP/X.500 directories, and
+   many other schema definitions for white pages objects use it as a
+   basis.  This document does not cover attributes used for the
+   administration of X.500 directory servers, nor does it include
+   attributes defined by other ISO/ITU-T documents.
+
+   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 RFC 2119 [6].
+
+3. General Issues
+
+   This document references syntaxes given in section 6 of this document
+   and section 6 of [1].  Matching rules are listed in section 8 of this
+   document and section 8 of [1].
+
+   The attribute type and object class definitions are written using the
+   BNF form of AttributeTypeDescription and ObjectClassDescription given
+   in [1].  Lines have been folded for readability.
+
+4. Source
+
+   The schema definitions in this document are based on those found in
+   X.500 [2],[3],[4],[5], and updates to these documents, specifically:
+
+        Sections                Source
+        ============            ============
+        5.1  - 5.2              X.501(93)
+        5.3  - 5.36             X.520(88)
+        5.37 - 5.41             X.509(93)
+        5.42 - 5.52             X.520(93)
+        5.53 - 5.54             X.509(96)
+        5.55                    X.520(96)
+        6.1                     RFC 1274
+        6.2                     (new syntax)
+        6.3  - 6.6              RFC 1274
+        7.1  - 7.2              X.501(93)
+        7.3  - 7.18             X.521(93)
+
+
+
+Wahl                        Standards Track                     [Page 2]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+        7.19 - 7.21             X.509(96)
+        7.22                    X.521(96)
+
+   Some attribute names are different from those found in X.520(93).
+
+   Three new attributes supportedAlgorithms, deltaRevocationList and
+   dmdName, and the objectClass dmd, are defined in the X.500(96)
+   documents.
+
+5. Attribute Types
+
+   An LDAP server implementation SHOULD recognize the attribute types
+   described in this section.
+
+5.1. objectClass
+
+   The values of the objectClass attribute describe the kind of object
+   which an entry represents.  The objectClass attribute is present in
+   every entry, with at least two values.  One of the values is either
+   "top" or "alias".
+
+    ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+5.2. aliasedObjectName
+
+   The aliasedObjectName attribute is used by the directory service if
+   the entry containing this attribute is an alias.
+
+    ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+5.3. knowledgeInformation
+
+   This attribute is no longer used.
+
+    ( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.4. cn
+
+   This is the X.500 commonName attribute, which contains a name of an
+   object.  If the object corresponds to a person, it is typically the
+   person's full name.
+
+    ( 2.5.4.3 NAME 'cn' SUP name )
+
+
+
+
+
+Wahl                        Standards Track                     [Page 3]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+5.5. sn
+
+   This is the X.500 surname attribute, which contains the family name
+   of a person.
+
+    ( 2.5.4.4 NAME 'sn' SUP name )
+
+5.6. serialNumber
+
+   This attribute contains the serial number of a device.
+
+    ( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
+
+5.7. c
+
+   This attribute contains a two-letter ISO 3166 country code
+   (countryName).
+
+    ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
+
+5.8. l
+
+   This attribute contains the name of a locality, such as a city,
+   county or other geographic region (localityName).
+
+    ( 2.5.4.7 NAME 'l' SUP name )
+
+5.9. st
+
+   This attribute contains the full name of a state or province
+   (stateOrProvinceName).
+
+    ( 2.5.4.8 NAME 'st' SUP name )
+
+5.10. street
+
+   This attribute contains the physical address of the object to which
+   the entry corresponds, such as an address for package delivery
+   (streetAddress).
+
+    ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+
+
+
+Wahl                        Standards Track                     [Page 4]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+5.11. o
+
+   This attribute contains the name of an organization
+   (organizationName).
+
+    ( 2.5.4.10 NAME 'o' SUP name )
+
+5.12. ou
+
+   This attribute contains the name of an organizational unit
+   (organizationalUnitName).
+
+    ( 2.5.4.11 NAME 'ou' SUP name )
+
+5.13. title
+
+   This attribute contains the title, such as "Vice President", of a
+   person in their organizational context.  The "personalTitle"
+   attribute would be used for a person's title independent of their job
+   function.
+
+    ( 2.5.4.12 NAME 'title' SUP name )
+
+5.14. description
+
+   This attribute contains a human-readable description of the object.
+
+    ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+
+5.15. searchGuide
+
+   This attribute is for use by X.500 clients in constructing search
+   filters. It is obsoleted by enhancedSearchGuide, described below in
+   5.48.
+
+    ( 2.5.4.14 NAME 'searchGuide'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+5.16. businessCategory
+
+   This attribute describes the kind of business performed by an
+   organization.
+
+   ( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch
+     SUBSTR caseIgnoreSubstringsMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+Wahl                        Standards Track                     [Page 5]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+5.17. postalAddress
+
+   ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch
+     SUBSTR caseIgnoreListSubstringsMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+5.18. postalCode
+
+   ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch
+     SUBSTR caseIgnoreSubstringsMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+5.19. postOfficeBox
+
+   ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch
+     SUBSTR caseIgnoreSubstringsMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+5.20. physicalDeliveryOfficeName
+
+   ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch
+     SUBSTR caseIgnoreSubstringsMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+5.21. telephoneNumber
+
+   ( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch
+     SUBSTR telephoneNumberSubstringsMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+
+5.22. telexNumber
+
+   ( 2.5.4.21 NAME 'telexNumber'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+5.23. teletexTerminalIdentifier
+
+   ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+5.24. facsimileTelephoneNumber
+
+   ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+
+
+
+
+
+
+Wahl                        Standards Track                     [Page 6]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+5.25. x121Address
+
+   ( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch
+     SUBSTR numericStringSubstringsMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+
+5.26. internationaliSDNNumber
+
+   ( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch
+     SUBSTR numericStringSubstringsMatch
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
+
+5.27. registeredAddress
+
+   This attribute holds a postal address suitable for reception of
+   telegrams or expedited documents, where it is necessary to have the
+   recipient accept delivery.
+
+    ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+5.28. destinationIndicator
+
+   This attribute is used for the telegram service.
+
+    ( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+
+5.29. preferredDeliveryMethod
+
+    ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+      SINGLE-VALUE )
+
+5.30. presentationAddress
+
+   This attribute contains an OSI presentation address.
+
+    ( 2.5.4.29 NAME 'presentationAddress'
+      EQUALITY presentationAddressMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.43
+      SINGLE-VALUE )
+
+
+
+
+
+
+
+
+Wahl                        Standards Track                     [Page 7]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+5.31. supportedApplicationContext
+
+   This attribute contains the identifiers of OSI application contexts.
+
+    ( 2.5.4.30 NAME 'supportedApplicationContext'
+      EQUALITY objectIdentifierMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+5.32. member
+
+    ( 2.5.4.31 NAME 'member' SUP distinguishedName )
+
+5.33. owner
+
+    ( 2.5.4.32 NAME 'owner' SUP distinguishedName )
+
+5.34. roleOccupant
+
+    ( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName )
+
+5.35. seeAlso
+
+    ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName )
+
+5.36. userPassword
+
+    ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+   Passwords are stored using an Octet String syntax and are not
+   encrypted.  Transfer of cleartext passwords are strongly discouraged
+   where the underlying transport service cannot guarantee
+   confidentiality and may result in disclosure of the password to
+   unauthorized parties.
+
+5.37. userCertificate
+
+   This attribute is to be stored and requested in the binary form, as
+   'userCertificate;binary'.
+
+    ( 2.5.4.36 NAME 'userCertificate'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+5.38. cACertificate
+
+   This attribute is to be stored and requested in the binary form, as
+   'cACertificate;binary'.
+
+
+
+
+Wahl                        Standards Track                     [Page 8]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+    ( 2.5.4.37 NAME 'cACertificate'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+5.39. authorityRevocationList
+
+   This attribute is to be stored and requested in the binary form, as
+   'authorityRevocationList;binary'.
+
+    ( 2.5.4.38 NAME 'authorityRevocationList'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.40. certificateRevocationList
+
+   This attribute is to be stored and requested in the binary form, as
+   'certificateRevocationList;binary'.
+
+    ( 2.5.4.39 NAME 'certificateRevocationList'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.41. crossCertificatePair
+
+   This attribute is to be stored and requested in the binary form, as
+   'crossCertificatePair;binary'.
+
+    ( 2.5.4.40 NAME 'crossCertificatePair'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+
+5.42. name
+
+   The name attribute type is the attribute supertype from which string
+   attribute types typically used for naming may be formed.  It is
+   unlikely that values of this type itself will occur in an entry. LDAP
+   server implementations which do not support attribute subtyping need
+   not recognize this attribute in requests.   Client implementations
+   MUST NOT assume that LDAP servers are capable of performing attribute
+   subtyping.
+
+    ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.43. givenName
+
+   The givenName attribute is used to hold the part of a person's name
+   which is not their surname nor middle name.
+
+    ( 2.5.4.42 NAME 'givenName' SUP name )
+
+
+
+
+Wahl                        Standards Track                     [Page 9]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+5.44. initials
+
+   The initials attribute contains the initials of some or all of an
+   individuals names, but not the surname(s).
+
+    ( 2.5.4.43 NAME 'initials' SUP name )
+
+5.45. generationQualifier
+
+   The generationQualifier attribute contains the part of the name which
+   typically is the suffix, as in "IIIrd".
+
+    ( 2.5.4.44 NAME 'generationQualifier' SUP name )
+
+5.46. x500UniqueIdentifier
+
+   The x500UniqueIdentifier attribute is used to distinguish between
+   objects when a distinguished name has been reused.  This is a
+   different attribute type from both the "uid" and "uniqueIdentifier"
+   types.
+
+    ( 2.5.4.45 NAME 'x500UniqueIdentifier' EQUALITY bitStringMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+5.47. dnQualifier
+
+   The dnQualifier attribute type specifies disambiguating information
+   to add to the relative distinguished name of an entry.  It is
+   intended for use when merging data from multiple sources in order to
+   prevent conflicts between entries which would otherwise have the same
+   name. It is recommended that the value of the dnQualifier attribute
+   be the same for all entries from a particular source.
+
+    ( 2.5.4.46 NAME 'dnQualifier' EQUALITY caseIgnoreMatch
+      ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+5.48. enhancedSearchGuide
+
+   This attribute is for use by X.500 clients in constructing search
+   filters.
+
+    ( 2.5.4.47 NAME 'enhancedSearchGuide'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+
+
+
+
+
+
+Wahl                        Standards Track                    [Page 10]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+5.49. protocolInformation
+
+   This attribute is used in conjunction with the presentationAddress
+   attribute, to provide additional information to the OSI network
+   service.
+
+    ( 2.5.4.48 NAME 'protocolInformation'
+      EQUALITY protocolInformationMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
+
+5.50. distinguishedName
+
+   This attribute type is not used as the name of the object itself, but
+   it is instead a base type from which attributes with DN syntax
+   inherit.
+
+   It is unlikely that values of this type itself will occur in an
+   entry.  LDAP server implementations which do not support attribute
+   subtyping need not recognize this attribute in requests.   Client
+   implementations MUST NOT assume that LDAP servers are capable of
+   performing attribute subtyping.
+
+    ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+5.51. uniqueMember
+
+    ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+5.52. houseIdentifier
+
+   This attribute is used to identify a building within a location.
+
+    ( 2.5.4.51 NAME 'houseIdentifier' EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.53. supportedAlgorithms
+
+   This attribute is to be stored and requested in the binary form, as
+   'supportedAlgorithms;binary'.
+
+    ( 2.5.4.52 NAME 'supportedAlgorithms'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+
+
+
+
+
+
+Wahl                        Standards Track                    [Page 11]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+5.54. deltaRevocationList
+
+   This attribute is to be stored and requested in the binary form, as
+   'deltaRevocationList;binary'.
+
+    ( 2.5.4.53 NAME 'deltaRevocationList'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.55. dmdName
+
+   The value of this attribute specifies a directory management domain
+   (DMD), the administrative authority which operates the directory
+   server.
+
+    ( 2.5.4.54 NAME 'dmdName' SUP name )
+
+6. Syntaxes
+
+   Servers SHOULD recognize the syntaxes defined in this section.  Each
+   syntax begins with a sample value of the ldapSyntaxes attribute which
+   defines the OBJECT IDENTIFIER of the syntax.  The descriptions of
+   syntax names are not carried in protocol, and are not guaranteed to
+   be unique.
+
+6.1. Delivery Method
+
+   ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      delivery-value = pdm / ( pdm whsp "$" whsp delivery-value )
+
+      pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
+                "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
+
+   Example:
+
+      telephone
+
+6.2. Enhanced Guide
+
+   ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset
+
+      subset = "baseobject" / "oneLevel" / "wholeSubtree"
+
+
+
+Wahl                        Standards Track                    [Page 12]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+   The criteria production is defined in the Guide syntax below.  This
+   syntax has been added subsequent to RFC 1778.
+
+   Example:
+
+      person#(sn)#oneLevel
+
+6.3. Guide
+
+   ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      guide-value = [ object-class "#" ] criteria
+
+      object-class = woid
+
+      criteria = criteria-item / criteria-set / ( "!" criteria )
+
+      criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) /
+                     ( [ "(" ] criteria "|" criteria-set [ ")" ] )
+
+      criteria-item = [ "(" ] attributetype "$" match-type [ ")" ]
+
+      match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
+
+   This syntax should not be used for defining new attributes.
+
+6.4. Octet String
+
+   ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+   Values in this syntax are encoded as octet strings.
+
+
+   Example:
+
+      secret
+
+6.5. Teletex Terminal Identifier
+
+   ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      teletex-id = ttx-term  0*("$" ttx-param)
+
+      ttx-term   = printablestring
+
+
+
+Wahl                        Standards Track                    [Page 13]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+      ttx-param  = ttx-key ":" ttx-value
+
+      ttx-key    = "graphic" / "control" / "misc" / "page" / "private"
+
+      ttx-value  = octetstring
+
+   In the above, the first printablestring is the encoding of the first
+   portion of the teletex terminal identifier to be encoded, and the
+   subsequent 0 or more octetstrings are subsequent portions of the
+   teletex terminal identifier.
+
+6.6. Telex Number
+
+   ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      telex-number  = actual-number "$" country "$" answerback
+
+      actual-number = printablestring
+
+      country       = printablestring
+
+      answerback    = printablestring
+
+   In the above, actual-number is the syntactic representation of the
+   number portion of the TELEX number being encoded, country is the
+   TELEX country code, and answerback is the answerback code of a TELEX
+   terminal.
+
+6.7. Supported Algorithm
+
+   ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' )
+
+   No printable representation of values of the supportedAlgorithms
+   attribute is defined in this document.  Clients which wish to store
+   and retrieve this attribute MUST use "supportedAlgorithms;binary", in
+   which the value is transferred as a binary encoding.
+
+7. Object Classes
+
+   LDAP servers MUST recognize the object classes "top" and "subschema".
+   LDAP servers SHOULD recognize all the other object classes listed
+   here as values of the objectClass attribute.
+
+7.1. top
+
+   ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+
+
+Wahl                        Standards Track                    [Page 14]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+7.2. alias
+
+   ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
+
+7.3. country
+
+   ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
+     MAY ( searchGuide $ description ) )
+
+7.4. locality
+
+   ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL
+     MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
+
+7.5. organization
+
+   ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o
+     MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+     x121Address $ registeredAddress $ destinationIndicator $
+     preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+     telephoneNumber $ internationaliSDNNumber $
+     facsimileTelephoneNumber $
+     street $ postOfficeBox $ postalCode $ postalAddress $
+     physicalDeliveryOfficeName $ st $ l $ description ) )
+
+7.6. organizationalUnit
+
+   ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou
+     MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+     x121Address $ registeredAddress $ destinationIndicator $
+     preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+     telephoneNumber $ internationaliSDNNumber $
+     facsimileTelephoneNumber $
+     street $ postOfficeBox $ postalCode $ postalAddress $
+     physicalDeliveryOfficeName $ st $ l $ description ) )
+
+7.7. person
+
+   ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
+     MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
+
+7.8. organizationalPerson
+
+   ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
+     MAY ( title $ x121Address $ registeredAddress $
+     destinationIndicator $
+     preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+     telephoneNumber $ internationaliSDNNumber $
+
+
+
+Wahl                        Standards Track                    [Page 15]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+     facsimileTelephoneNumber $
+     street $ postOfficeBox $ postalCode $ postalAddress $
+     physicalDeliveryOfficeName $ ou $ st $ l ) )
+
+7.9. organizationalRole
+
+   ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn
+     MAY ( x121Address $ registeredAddress $ destinationIndicator $
+     preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+     telephoneNumber $ internationaliSDNNumber $
+     facsimileTelephoneNumber $
+     seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
+     postOfficeBox $ postalCode $ postalAddress $
+     physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
+
+7.10. groupOfNames
+
+   ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn )
+     MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+
+7.11. residentialPerson
+
+   ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l
+     MAY ( businessCategory $ x121Address $ registeredAddress $
+     destinationIndicator $ preferredDeliveryMethod $ telexNumber $
+     teletexTerminalIdentifier $ telephoneNumber $
+     internationaliSDNNumber $
+     facsimileTelephoneNumber $ preferredDeliveryMethod $ street $
+     postOfficeBox $ postalCode $ postalAddress $
+     physicalDeliveryOfficeName $ st $ l ) )
+
+7.12. applicationProcess
+
+   ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn
+     MAY ( seeAlso $ ou $ l $ description ) )
+
+7.13. applicationEntity
+
+   ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL
+     MUST ( presentationAddress $ cn )
+     MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
+     description ) )
+
+7.14. dSA
+
+   ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL
+     MAY knowledgeInformation )
+
+
+
+
+Wahl                        Standards Track                    [Page 16]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+7.15. device
+
+   ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn
+     MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
+
+7.16. strongAuthenticationUser
+
+   ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY
+     MUST userCertificate )
+
+7.17. certificationAuthority
+
+   ( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY
+     MUST ( authorityRevocationList $ certificateRevocationList $
+     cACertificate ) MAY crossCertificatePair )
+
+7.18. groupOfUniqueNames
+
+   ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
+     MUST ( uniqueMember $ cn )
+     MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+
+7.19. userSecurityInformation
+
+   ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY
+     MAY ( supportedAlgorithms ) )
+
+7.20. certificationAuthority-V2
+
+   ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP
+     certificationAuthority
+     AUXILIARY MAY ( deltaRevocationList ) )
+
+7.21. cRLDistributionPoint
+
+   ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL
+     MUST ( cn ) MAY ( certificateRevocationList $
+     authorityRevocationList $
+     deltaRevocationList ) )
+
+7.22. dmd
+
+   ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName )
+     MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+     x121Address $ registeredAddress $ destinationIndicator $
+     preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+     telephoneNumber $ internationaliSDNNumber $
+     facsimileTelephoneNumber $
+
+
+
+Wahl                        Standards Track                    [Page 17]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+     street $ postOfficeBox $ postalCode $ postalAddress $
+     physicalDeliveryOfficeName $ st $ l $ description ) )
+
+8. Matching Rules
+
+   Servers MAY implement additional matching rules.
+
+8.1. octetStringMatch
+
+   Servers which implement the extensibleMatch filter SHOULD allow the
+   matching rule listed in this section to be used in the
+   extensibleMatch.  In general these servers SHOULD allow matching
+   rules to be used with all attribute types known to the server, when
+   the assertion syntax of the matching rule is the same as the value
+   syntax of the attribute.
+
+   ( 2.5.13.17 NAME 'octetStringMatch'
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+9. Security Considerations
+
+   Attributes of directory entries are used to provide descriptive
+   information about the real-world objects they represent, which can be
+   people, organizations or devices.  Most countries have privacy laws
+   regarding the publication of information about people.
+
+   Transfer of cleartext passwords are strongly discouraged where the
+   underlying transport service cannot guarantee confidentiality and may
+   result in disclosure of the password to unauthorized parties.
+
+10. Acknowledgements
+
+   The definitions on which this document have been developed by
+   committees for telecommunications and international standards.  No
+   new attribute definitions have been added.  The syntax definitions
+   are based on the ISODE "QUIPU" implementation of X.500.
+
+11. Bibliography
+
+   [1] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+       "Lightweight X.500 Directory Access Protocol (v3): Attribute
+       Syntax Definitions", RFC 2252, December 1997.
+
+   [2] The Directory: Models. ITU-T Recommendation X.501, 1996.
+
+   [3] The Directory: Authentication Framework. ITU-T Recommendation
+       X.509, 1996.
+
+
+
+
+Wahl                        Standards Track                    [Page 18]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+   [4] The Directory: Selected Attribute Types. ITU-T Recommendation
+       X.520, 1996.
+
+   [5] The Directory: Selected Object Classes.  ITU-T Recommendation
+       X.521, 1996.
+
+   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", RFC 2119, March 1997.
+
+12. Author's Address
+
+   Mark Wahl
+   Critical Angle Inc.
+   4815 West Braker Lane #502-385
+   Austin, TX 78759
+   USA
+
+   Phone:  +1 512 372 3160
+   EMail:  M.Wahl@critical-angle.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl                        Standards Track                    [Page 19]
+
+RFC 2256                     LDAPv3 Schema                 December 1997
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl                        Standards Track                    [Page 20]
+

Propchange: directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2256.txt
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2596.txt
URL: http://svn.apache.org/viewvc/directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2596.txt?rev=592038&view=auto
==============================================================================
--- directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2596.txt (added)
+++ directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2596.txt Mon Nov  5 07:16:53 2007
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                            M. Wahl
+Request for Comments: 2596                  Innosoft International, Inc.
+Category: Standards Track                                       T. Howes
+                                           Netscape Communications Corp.
+                                                                May 1999
+
+
+                     Use of Language Codes in LDAP
+
+
+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 (1999).  All Rights Reserved.
+
+1. Abstract
+
+   The Lightweight Directory Access Protocol [1] provides a means for
+   clients to interrogate and modify information stored in a distributed
+   directory system.  The information in the directory is maintained as
+   attributes [2] of entries.  Most of these attributes have syntaxes
+   which are human-readable strings, and it is desirable to be able to
+   indicate the natural language associated with attribute values.
+
+   This document describes how language codes [3] are carried in LDAP
+   and are to be interpreted by LDAP servers.  All implementations MUST
+   be prepared to accept language codes in the LDAP protocols.  Servers
+   may or may not be capable of storing attributes with language codes
+   in the directory.  This document does not specify how to determine
+   whether particular attributes can or cannot have language codes.
+
+   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 RFC 2119 [4].
+
+2. Language Codes
+
+   Section 2 of RFC 1766 [3] describes the language code format which is
+   used in LDAP.  Briefly, it is a string of ASCII alphabetic characters
+   and hyphens.  Examples include "fr", "en-US" and "ja-JP".
+
+
+
+
+Wahl & Howes                Standards Track                     [Page 1]
+
+RFC 2596             Use of Language Codes in LDAP              May 1999
+
+
+   Language codes are case insensitive.  For example, the language code
+   "en-us" is the same as "EN-US" and "en-US".
+
+   Implementations MUST NOT otherwise interpret the structure of the
+   code when comparing two codes, and MUST treat them as simply strings
+   of characters. Client and server implementations MUST allow any
+   arbitrary string which follows the patterns given in RFC 1766 to be
+   used as a language code.
+
+3. Use of Language Codes in LDAP
+
+   This section describes how LDAP implementations MUST interpret
+   language codes in performing operations.
+
+   In general, an attribute with a language code is to be treated as a
+   subtype of the attribute without a language code.  If a server does
+   not support storing language codes with attribute values in the DIT,
+   then it MUST always treat an attribute with a language code as an
+   unrecognized attribute.
+
+3.1. Attribute Description
+
+   An attribute consists of a type, a list of options for that type, and
+   a set of one or more values.  In LDAP, the type and the options are
+   combined into the AttributeDescription, defined in section 4.1.5 of
+   [1]. This is represented as an attribute type name and a possibly-
+   empty list of options.  One of these options associates a natural
+   language with values for that attribute.
+
+        language-option = "lang-" lang-code
+
+        lang-code = printable-ascii ; a code as defined in RFC 1766
+
+   Multiple language options may be present on a particular value.
+
+   The language code has no effect on the character set encoding for
+   string representations of DirectoryString syntax values; the UTF-8
+   representation of UniversalString (ISO 10646) is always used.
+
+   Examples of valid AttributeDescription:
+        givenName;lang-en-US
+        CN;lang-ja
+
+   In LDAP and in examples in this document, a directory attribute is
+   represented as an AttributeDescription with a list of values.  Note
+   that the data could be stored in the LDAP server in a different
+   representation.
+
+
+
+
+Wahl & Howes                Standards Track                     [Page 2]
+
+RFC 2596             Use of Language Codes in LDAP              May 1999
+
+
+3.2. Distinguished Names and Relative Distinguished Names
+
+   No attribute description options are permitted in Distinguished Names
+   or Relative Distinguished Names.  Thus language codes MUST NOT be
+   used in forming DNs.
+
+3.3. Search Filter
+
+   If a language code is present in an AttributeDescription in a search
+   filter, then only attribute values in the directory which match the
+   base attribute type or its subtype, the language code and the
+   assertion value match this filter.
+
+   Thus for example a filter of an equality match of type "name;lang-
+   en-US" and assertion value "Billy Ray", against the following
+   directory entry
+
+   objectclass: top                     DOES NOT MATCH (wrong type)
+   objectclass: person                  DOES NOT MATCH (wrong type)
+   name;lang-EN-US: Billy Ray           MATCHES
+   name;lang-EN-US: Billy Bob           DOES NOT MATCH (wrong value)
+   CN;lang-en-us: Billy Ray                MATCHES
+   CN;lang-EN-US;dynamic: Billy Ray     MATCHES
+   CN;lang-en;dynamic: Billy Ray        DOES NOT MATCH (differing lang-)
+   name: Billy Ray                      DOES NOT MATCH (no lang-)
+   SN: Ray                              DOES NOT MATCH (wrong value)
+
+   (Note that "CN" and "SN" are subtypes of "name".)
+
+   Client implementors should however note that providing a language
+   code in a search filter AttributeDescription will often filter out
+   desirable values where the language code does not match exactly.  For
+   example, the filter (name;lang-en=Billy Ray) does NOT match the
+   attribute "name;lang-en-US: Billy Ray".
+
+   If the server does not support storing language codes with attribute
+   values in the DIT, then any filter which includes a language code
+   will always fail to match, as it is an unrecognized attribute type.
+   No error would be returned because of this; a presence filter would
+   evaluate to FALSE and all other forms to Undefined.
+
+   If no language code is specified in the search filter, then only the
+   base attribute type and the assertion value need match the value in
+   the directory.
+
+   Thus for example a filter of an equality match of type "name" and
+   assertion value "Billy Ray", against the following directory entry
+
+
+
+
+Wahl & Howes                Standards Track                     [Page 3]
+
+RFC 2596             Use of Language Codes in LDAP              May 1999
+
+
+   objectclass: top                     DOES NOT MATCH (wrong type)
+   objectclass: person                  DOES NOT MATCH (wrong type)
+   name;lang-EN-US: Billy Ray           MATCHES
+   name;lang-EN-US: Billy Bob           DOES NOT MATCH (wrong value)
+   CN;lang-EN-US;dynamic: Billy Ray     MATCHES
+   CN;lang-en;dynamic: Billy Ray        MATCHES
+   name: Billy Ray                      MATCHES
+   SN: Ray                              DOES NOT MATCH (wrong value)
+
+   Thus in general, clients SHOULD NOT use the language code option in
+   AttributeDescription fields in search filters.
+
+3.4. Compare
+
+   A language code can be present in an AttributeDescription used in a
+   compare request AttributeValueAssertion.  This is to be treated by
+   servers the same as the use of language codes in a search filter with
+   an equality match, as described in the previous section.  If there is
+   no attribute in the entry with the same subtype and language code,
+   the noSuchAttributeType error will be returned.
+
+   Thus for example a compare request of type "name" and assertion value
+   "Johann", against an entry with all the following directory entry
+
+   objectclass: top
+   objectclass: person
+   givenName;lang-de-DE: Johann
+   CN: Johann Sibelius
+   SN: Sibelius
+
+   will cause the server to return compareTrue.
+
+   However, if the client issued a compare request of type "name;lang-
+   de" and assertion value "Johann" against the above entry, the request
+   would fail with the noSuchAttributeType error.
+
+   If the server does not support storing language codes with attribute
+   values in the DIT, then any comparison which includes a language code
+   will always fail to locate an attribute type, and noSuchAttributeType
+   will be returned.
+
+   Thus in general, clients SHOULD NOT use the language code option in
+   AttributeDescription fields in the compare request.
+
+3.5. Requested Attributes in Search
+
+   Clients MAY provide language codes in AttributeDescription in the
+   requested attribute list in a search request.
+
+
+
+Wahl & Howes                Standards Track                     [Page 4]
+
+RFC 2596             Use of Language Codes in LDAP              May 1999
+
+
+   If a language code is provided in an attribute description, then only
+   attribute values in a directory entry which have the same language
+   code as that provided are to be returned. Thus if a client requests
+   an attribute "description;lang-en", the server MUST NOT return values
+   of an attribute "description" or "description;lang-fr".
+
+   Clients MAY provide in the attribute list multiple
+   AttributeDescription which have the same base attribute type but
+   different options. For example a client MAY provide both "name;lang-
+   en" and "name;lang-fr", and this would permit an attribute with
+   either language code to be returned.  Note there would be no need to
+   provide both "name" and "name;lang-en" since all subtypes of name
+   would match "name".
+
+   If a server does not support storing language codes with attribute
+   values in the DIT, then any attribute descriptions in the list which
+   include language codes are to be ignored, just as if they were
+   unknown attribute types.
+
+   If a request is made specifying all attributes or an attribute is
+   requested without providing a language code, then all attribute
+   values regardless of their language code are returned.
+
+   For example, if the client requests a "description" attribute, and a
+   matching entry contains
+
+   objectclass: top
+   objectclass: organization
+   O: Software GmbH
+   description: software
+   description;lang-en: software products
+   description;lang-de: Softwareprodukte
+   postalAddress: Berlin 8001 Germany
+   postalAddress;lang-de: Berlin 8001 Deutschland
+
+   The server will return:
+
+   description: software
+   description;lang-en: software products
+   description;lang-de: Softwareprodukte
+
+3.6. Add Operation
+
+   Clients MAY provide language codes in AttributeDescription in
+   attributes of a new entry to be created, subject to the limitation
+   that the client MUST NOT use language codes in the attribute value or
+   values which form the RDN of the entry.
+
+
+
+
+Wahl & Howes                Standards Track                     [Page 5]
+
+RFC 2596             Use of Language Codes in LDAP              May 1999
+
+
+   A client MAY provide multiple attributes with the same attribute type
+   and value, so long as each attribute has a different language code,
+   and at most one attribute does not have a language code option.
+
+   Servers which support storing language codes in the DIT MUST allow
+   any attribute it recognizes that has the Directory String syntax to
+   have a language option associated with it. Servers SHOULD allow
+   language options to be associated with other attributes.
+
+   For example, the following is a legal request.
+
+   objectclass: top
+   objectclass: person
+   objectclass: residentialPerson
+   name: John Smith
+   CN: John Smith
+   CN;lang-en: John Smith
+   SN: Smith
+   streetAddress: 1 University Street
+   streetAddress;lang-en: 1 University Street
+   streetAddress;lang-fr: 1 rue Universite
+   houseIdentifier;lang-fr: 9e etage
+
+   If a server does not support storing language codes with attribute
+   values in the DIT, then it MUST treat an AttributeDescription with a
+   language code as an unrecognized attribute. If the server forbids the
+   addition of unrecognized attributes then it MUST fail the add request
+   with the appropriate result code.
+
+3.7. Modify Operation
+
+   A client MAY provide a language code in an AttributeDescription as
+   part of a modification element in the modify operation.
+
+   Attribute types and language codes MUST match exactly against values
+   stored in the directory.  For example, if the modification is a
+   "delete", then if the stored values to be deleted have a language
+   code, the language code MUST be provided in the modify operation, and
+   if the stored values to be deleted do not have a language code, then
+   no language code is to be provided.
+
+   If the server does not support storing language codes with attribute
+   values in the DIT, then it MUST treat an AttributeDescription with a
+   language code as an unrecognized attribute, and MUST fail the request
+   with an appropriate result code.
+
+
+
+
+
+
+Wahl & Howes                Standards Track                     [Page 6]
+
+RFC 2596             Use of Language Codes in LDAP              May 1999
+
+
+3.8. Diagnostic Messages
+
+   Servers SHOULD use only printable ASCII characters in the
+   errorMessage field, as not all clients will be able to display the
+   full range of Unicode.
+
+4. Differences from X.500(1997)
+
+   X.500(1997) defines a different mechanism, contexts, as the means of
+   representing language tags.  This section summarizes the major
+   differences in approach.
+
+   a) An X.500 operation which has specified a language code on a value
+      matches a value in the directory without a language code.
+   b) LDAP references RFC 1766, which allows for IANA registration of
+      new tags.
+   c) LDAP does not allow language codes in distinguished names.
+   d) X.500 describes subschema administration procedures to allow
+      language codes to be associated with particular attributes types.
+
+5. Security Considerations
+
+   There are no known security considerations for this document.  See
+   the security considerations sections of [1] and [2] for security
+   considerations of LDAP in general.
+
+6. Acknowledgements
+
+   This document is a product of the IETF ASID and LDAPEXT working
+   groups.  Martin Duerst provided many valuable comments on an earlier
+   version of this document.
+
+7. Bibliography
+
+   [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+       Protocol (v3)", RFC 2251, December 1997.
+
+   [2] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+       X.500 Directory Access Protocol Attribute Syntax Definitions",
+       RFC 2252, December 1997.
+
+   [3] Alvestrand, H.,"Tags for the Identification of Languages", RFC
+       1766, March 1995.
+
+   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Wahl & Howes                Standards Track                     [Page 7]
+
+RFC 2596             Use of Language Codes in LDAP              May 1999
+
+
+8. Authors' Addresses
+
+   Mark Wahl
+   Innosoft International, Inc.
+   8911 Capital of Texas Hwy Suite 4140
+   Austin, TX 78759 USA
+
+   EMail:  M.Wahl@innosoft.com
+
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 E. Middlefield Rd
+   Mountain View, CA 94043 USA
+
+   Phone:  +1 650 937-3419
+   EMail:   howes@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl & Howes                Standards Track                     [Page 8]
+
+RFC 2596             Use of Language Codes in LDAP              May 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl & Howes                Standards Track                     [Page 9]
+

Propchange: directory/sandbox/felixk/studio-ldapbrowser-help/src/main/resources/html/rfc/rfc2596.txt
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message