Include more LDAP RFCs

doc/rfc/rfc1488.txt

+
+
+
+
+
+
+Network Working Group                                         T. Howes
+Request for Comments: 1488                      University of Michigan
+                                                              S. Kille
+                                                      ISODE Consortium
+                                                              W. Yeong
+                                     Performance Systems International
+                                                            C. Robbins
+                                                            NeXor Ltd.
+                                                             July 1993
+
+
+     The X.500 String Representation of Standard Attribute Syntaxes
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) [9] requires that
+   the contents of AttributeValue fields in protocol elements be octet
+   strings.  This document defines the requirements that must be
+   satisfied by encoding rules used to render Directory attribute
+   syntaxes into a form suitable for use in the LDAP, then goes on to
+   define the encoding rules for the standard set of attribute syntaxes
+   defined in [1,2] and [3].
+
+1.  Attribute Syntax Encoding Requirements
+
+   This section defines general requirements for lightweight directory
+   protocol attribute syntax encodings. All documents defining attribute
+   syntax encodings for use by the lightweight directory protocols are
+   expected to conform to these requirements.
+
+   The encoding rules defined for a given attribute syntax must produce
+   octet strings.  To the greatest extent possible, encoded octet
+   strings should be usable in their native encoded form for display
+   purposes. In particular, encoding rules for attribute syntaxes
+   defining non-binary values should produce strings that can be
+   displayed with little or no translation by clients implementing the
+   lightweight directory protocols.
+
+
+
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 1]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+2.  Standard Attribute Syntax Encodings
+
+   For the purposes of defining the encoding rules for the standard
+   attribute syntaxes, the following auxiliary BNF definitions will be
+   used:
+
+     <a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
+             'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
+             's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
+             'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
+             'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
+             'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
+
+     <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
+
+     <hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
+                      'A' | 'B' | 'C' | 'D' | 'E' | 'F'
+
+     <k> ::= <a> | <d> | '-'
+
+     <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
+             '/' | ':' | '?' | ' '
+
+     <CRLF> ::= The ASCII newline character with hexadecimal value 0x0A
+
+     <letterstring> ::= <a> | <a> <letterstring>
+
+     <numericstring> ::= <d> | <d> <numericstring>
+
+     <keystring> ::= <a> | <a> <anhstring>
+
+     <anhstring> ::= <k> | <k> <anhstring>
+
+     <printablestring> ::= <p> | <p> <printablestring>
+
+     <space> ::= ' ' | ' ' <space>
+
+2.1.  Undefined
+
+   Values of type Undefined are encoded as if they were values of type
+   Octet String.
+
+2.2.  Case Ignore String
+
+   A string of type caseIgnoreStringSyntax is encoded as the string
+   value itself.
+
+
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 2]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+2.3.  Case Exact String
+
+   The encoding of a string of type caseExactStringSyntax is the string
+   value itself.
+
+2.4.  Printable String
+
+   The encoding of a string of type printableStringSyntax is the string
+   value itself.
+
+2.5.  Numeric String
+
+   The encoding of a string of type numericStringSyntax is the string
+   value itself.
+
+2.6.  Octet String
+
+   The encoding of a string of type octetStringSyntax is the string
+   value itself.
+
+2.7.  Case Ignore IA5 String
+
+   The encoding of a string of type caseIgnoreIA5String is the string
+   value itself.
+
+2.8.  IA5 String
+
+   The encoding of a string of type iA5StringSyntax is the string value
+   itself.
+
+2.9.  T61 String
+
+   The encoding of a string of type t61StringSyntax is the string value
+   itself.
+
+2.10.  Case Ignore List
+
+   Values of type caseIgnoreListSyntax are encoded according to the
+   following BNF:
+
+     <caseignorelist> ::= <caseignorestring> |
+                          <caseignorestring> '$' <caseignorelist>
+
+     <caseignorestring> ::= a string encoded according to the rules
+                             for Case Ignore String as above.
+
+
+
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 3]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+2.11.  Case Exact List
+
+   Values of type caseExactListSyntax are encoded according to the
+   following BNF:
+
+     <caseexactlist> ::= <caseexactstring> |
+                          <caseexactstring> '$' <caseexactlist>
+
+     <caseexactstring> ::= a string encoded according to the rules for
+                            Case Exact String as above.
+
+2.12.  Distinguished Name
+
+   Values of type distinguishedNameSyntax are encoded to have the
+   representation defined in [5].
+
+2.13.  Boolean
+
+   Values of type booleanSyntax are encoded according to the following
+   BNF:
+
+     <boolean> ::= "TRUE" | "FALSE"
+
+   Boolean values have an encoding of "TRUE" if they are logically true,
+   and have an encoding of "FALSE" otherwise.
+
+2.14.  Integer
+
+   Values of type integerSyntax are encoded as the decimal
+   representation of their values, with each decimal digit represented
+   by the its character equivalent. So the digit 1 is represented by the
+   character
+
+2.15.  Object Identifier
+
+   Values of type objectIdentifierSyntax are encoded according to the
+   following BNF:
+
+     <oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
+
+     <descr> ::= <keystring>
+
+     <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
+
+   In the above BNF, <descr> is the syntactic representation of an
+   object descriptor. When encoding values of type
+   objectIdentifierSyntax, the first encoding option should be used in
+   preference to the second, which should be used in preference to the
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 4]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+   third wherever possible. That is, in encoding object identifiers,
+   object descriptors (where assigned and known by the implementation)
+   should be used in preference to numeric oids to the greatest extent
+   possible. For example, in encoding the object identifier representing
+   an organizationName, the descriptor "organizationName" is preferable
+   to "ds.4.10", which is in turn preferable to the string "2.5.4.10".
+
+2.16.  Telephone Number
+
+   Values of type telephoneNumberSyntax are encoded as if they were
+   Printable String types.
+
+2.17.  Telex Number
+
+   Values of type telexNumberSyntax 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.
+
+2.18.  Teletex Terminal Identifier
+
+   Values of type teletexTerminalIdentifier are encoded according to the
+   following BNF:
+
+     <teletex-id> ::= <printablestring> 0*( '$' <printablestring>)
+
+   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 <printablestrings> are subsequent portions
+   of the teletex terminal identifier.
+
+2.19.  Facsimile Telephone Number
+
+   Values of type FacsimileTelephoneNumber are encoded according to the
+   following BNF:
+
+ <fax-number> ::= <printablestring> [ '$' <faxparameters> ]
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 5]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+ <faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
+
+ <faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
+               'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
+
+   In the above, the first <printablestring> is the actual fax number,
+   and the <faxparm> tokens represent fax parameters.
+
+2.20.  Presentation Address
+
+   Values of type PresentationAddress are encoded to have the
+   representation described in [6].
+
+2.21.  UTC Time
+
+   Values of type uTCTimeSyntax are encoded as if they were Printable
+   Strings with the strings containing a UTCTime value.
+
+2.22.  Guide (search guide)
+
+   Values of type Guide, such as values of the searchGuide attribute,
+   are encoded according to the following BNF:
+
+     <guide-value> ::= [ <object-class> '#' ] <criteria>
+
+     <object-class> ::= an encoded value of type objectIdentifierSyntax
+
+     <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"
+
+2.23.  Postal Address
+
+Values of type PostalAddress are encoded according to the following BNF:
+
+     <postal-address> ::= <t61string> | <t61string> '$' <postal-address>
+
+   In the above, each <t61string> component of a postal address value is
+   encoded as a value of type t61StringSyntax.
+
+
+
+
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 6]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+2.24.  User Password
+
+   Values of type userPasswordSyntax are encoded as if they were of type
+   octetStringSyntax.
+
+2.25.  User Certificate
+
+   Values of type userCertificate are encoded according to the following
+   BNF:
+
+ <certificate> ::= <signature> '#' <issuer> '#' <validity> '#' <subject>
+                   '#' <public-key-info>
+
+ <signature> ::= <algorithm-id>
+
+ <issuer> ::= an encoded Distinguished Name
+
+ <validity> ::= <not-before-time> '#' <not-after-time>
+
+ <not-before-time> ::= <utc-time>
+
+ <not-after-time> ::= <utc-time>
+
+ <algorithm-parameters> ::=  <null> | <integervalue> |
+                             '{ASN}' <hex-string>
+
+ <subject> ::= an encoded Distinguished Name
+
+ <public-key-info> ::= <algorithm-id> '#' <encrypted-value>
+
+ <encrypted-value> ::= <hex-string> | <hex-string> '-' <d>
+
+ <algorithm-id> ::= <oid> '#' <algorithm-parameters>
+
+ <utc-time> ::= an encoded UTCTime value
+
+ <hex-string> ::= <hex-digit> | <hex-digit> <hex-string>
+
+2.26.  CA Certificate
+
+   Values of type cACertificate are encoded as if the values were of
+   type userCertificate.
+
+2.27.  Authority Revocation List
+
+   Values of type authorityRevocationList are encoded according to the
+   following BNF:
+
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 7]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+     <certificate-list> ::= <signature> '#' <issuer> '#'
+                            <utc-time> [ '#' <revoked-certificates> ]
+
+     <revoked-certificates> ::= <algorithm> '#' <encrypted-value>
+                                [ '#' 0*(<revoked-certificate>) '#']
+
+     <revoked-certificates> ::= <subject> '#' <algorithm> '#'
+                                <serial> '#' <utc-time>
+
+   The syntactic components <algorithm>, <issuer>, <encrypted-value>,
+   <utc-time>, <subject> and <serial> have the same definitions as in
+   the BNF for the userCertificate attribute syntax.
+
+2.28.  Certificate Revocation List
+
+   Values of type certificateRevocationList are encoded as if the values
+   were of type authorityRevocationList.
+
+2.29.  Cross Certificate Pair
+
+   Values of type crossCertificatePair are encoded according to the
+   following BNF:
+
+     <certificate-pair> ::= <certificate> '|' <certificate>
+
+   The syntactic component <certificate> has the same definition as in
+   the BNF for the userCertificate attribute syntax.
+
+2.30.  Delivery Method
+
+   Values of type deliveryMethod are encoded according to the following
+   BNF:
+
+     <delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
+
+     <pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
+               'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
+
+2.31.  Other Mailbox
+
+   Values of the type otherMailboxSyntax are encoded according to the
+   following BNF:
+
+     <otherMailbox> ::= <mailbox-type> '$' <mailbox>
+
+     <mailbox-type> ::= an encoded Printable String
+
+     <mailbox> ::= an encoded IA5 String
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 8]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+   In the above, <mailbox-type> represents the type of mail system in
+   which the mailbox resides, for example "Internet" or "MCIMail"; and
+   <mailbox> is the actual mailbox in the mail system defined by
+   <mailbox-type>.
+
+2.32.  Mail Preference
+
+   Values of type mailPreferenceOption are encoded according to the
+   following BNF:
+
+ <mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
+
+2.33.  MHS OR Address
+
+   Values of type MHS OR Address are encoded as strings, according to
+   the format defined in [10].
+
+2.34.  Photo
+
+   Values of type Photo are encoded as if they were octet strings
+   containing JPEG images in the JPEG File Interchange Format (JFIF), as
+   described in [8].
+
+2.35.  Fax
+
+   Values of type Fax are encoded as if they were octet strings
+   containing Group 3 Fax images as defined in [7].
+
+3.  Acknowledgements
+
+   Many of the attribute syntax encodings defined in this document are
+   adapted from those used in the QUIPU X.500 implementation. The
+   contribu- tions of the authors of the QUIPU implementation in the
+   specification of the QUIPU syntaxes [4] are gratefully acknowledged.
+
+4.  Bibliography
+
+   [1] The Directory: Selected Attribute Syntaxes.  CCITT,
+       Recommendation X.520.
+
+   [2] Information Processing Systems -- Open Systems Interconnection --
+       The Directory: Selected Attribute Syntaxes.
+
+   [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
+       RFC 1274, University College London, November 1991.
+
+   [4] The ISO Development Environment: User's Manual -- Volume 5:
+       QUIPU.  Colin Robbins, Stephen E. Kille.
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 9]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+   [5] Kille, S., "A String Representation of Distinguished Names", RFC
+       1485, July 1993.
+
+   [6] Kille, S., "A String Representation for Presentation Addresses",
+       RFC 1278, University College London, November 1991.
+
+   [7] Terminal Equipment and Protocols for Telematic Services -
+       Standardization of Group 3 facsimile apparatus for document
+       transmission.  CCITT, Recommendation T.4.
+
+   [8] JPEG File Interchange Format (Version 1.02).  Eric Hamilton, C-
+       Cube Microsystems, Milpitas, CA, September 1, 1992.
+
+   [9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
+       Protocol", RFC 1487, Performance Systems International,
+       University of Michigan, ISODE Consortium, July 1993.
+
+  [10] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC 822",
+       RFC 1327, University College London, May 1992.
+
+5.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, Kille, Yeong & Robbins                                  [Page 10]
+
+RFC 1488                 X.500 Syntax Encoding                 July 1993
+
+
+6.  Authors' Addresses
+
+   Tim Howes
+   University of Michigan
+   ITD Research Systems
+   535 W William St.
+   Ann Arbor, MI 48103-4943
+   USA
+
+   Phone: +1 313 747-4454
+   EMail: tim@umich.edu
+
+
+   Steve Kille
+   ISODE Consortium
+   PO Box 505
+   London
+   SW11 1DX
+   UK
+
+   Phone: +44-71-223-4062
+   EMail: S.Kille@isode.com
+
+
+   Wengyik Yeong
+   PSI, Inc.
+   510 Huntmar Park Drive
+   Herndon, VA 22070
+   USA
+
+   Phone: +1 703-450-8001
+   EMail: yeongw@psilink.com
+
+
+   Colin Robbins
+   NeXor Ltd
+   University Park
+   Nottingham
+   NG7 2RD
+   UK
+
+
+
+
+
+
+
+
+
+
+
+Howes, Kille, Yeong & Robbins                                  [Page 11]
+
\ No newline at end of file

doc/rfc/rfc2079.txt

+
+
+
+
+
+
+Network Working Group                                          M. Smith
+Request for Comments: 2079                      Netscape Communications
+Category: Standards Track                                  January 1997
+
+
+   Definition of an X.500 Attribute Type and an Object Class to Hold
+                  Uniform Resource Identifiers (URIs)
+
+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.
+
+Abstract
+
+   Uniform Resource Locators (URLs) are being widely used to specify the
+   location of Internet resources.  There is an urgent need to be able
+   to include URLs in directories that conform to the LDAP and X.500
+   information models, and a desire to include other types of Uniform
+   Resource Identifiers (URIs) as they are defined.  A number of
+   independent groups are already experimenting with the inclusion of
+   URLs in LDAP and X.500 directories.  This document builds on the
+   experimentation to date and defines a new attribute type and an
+   auxiliary object class to allow URIs, including URLs, to be stored in
+   directory entries in a standard way.
+
+Background and Intended Usage
+
+   Uniform Resource Locators (URLs) as defined by [1] are the first of
+   several types of Uniform Resource Identifiers (URIs) being defined by
+   the IETF.  URIs are widely used on the Internet, most notably within
+   Hypertext Markup Language [2] documents. This document defines an
+   X.500 [3,4] attribute type called labeledURI and an auxiliary object
+   class called labeledURIObject to hold all types of URIs, including
+   URLs.  These definitions are designed for use in LDAP and X.500
+   directories, and may be used in other contexts as well.
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                       Standards Track                     [Page 1]
+
+RFC 2079          URI Attribute Type and Object Class       January 1997
+
+
+Schema Definition of the labeledURI Attribute Type
+
+   Name:             labeledURI
+   ShortName:        None
+   Description:      Uniform Resource Identifier with optional label
+   OID:              umichAttributeType.57 (1.3.6.1.4.1.250.1.57)
+   Syntax:           caseExactString
+   SizeRestriction:  None
+   SingleValued:     False
+
+Discussion of the labeledURI Attribute Type
+
+   The labeledURI attribute type has the caseExactString syntax (since
+   URIs are case-sensitive) and it is multivalued.  Values placed in the
+   attribute should consist of a URI (at the present time, a URL)
+   optionally followed by one or more space characters and a label.
+   Since space characters are not allowed to appear un-encoded in URIs,
+   there is no ambiguity about where the label begins.  At the present
+   time, the URI portion must comply with the URL specification [1].
+   Multiple labeledURI values will generally indicate different
+   resources that are all related to the X.500 object, but may indicate
+   different locations for the same resource.
+
+   The label is used to describe the resource to which the URI points,
+   and is intended as a friendly name fit for human consumption.  This
+   document does not propose any specific syntax for the label part.  In
+   some cases it may be helpful to include in the label some indication
+   of the kind and/or size of the resource referenced by the URI.
+
+   Note that the label may include any characters allowed by the
+   caseExactString syntax, but that the use of non-IA5 (non-ASCII)
+   characters is discouraged as not all directory clients may handle
+   them in the same manner.  If non-IA5 characters are included, they
+   should be represented using the X.500 conventions, not the HTML
+   conventions (e.g., the character that is an "a" with a ring above it
+   should be encoded using the T.61 sequence 0xCA followed by an "a"
+   character; do not use the HTML escape sequence "&aring").
+
+Examples of labeledURI Attribute Values
+
+   An example of a labeledURI attribute value that does not include a
+   label:
+
+                   ftp://ds.internic.net/rfc/rfc822.txt
+
+
+
+
+
+
+
+Smith                       Standards Track                     [Page 2]
+
+RFC 2079          URI Attribute Type and Object Class       January 1997
+
+
+   An example of a labeledURI attribute value that contains a tilde
+   character in the URL (special characters in a URL must be encoded as
+   specified by the URL document [1]).  The label is "LDAP Home Page":
+
+             http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page
+
+   Another example.  This one includes a hint in the label to help the
+   user realize that the URL points to a photo image.
+
+        http://champagne.inria.fr/Unites/rennes.gif Rennes [photo]
+
+Schema Definition of the labeledURIObject Object Class
+
+   Name:              labeledURIObject
+   Description:       object that contains the URI attribute type
+   OID:               umichObjectClass.15 (1.3.6.1.4.1.250.3.15)
+   SubclassOf:        top
+   MustContain:
+   MayContain:        labeledURI
+
+Discussion of the labeledURIObject Object Class
+
+   The labeledURIObject class is a subclass of top and may contain the
+   labeledURI attribute.  The intent is that this object class can be
+   added to existing directory objects to allow for inclusion of URI
+   values.  This approach does not preclude including the labeledURI
+   attribute type directly in other object classes as appropriate.
+
+Security Considerations
+
+   Security considerations are not discussed in this memo, except to
+   note that blindly inserting the label portion of a labeledURI
+   attribute value into an HTML document is not recommended, as this may
+   allow a malicious individual to include HTML tags in the label that
+   mislead viewers of the entire document in which the labeledURI value
+   was inserted.
+
+Acknowledgments
+
+   Paul-Andre Pays, Martijn Koster, Tim Howes, Rakesh Patel, Russ
+   Wright, and Hallvard Furuseth provided invaluable assistance in the
+   creation of this document.
+
+   This material is based in part upon work supported by the National
+   Science Foundation under Grant No. NCR-9416667.
+
+
+
+
+
+
+Smith                       Standards Track                     [Page 3]
+
+RFC 2079          URI Attribute Type and Object Class       January 1997
+
+
+Appendix:  The labeledURL Attribute Type (Deprecated)
+
+   An earlier draft of this document defined an additional attribute
+   type called labeledURL.  This attribute type is deprecated, and
+   should not be used when adding new values to directory entries.  The
+   original motivation for including a separate attribute type to hold
+   URLs was that this would better enable efficient progammatic access
+   to specific types of URIs.  After some deliberation, the IETF-ASID
+   working group concluded that it was better to simply have one
+   attribute than two.
+
+   The schema definition for labeledURL is included here for historical
+   reference only.  Directory client software may want to support this
+   schema definition (in addition to labeledURI) to ease the transition
+   away from labeledURL for those sites that are using it.
+
+   Name:             labeledURL
+   ShortName:        None
+   Description:      Uniform Resource Locator with optional label
+   OID:              umichAttributeType.41 (1.3.6.1.4.1.250.1.41)
+   Syntax:           caseExactString
+   SizeRestriction:  None
+   SingleValued:     False
+   OID:              umichAttributeType.41 (1.3.6.1.4.1.250.1.41)
+
+References
+
+   [1] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+   Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
+   University of Minnesota, December 1994.
+   <URL:ftp://ds.internic.net/rfc/rfc1738.txt>
+
+   [2] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
+   2.0", RFC 1866, <URL:ftp://ds.internic.net/rfc/rfc1866.txt>
+
+   [3] The Directory: Overview of Concepts, Models and Service.  CCITT
+   Recommendation X.500, 1988.
+
+   [4] Information Processing Systems -- Open Systems Interconnection --
+   The Directory: Overview of Concepts, Models and Service.  ISO/IEC JTC
+   1/SC21; International Standard 9594-1, 1988.
+
+
+
+
+
+
+
+
+
+
+Smith                       Standards Track                     [Page 4]
+
+RFC 2079          URI Attribute Type and Object Class       January 1997
+
+
+Author's Address
+
+   Mark Smith
+   Netscape Communications Corp.
+   501 E. Middlefield Rd.
+   Mountain View, CA 94043, USA
+
+   Phone:  +1 415 937-3477
+   EMail:  mcs@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                       Standards Track                     [Page 5]
+

doc/rfc/rfc2587.txt

+
+
+
+
+
+
+Network Working Group                                     S. Boeyen
+Request for Comments: 2587                                  Entrust
+Category: Standards Track                                  T. Howes
+                                                           Netscape
+                                                         P. Richard
+                                                              Xcert
+                                                          June 1999
+
+
+
+                Internet X.509 Public Key Infrastructure
+                             LDAPv2 Schema
+
+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 schema defined in this document is a minimal schema to support
+   PKIX in an LDAPv2 environment, as defined in RFC 2559.  Only PKIX-
+   specific components are specified here.  LDAP servers, acting as PKIX
+   repositories should support the auxiliary object classes defined in
+   this specification and integrate this schema specification with the
+   generic and other application-specific schemas as appropriate,
+   depending on the services to be supplied by that server.
+
+   The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
+   and 'MAY' in this document are to be interpreted as described in RFC
+   2119.
+
+2.  Introduction
+
+   This specification is part of a multi-part standard for development
+   of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
+   mechanism defined for access to a PKI repository. Other mechanisms,
+   such as http, are also defined. If an LDAP server, accessed by LDAPv2
+   is used to provide a repository, the minimum requirement is that the
+   repository support the addition of X.509 certificates to directory
+
+
+
+
+Boeyen, et al.              Standards Track                     [Page 1]
+
+RFC 2587                   PKIX LDAPv2 Schema                  June 1999
+
+
+   entries.  Certificate Revocation List (CRL)is one mechanism for
+   publishing revocation information in a repository.  Other mechanisms,
+   such as http, are also defined.
+
+   This specification defines the attributes and object classes to be
+   used by LDAP servers acting as PKIX repositories and to be understood
+   by LDAP clients communicating with such repositories to query, add,
+   modify and delete PKI information. Some object classes and attributes
+   defined in X.509 are duplicated here for completeness. For end
+   entities and Certification Authorities (CA), the earlier X.509
+   defined object classes mandated inclusion of attributes which are
+   optional for PKIX. Also, because of the mandatory attribute
+   specification, this would have required dynamic modification of the
+   object class attribute should the attributes not always be present in
+   entries. For these reasons, alternative object classes are defined in
+   this document for use by LDAP servers acting as PKIX repositories.
+
+3.  PKIX Repository Objects
+
+   The primary PKIX objects to be represented in a repository are:
+
+      -  End Entities
+      -  Certification Authorities (CA)
+
+   These objects are defined in RFC 2459.
+
+3.1.  End Entities
+
+   For purposes of PKIX schema definition, the role of end entities as
+   subjects of certificates is the major aspect relevant to this
+   specification. End entities may be human users, or other types of
+   entities to which certificates may be issued. In some cases, the
+   entry for the end entity may already exist and the PKI-specific
+   information is added to the existing entry. In other cases the entry
+   may not exist prior to the issuance of a certificate, in which case
+   the entity adding the certificate may also need to create the entry.
+   Schema elements used to represent the non PKIX aspects of an entry,
+   such as the structural object class used to represent organizational
+   persons, may vary, depending on the particular environment and set of
+   applications served and are outside the scope of this specification.
+
+   The following auxiliary object class MAY be used to represent
+   certificate subjects:
+
+
+
+
+
+
+
+
+Boeyen, et al.              Standards Track                     [Page 2]
+
+RFC 2587                   PKIX LDAPv2 Schema                  June 1999
+
+
+pkiUser   OBJECT-CLASS   ::= {
+   SUBCLASS OF   { top}
+   KIND          auxiliary
+   MAY CONTAIN   {userCertificate}
+   ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
+
+userCertificate    ATTRIBUTE  ::=  {
+     WITH SYNTAX   Certificate
+     EQUALITY MATCHING RULE   certificateExactMatch
+     ID  joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
+
+   An end entity may obtain one or more certificates from one or more
+   Certification Authorities.  The userCertificate attribute MUST be
+   used to represent these certificates in the directory entry
+   representing that user.
+
+3.2.  Certification Authorities
+
+   As with end entities, Certification Authorities are typically
+   represented in directories as auxiliary components of entries
+   representing a more generic object, such as organizations,
+   organizational units etc. The non PKIX-specific schema elements for
+   these entries, such as the structural object class of the object, are
+   outside the scope of this specification.
+
+   The following auxiliary object class MAY be used to represent
+   Certification Authorities:
+
+pkiCA   OBJECT-CLASS   ::= {
+   SUBCLASS OF   { top}
+   KIND          auxiliary
+   MAY CONTAIN   {cACertificate |
+                  certificateRevocationList |
+                  authorityRevocationList |
+                  crossCertificatePair }
+   ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
+
+cACertificate    ATTRIBUTE  ::=  {
+     WITH SYNTAX   Certificate
+     EQUALITY MATCHING RULE   certificateExactMatch
+     ID  joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
+
+crossCertificatePairATTRIBUTE::={
+   WITH SYNTAX   CertificatePair
+   EQUALITY MATCHING RULE certificatePairExactMatch
+ ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
+
+
+
+
+
+Boeyen, et al.              Standards Track                     [Page 3]
+
+RFC 2587                   PKIX LDAPv2 Schema                  June 1999
+
+
+   The cACertificate attribute of a CA's directory entry shall be used
+   to store self-issued certificates (if any) and certificates issued to
+   this CA by CAs in the same realm as this CA.
+
+   The forward elements of the crossCertificatePair attribute of a CA's
+   directory entry shall be used to store all, except self-issued
+   certificates issued to this CA.  Optionally, the reverse elements of
+   the crossCertificatePair attribute, of a CA's directory entry may
+   contain a subset of certificates issued by this CA to other CAs.
+   When both the forward and the reverse elements are present in a
+   single attribute value, issuer name in one certificate shall match
+   the subject name in the other and vice versa, and the subject public
+   key in one certificate shall be capable of verifying the digital
+   signature on the other certificate and vice versa.
+
+   When a reverse element is present, the forward element value and the
+   reverse element value need not be stored in the same attribute value;
+   in other words, they can be stored in either a single attribute value
+   or two attribute values.
+
+   In the case of V3 certificates, none of the above CA certificates
+   shall include a basicConstraints extension with the cA value set to
+   FALSE.
+
+   The definition of realm is purely a matter of local policy.
+
+      certificateRevocationListATTRIBUTE::={
+           WITH SYNTAX  CertificateList
+           EQUALITY MATCHING RULE certificateListExactMatch
+        ID joint-iso-ccitt(2) ds(5) attributeType(4)
+           certificateRevocationList(39)}
+
+   The certificateRevocationList attribute, if present in a particular
+   CA's entry, contains CRL(s) as defined in RFC 2459.
+
+      authorityRevocationListATTRIBUTE::={
+         WITH SYNTAX   CertificateList
+         EQUALITY MATCHING RULE certificateListExactMatch
+       ID joint-iso-ccitt(2) ds(5) attributeType(4)
+          authorityRevocationList(38)}
+
+   The authorityRevocationList attribute, if present in a particular
+   CA's entry, includes revocation information regarding certificates
+   issued to other CAs.
+
+
+
+
+
+
+
+Boeyen, et al.              Standards Track                     [Page 4]
+
+RFC 2587                   PKIX LDAPv2 Schema                  June 1999
+
+
+3.2.1.  CRL distribution points
+
+   CRL distribution points are an optional mechanism, specified in RFC
+   2459, which MAY be used to distribute revocation information.
+
+   A patent statement regarding CRL distribution points can be found at
+   the end of this document.
+
+   If a CA elects to use CRL distribution points, the following object
+   class is used to represent these.
+
+ cRLDistributionPoint   OBJECT-CLASS::= {
+    SUBCLASS OF     { top }
+    KIND            structural
+    MUST CONTAIN    { commonName }
+    MAY CONTAIN     { certificateRevocationList |
+                      authorityRevocationList |
+                      deltaRevocationList }
+    ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
+
+   The certificateRevocationList and authorityRevocationList attributes
+   are as defined above.
+
+   The commonName attribute and deltaRevocationList attributes, defined
+   in X.509, are duplicated below.
+
+      commonName   ATTRIBUTE::={
+         SUBTYPE OF     name
+         WITH SYNTAX   DirectoryString
+         ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
+
+      deltaRevocationList        ATTRIBUTE ::= {
+         WITH SYNTAX             CertificateList
+         EQUALITY MATCHING RULE  certificateListExactMatch
+         ID joint-iso-ccitt(2) ds(5) attributeType(4)
+            deltaRevocationList(53) }
+
+3.2.2.  Delta CRLs
+
+   Delta CRLs are an optional mechanism, specified in RFC 2459, which
+   MAY be used to enhance the distribution of revocation information.
+
+   If a CA elects to use delta CRLs, the following object class is used
+   to represent these.
+
+
+
+
+
+
+
+Boeyen, et al.              Standards Track                     [Page 5]
+
+RFC 2587                   PKIX LDAPv2 Schema                  June 1999
+
+
+      deltaCRL   OBJECT-CLASS::= {
+         SUBCLASS OF     { top }
+         KIND            auxiliary
+         MAY CONTAIN     { deltaRevocationList }
+         ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
+
+4.  Security Considerations
+
+   Since the elements of information which are key to the PKI service
+   (certificates and CRLs) are both digitally signed pieces of
+   information, no additional integrity service is REQUIRED.
+
+   Security considerations with respect to retrieval, addition,
+   deletion, and modification of the information supported by this
+   schema definition are addressed in RFC 2559.
+
+5.  References
+
+   [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
+        Protocol", RFC 1777, March 1995.
+
+   [2]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+6  Intellectual Property Rights
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+
+
+
+
+
+
+Boeyen, et al.              Standards Track                     [Page 6]
+
+RFC 2587                   PKIX LDAPv2 Schema                  June 1999
+
+
+7.  Authors' Addresses
+
+   Sharon Boeyen
+   Entrust Technologies Limited
+   750 Heron Road
+   Ottawa, Ontario
+   Canada K1V 1A7
+
+   EMail: sharon.boeyen@entrust.com
+
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 E. Middlefield Rd.
+   Mountain View, CA 94043
+   USA
+
+   EMail: howes@netscape.com
+
+
+   Patrick Richard
+   Xcert Software Inc.
+   Suite 1001, 701 W. Georgia Street
+   P.O. Box 10145
+   Pacific Centre
+   Vancouver, B.C.
+   Canada V7Y 1C6
+
+   EMail: patr@xcert.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boeyen, et al.              Standards Track                     [Page 7]
+
+RFC 2587                   PKIX LDAPv2 Schema                  June 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boeyen, et al.              Standards Track                     [Page 8]
+

doc/rfc/rfc2596.txt

+
+
+
+
+
+
+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]
+