home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-ldapv3-attributes-04.txt < prev    next >
Text File  |  1997-03-27  |  35KB  |  1,021 lines
  1.  
  2. Network Working Group                                            M. Wahl
  3. INTERNET-DRAFT                                       Critical Angle Inc.
  4. Obsoletes: RFC 1778                                          A. Coulbeck
  5.                                                            Isode Limited
  6.                                                                 T. Howes
  7.                                            Netscape Communications Corp.   
  8.                                                                 S. Kille
  9.                                                            Isode Limited
  10. Intended Category: Standards Track                         24 March 1997
  11.  
  12.  
  13.                   Lightweight Directory Access Protocol (v3):
  14.                        Attribute Syntax Definitions
  15.                  <draft-ietf-asid-ldapv3-attributes-04.txt> 
  16.  
  17. 1. Status of this Memo
  18.  
  19.    This document is an Internet-Draft.  Internet-Drafts are working 
  20.    documents of the Internet Engineering Task Force (IETF), its areas, and
  21.    its working groups.  Note that other groups may also distribute working
  22.    documents as Internet-Drafts.
  23.  
  24.    Internet-Drafts are draft documents valid for a maximum of six months
  25.    and may be updated, replaced, or obsoleted by other documents at any
  26.    time.  It is inappropriate to use Internet-Drafts as reference material
  27.    or to cite them other than as "work in progress."
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
  31.    Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  32.    ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  33.  
  34. 2. Abstract
  35.  
  36.    The Lightweight Directory Access Protocol (LDAP) [1] requires that the 
  37.    contents of AttributeValue fields in protocol elements be octet 
  38.    strings.  This document defines a set of syntaxes for LDAPv3, and the
  39.    rules by which attribute values of these syntaxes are represented as
  40.    octet strings for transmission in the LDAP protocol.  The syntaxes 
  41.    defined in this document are referenced by this and other documents that
  42.    define attribute types.  This document also defines the set of attribute
  43.    types which LDAP servers should support.
  44.  
  45. 3. Overview
  46.  
  47.    Section 4 states the general requirements and notations for attribute 
  48.    types, object classes, syntax and matching rule definitions.
  49.  
  50.    Section 5 lists attributes, section 6 syntaxes and section 7 object 
  51.    classes.
  52.  
  53. 4. General Issues
  54.  
  55.    This document describes encodings used in an Internet protocol. Terms are 
  56.    defined in [4].
  57.  
  58.  
  59.  
  60. Wahl, Coulbeck, Howes, Kille                                   Page 1
  61.  
  62. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  63.  
  64. 4.1. Attribute Types
  65.  
  66.    The attribute types are described by sample values for the subschema 
  67.    "attributeTypes" attribute, which is written in the 
  68.    AttributeTypeDescription syntax.  While lines have been folded for 
  69.    readability, the values transferred in protocol would not contain 
  70.    newlines.  
  71.  
  72.    The AttributeTypeDescription is encoded according to the following BNF,
  73.    and the productions for <oid>, <DirectoryStrings> and <DirectoryString>
  74.    are given in sections 4.2.1.
  75.  
  76.       <AttributeTypeDescription> ::= "("
  77.           <oid>   -- AttributeType identifier
  78.           [ "NAME" <DirectoryStrings> ] -- name used in AttributeType
  79.           [ "DESC" <DirectoryString> ]
  80.           [ "OBSOLETE" ]
  81.           [ "SUP" <oid> ]         -- derived from this other AttributeType
  82.           [ "EQUALITY" <oid> ]    -- Matching Rule name
  83.           [ "ORDERING" <oid> ]    -- Matching Rule name
  84.           [ "SUBSTR" <oid> ]      -- Matching Rule name 
  85.           [ "SYNTAX" <DirectoryString> ] -- see section 4.2
  86.           [ "SINGLE-VALUE" ]              -- default multi-valued
  87.           [ "COLLECTIVE" ]                -- default not collective
  88.           [ "NO-USER-MODIFICATION" ]      -- default user modifiable
  89.           [ "USAGE" <AttributeUsage> ]    -- default user applications
  90.           ")"
  91.     
  92.       <AttributeUsage> ::=
  93.           "userApplications"
  94.       |   "directoryOperation"
  95.       |   "distributedOperation"  -- DSA-shared
  96.       |   "dSAOperation"          -- DSA-specific, value depends on server
  97.  
  98.    Servers are not required to provide the same or any text 
  99.    in the description part of the subschema values they maintain.
  100.  
  101.    Servers SHOULD implement all the attribute types referenced in section 5: 
  102.    they MUST be able to perform equality matching of values, but need not 
  103.    perform any additional validity checks on attribute values.
  104.    
  105.    Servers MAY recognize additional names and attributes not listed in this
  106.    document, and if they do so, SHOULD publish the definitions of the types
  107.    in the attributeTypes attribute of their subschema subentries.
  108.  
  109.    AttributeDescriptions can be used as the value in a NAME part of an
  110.    AttributeTypeDescription.  Note that these are case insensitive.
  111.  
  112. 4.2. Syntaxes
  113.  
  114.    This section defines general requirements for LDAP attribute value
  115.    syntax encodings. All documents defining attribute syntax encodings for
  116.    use with LDAP are expected to conform to these requirements.
  117.  
  118.  
  119.  
  120. Wahl, Coulbeck, Howes, Kille                                   Page 2
  121.  
  122. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  123.  
  124.    The encoding rules defined for a given attribute syntax must produce
  125.    octet strings.  To the greatest extent possible, encoded octet
  126.    strings should be usable in their native encoded form for display
  127.    purposes. In particular, encoding rules for attribute syntaxes
  128.    defining non-binary values should produce strings that can be
  129.    displayed with little or no translation by clients implementing 
  130.    LDAP.  There are a few cases (e.g. Audio) however, when it is not sensible
  131.    to produce a printable representation, and clients MUST NOT assume that
  132.    an unrecognized syntax is a string representation.
  133.  
  134. 4.2.1. Common Encoding Aspects
  135.  
  136.    In these encodings where an arbitrary string is used as part of a larger 
  137.    production (other than a Distinguished Name), a backslash quoting mechanism 
  138.    is used to encode the following separator symbol character (such as ''', 
  139.    '$' or '#') if it should occur in that string.  The backslash is followed 
  140.    by a pair of hexadecimal digits representing the next character.  A 
  141.    backslash itself in the string which forms part of a larger syntax is   
  142.    always transmitted as '\5C' or '\5c'.
  143.  
  144.    For the purposes of defining the encoding rules for attribute syntaxes,
  145.    the following auxiliary BNF definitions will be used:
  146.  
  147.      <a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
  148.              'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
  149.              's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
  150.              'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
  151.              'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
  152.              'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
  153.  
  154.      <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
  155.  
  156.      <hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
  157.                       'A' | 'B' | 'C' | 'D' | 'E' | 'F'
  158.  
  159.      <k> ::= <a> | <d> | '-'
  160.  
  161.      <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
  162.              '/' | ':' | '?' | ' '
  163.  
  164.      <letterstring> ::= <a> | <a> <letterstring>
  165.  
  166.      <numericstring> ::= <d> | <d> <numericstring>
  167.  
  168.      <keystring> ::= <a> | <a> <anhstring>
  169.  
  170.      <anhstring> ::= <k> | <k> <anhstring>
  171.  
  172.      <printablestring> ::= <p> | <p> <printablestring>
  173.  
  174.      <space> ::= ' ' | ' ' <space>
  175.  
  176.      <whsp> ::= <space> | empty
  177.  
  178.  
  179.  
  180. Wahl, Coulbeck, Howes, Kille                                   Page 3
  181.  
  182. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  183.  
  184.      <utf8> ::= any sequence of octets formed from the UTF-8 [9]  
  185.                 transformation of a character from ISO 10646 [10]
  186.  
  187.      <dstring> ::= <utf8> | <utf8> <dstring>
  188.  
  189.      <DirectoryStrings> ::= <DirectoryString> | '(' <DirectoryStringList> ')'
  190.  
  191.      <DirectoryStringList> ::= <DirectoryStringList> <DirectoryString> | ""
  192.  
  193.      <DirectoryString> ::= ''' <dstring> '''
  194.   
  195.      <oids> ::= <oid> | '(' <oidlist> ')'
  196.     
  197.      <oidlist> ::= <oidlist> '$' <oid> | <oid>   
  198.  
  199. 4.2.2  Binary Transfer of Values
  200.  
  201.    This encoding format is used if the binary encoding is requested by the 
  202.    client for an attribute, or if the attribute syntax name is 'Binary'.  The 
  203.    value, an instance of the ASN.1 AttributeValue type, is BER-encoded, 
  204.    subject to the restrictions of section 5.1 of [1], and this sequence of 
  205.    octets is used as the value.  
  206.  
  207.    All servers MUST implement this form for both generating attribute values in
  208.    search responses, and parsing attribute values in add, compare and modify 
  209.    requests, if the attribute type is recognized and the attribute syntax name 
  210.    is 'Binary'.  Clients MUST be prepared receiving values in binary (e.g. 
  211.    userCertificate or audio), and MUST NOT simply display binary or 
  212.    unrecognized values to users.
  213.  
  214. 4.2.3. Syntax Names
  215.  
  216.    Names of syntaxes for use with LDAP are ASCII strings which either
  217.    begin with a letter and contain only letters or digits.  The names are 
  218.    case insensitive.  Historically since syntaxes correspond to ASN.1 types, 
  219.    they have been named starting with a capital letter.  A suggested minimum
  220.    upper bound on the number of characters in value with a DirectoryString or 
  221.    IA5String syntax or the number of bytes in a value for all other syntaxes
  222.    may be indicated by appending this bound count inside of curly braces. 
  223.    For instance, "DirectoryString{64}" suggests that server implementations
  224.    should allow the string to be 64 characters long, althoough they may allow 
  225.    longer strings.  Note that a single character of the DirectoryString may be 
  226.    encoded in more than one byte since UTF-8 is a variable-length encoding.
  227.  
  228.    Syntax names do not have global scope: two clients or servers may 
  229.    know of different syntaxes with the same name.  
  230.  
  231.    The definition of additional arbitrary syntaxes is strongly depreciated 
  232.    since it will hinder interoperability: today's client and server 
  233.    implementations generally do not have the ability to dynamically recognize
  234.    new syntaxes.  In most cases attributes will be defined with the 
  235.    DirectoryString syntax. 
  236.  
  237.  
  238.  
  239.  
  240. Wahl, Coulbeck, Howes, Kille                                   Page 4
  241.  
  242. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  243.  
  244. 4.3. Object Classes
  245.  
  246.    Object class descriptions are written according to the following BNF:
  247.  
  248.       <ObjectClassDescription> ::= "("
  249.           <oid>   -- ObjectClass identifier
  250.           [ "NAME" <DirectoryStrings> ]
  251.           [ "DESC" <DirectoryString> ]
  252.           [ "OBSOLETE" ]
  253.           [ "SUP" <oids> ]    -- Superior ObjectClasses
  254.           [ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ] -- default structural
  255.           [ "MUST" <oids> ]   -- AttributeTypes
  256.           [ "MAY" <oids> ]    -- AttributeTypes
  257.       ")"
  258.  
  259.    These are described as sample values for the subschema "objectClasses" 
  260.    attribute for a server which implements the LDAP schema.
  261.    While lines have been folded for readability, the values transferred in 
  262.    protocol would not contain newlines.
  263.  
  264.    Servers SHOULD implement all the object classes referenced in section 7, 
  265.    except for extensibleObject, which is optional.
  266.  
  267.    Servers MAY implement additional object classes not listed in this 
  268.    document, and if they do so, SHOULD publish the definitions of the classes
  269.    in the objectClasses attribute of their subschema subentries.  Later 
  270.    documents may define additional object classes.
  271.  
  272. 4.4. Matching Rules
  273.  
  274.    Matching rules are used by servers to compare attribute values against
  275.    assertion values when performing Search and Compare operations.  
  276.   
  277.    Most of the attributes given in this document will have an equality 
  278.    matching rule defined.
  279.  
  280.    Matching rule descriptions are written according to the following BNF:
  281.  
  282.       <MatchingRuleDescription> ::= "("
  283.           <oid>   -- MatchingRule identifier
  284.           [ "NAME" <DirectoryStrings> ]
  285.           [ "DESC" <DirectoryString> ]
  286.           [ "OBSOLETE" ]
  287.           "SYNTAX" <DirectoryString>
  288.          ")"
  289.  
  290.    Servers SHOULD implement all the matching rules in section 8.
  291.  
  292.    Servers MAY implement additional matching rules not listed in this 
  293.    document, and if they do so, SHOULD publish the definitions of the 
  294.    matching rules in the matchingRules attribute of their 
  295.    subschema subentries.
  296.  
  297.  
  298.  
  299.  
  300. Wahl, Coulbeck, Howes, Kille                                   Page 5 
  301.  
  302. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  303.  
  304. 5. Attribute Types
  305.  
  306.    All LDAP server implementations MUST recognize the attribute types 
  307.    defined in this section.  These types are based on definitions in 
  308.    X.501(93) [3].
  309.  
  310.    Servers SHOULD also recognize all the attributes from section 5 of [12],
  311.    from section 5 of [13]. 
  312.  
  313. 5.1. Standard Operational Attributes
  314.  
  315. 5.1.1. createTimestamp
  316.  
  317.     ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch
  318.       ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime' 
  319.       SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 
  320.  
  321. 5.1.2. modifyTimestamp
  322.  
  323.     ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch
  324.       ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime' 
  325.       SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 
  326.  
  327. 5.1.3. creatorsName
  328.  
  329.     ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch SYNTAX 'DN' 
  330.       SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 
  331.  
  332. 5.1.4. modifiersName
  333.  
  334.     ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch SYNTAX 'DN'
  335.       SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 
  336.  
  337. 5.1.5. subschemaSubentry
  338.  
  339.     The value of this attribute is the name of a subschema subentry, an 
  340.     entry in which the server makes available attributes specifying 
  341.     the schema. 
  342.  
  343.     ( 2.5.18.10 NAME 'subschemaSubentry' 
  344.       EQUALITY distinguishedNameMatch SYNTAX 'DN' NO-USER-MODIFICATION 
  345.       SINGLE-VALUE USAGE directoryOperation )
  346.  
  347. 5.1.6. attributeTypes
  348.  
  349.     ( 2.5.21.5 NAME 'attributeTypes' 
  350.       EQUALITY objectIdentifierFirstComponentMatch
  351.       SYNTAX 'AttributeTypeDescription' USAGE directoryOperation ) 
  352.  
  353. 5.1.7. objectClasses
  354.  
  355.     ( 2.5.21.6 NAME 'objectClasses' 
  356.       EQUALITY objectIdentifierFirstComponentMatch
  357.       SYNTAX 'ObjectClassDescription' USAGE directoryOperation ) 
  358.  
  359.  
  360. Wahl, Coulbeck, Howes, Kille                                   Page 6
  361.  
  362. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  363.  
  364. 5.2. LDAP Operational Attributes
  365.  
  366.    These attributes are only present in the root DSE.
  367.  
  368.    Servers MUST recognize these attribute names, but it is not required that 
  369.    a server provide values for these attributes, when the attribute 
  370.    corresponds to a feature which the server does not implement.
  371.  
  372. 5.2.1. namingContexts
  373.  
  374.    The values of this attribute correspond to naming contexts which this 
  375.    server masters or shadows.  If the server does not master any 
  376.    information (e.g. it is an LDAP gateway to a public X.500 directory) 
  377.    this attribute will be absent.  If the server believes it contains the 
  378.    entire directory, the attribute will have a single value, and that 
  379.    value will be the empty string (indicating the null DN of the root).
  380.    This attribute will allow a client to choose suitable base objects 
  381.    for searching when it has contacted a server.
  382.  
  383.     ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
  384.      SYNTAX 'DN' USAGE dSAOperation )
  385.  
  386. 5.2.2. altServer
  387.  
  388.    The values of this attribute are URLs of other servers which may be 
  389.    contacted when this server becomes unavailable.  If the server does not 
  390.    know of any other servers which could be used this attribute will be 
  391.    absent. Clients may cache this information in case their preferred LDAP 
  392.    server later becomes unavailable.
  393.  
  394.     ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
  395.      SYNTAX 'IA5String' USAGE dSAOperation )
  396.  
  397. 5.2.3. supportedExtension
  398.  
  399.    The values of this attribute are OBJECT IDENTIFIERs identifying the 
  400.    supported extended operations which the server supports.   
  401.  
  402.    If the server does not support any extensions this attribute will be 
  403.    absent.
  404.  
  405.     ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
  406.      SYNTAX 'OID' USAGE dSAOperation )
  407.  
  408. 5.2.4. supportedControl
  409.  
  410.    The values of this attribute are the OBJECT IDENTIFIERS identifying 
  411.    controls which the server supports.  If the server does not 
  412.    support any controls, this attribute will be absent.
  413.  
  414.     ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
  415.      SYNTAX 'OID' USAGE dSAOperation )
  416.  
  417.  
  418.  
  419.  
  420. Wahl, Coulbeck, Howes, Kille                                   Page 7
  421.  
  422. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  423.  
  424. 5.2.5. supportedSASLMechanisms
  425.  
  426.    The values of this attribute are the names of supported SASL
  427.    mechanisms which the server supports.  If the server does not 
  428.    support any mechanisms this attribute will be absent.
  429.  
  430.     ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
  431.      SYNTAX 'LDAPString' USAGE dSAOperation )
  432.  
  433. 5.2.6. supportedLDAPVersion
  434.  
  435.    The values of this attribute are the versions of the LDAP protocol which
  436.    the server implements.
  437.  
  438.     ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
  439.      SYNTAX 'INTEGER' USAGE dSAOperation )
  440.  
  441. 6. Syntaxes
  442.  
  443.    Servers SHOULD recognize all the syntaxes described in this section 
  444.    (6.1 - 6.3).
  445.  
  446. 6.1. AttributeTypeDescription
  447.  
  448.    Values with this syntax are encoded according to the BNF given at the
  449.    start of section 4.1. For example,
  450.  
  451.         ( 2.5.4.0 NAME 'objectClass' SYNTAX 'OID' )
  452.  
  453. 6.2. Audio
  454.  
  455.    The encoding of a value with Audio syntax is the octets of the value
  456.    itself, an 8KHz uncompressed encoding compatible with the SunOS 
  457.    4.1.3 'play' utility.
  458.  
  459. 6.3. BitString
  460.  
  461.    The encoding of a value with BitString syntax is according to the 
  462.    following BNF:
  463.  
  464.       <bitstring> ::= ''' <binary-digits> ''B' 
  465.  
  466.       <binary-digits> ::= '0' <binary-digits> | '1' <binary-digits> | 
  467.       empty
  468.  
  469.    Example:
  470.   
  471.         '0101111101'B
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480. Wahl, Coulbeck, Howes, Kille                                   Page 8
  481.  
  482. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  483.  
  484. 6.4. Boolean
  485.  
  486.    Values with Boolean syntax are encoded according to the following
  487.    BNF:
  488.  
  489.       <boolean> ::= "TRUE" | "FALSE"
  490.  
  491.    Boolean values have an encoding of "TRUE" if they are logically true,
  492.    and have an encoding of "FALSE" otherwise.
  493.  
  494. 6.5. Certificate
  495.  
  496.    Because of the changes from X.509(1988) and X.509(1993) and additional 
  497.    changes to the ASN.1 definition to support certificate extensions, no 
  498.    string representation is defined, and values with Certificate syntax 
  499.    MUST only be transferred using the binary encoding, by requesting or 
  500.    returning the attributes with descriptions "userCertificate;binary" or 
  501.    "caCertificate;binary".  The BNF notation in RFC 1778 for 
  502.    "User Certificate" is not recommended to be used.
  503.  
  504. 6.6. CertificateList
  505.  
  506.    Because of the incompatibility of the X.509(1988) and X.509(1993) 
  507.    definitions of revocation lists, values with CertificateList syntax
  508.    MUST only be transferred using a binary encoding, by requesting or 
  509.    returning the attributes with descriptions 
  510.    "certificateRevocationList;binary" or "authorityRevocationList;binary".  
  511.    The BNF notation in RFC 1778 for "Authority Revocation List" is not 
  512.    recommended to be used.
  513.  
  514. 6.7. CertificatePair
  515.  
  516.    Because the Certificate is being carried in binary, values with 
  517.    CertificatePair syntax MUST only be transferred using a binary encoding, 
  518.    by requesting or returning the attribute description 
  519.    "crossCertificatePair;binary".  The BNF notation in RFC 1778 for 
  520.    "Certificate Pair" is not recommended to be used.
  521.  
  522. 6.8. CountryString
  523.  
  524.    A value of CountryString syntax is encoded the same as a value of
  525.    DirectoryString syntax.  Note that this syntax is limited to values of
  526.    exactly two printable string characters.
  527.  
  528.       <CountryString>  ::= <p> <p>
  529.  
  530.    Example:
  531.       US
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540. Wahl, Coulbeck, Howes, Kille                                   Page 9
  541.  
  542. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  543.  
  544. 6.9. DN
  545.  
  546.    Values with DN (Distinguished Name) syntax are encoded to have the
  547.    representation defined in [5].  Note that this representation is not 
  548.    reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as 
  549.    the CHOICE of any DirectoryString element in an RDN is no longer known.
  550.  
  551.    Examples (from [5]):
  552.       CN=Steve Kille,O=Isode Limited,C=GB
  553.       OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
  554.       CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
  555.       CN=Before\0DAfter,O=Test,C=GB
  556.       1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
  557.       SN=Lu\C4\8Di\C4\C7
  558.  
  559. 6.10. DirectoryString
  560.  
  561.    A string with DirectoryString syntax is encoded in the UTF-8 form of 
  562.    ISO 10646 (a superset of Unicode).  Servers and clients MUST be prepared to 
  563.    receive encodings of arbitrary Unicode characters, including characters
  564.    not presently assigned to any character set, in values.
  565.  
  566.    For characters in the PrintableString form, the value is encoded as the 
  567.    string value itself.
  568.  
  569.    If it is of the TeletexString form, then the characters are transliterated
  570.    to their equivalents in UniversalString, and encoded in UTF-8 [9].
  571.  
  572.    If it is of the UniversalString or BMPString forms [10], UTF-8 is used to 
  573.    encode them.  
  574.  
  575.    Note: the form of DirectoryString is not indicated in protocol unless the
  576.    attribute value is carried in binary.  Servers which convert to DAP MUST
  577.    choose an appropriate form.  Servers MUST NOT reject values merely because 
  578.    they contain legal Unicode characters outside of the range of printable 
  579.    ASCII.
  580.  
  581.    Example:
  582.  
  583.       This is a string of DirectoryString containing #!%#@
  584.  
  585. 6.11. DITContentRuleDescription
  586.  
  587.    Values with this syntax are encoded according to the following BNF:
  588.  
  589.       <DITContentRuleDescription> ::= "("
  590.           <oid>   -- Structural ObjectClass identifier
  591.           [ "NAME" <DirectoryStrings> ]
  592.           [ "DESC" <DirectoryString> ]
  593.           [ "OBSOLETE" ]
  594.           [ "AUX" <oids> ]    -- Auxiliary ObjectClasses
  595.           [ "MUST" <oids> ]   -- AttributeType identifiers
  596.           [ "MAY" <oids> ]    -- AttributeType identifiers
  597.           [ "NOT" <oids> ]    -- AttributeType identifiers
  598.          ")"
  599.  
  600. Wahl, Coulbeck, Howes, Kille                                   Page 10
  601.  
  602. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  603.  
  604. 6.12. FacsimileTelephoneNumber
  605.  
  606.    Values with the FacsimileTelephoneNumber syntax are encoded according  
  607.    to the following BNF:
  608.  
  609.       <fax-number> ::= <printablestring> [ '$' <faxparameters> ]
  610.  
  611.       <faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
  612.  
  613.       <faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
  614.                    'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
  615.  
  616.    In the above, the first <printablestring> is the actual fax number,
  617.    and the <faxparm> tokens represent fax parameters.
  618.  
  619. 6.13. Fax
  620.  
  621.    Values with Fax syntax are encoded as if they were octet strings
  622.    containing Group 3 Fax images as defined in [7].
  623.  
  624. 6.14. GeneralizedTime
  625.  
  626.    Values of this syntax are encoded as printable strings, represented 
  627.    as specified in X.208.  Note that the time zone must be specified.
  628.    It is strongly recommended that Zulu time zone be used.  For example, 
  629.         
  630.                 199412161032Z
  631.  
  632. 6.15. IA5String
  633.  
  634.    The encoding of a value with IA5String syntax is the string value
  635.    itself.
  636.  
  637. 6.16. INTEGER
  638.  
  639.    Values with INTEGER syntax are encoded as the decimal representation  
  640.    of their values, with each decimal digit represented by the its 
  641.    character equivalent. So the number 1321 is represented by the character 
  642.    string "1321".
  643.  
  644. 6.17. JPEG
  645.  
  646.    Values with JPEG syntax are encoded as if they were octet strings
  647.    containing JPEG images in the JPEG File Interchange Format (JFIF), as
  648.    described in [8].
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660. Wahl, Coulbeck, Howes, Kille                                   Page 11
  661.  
  662. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  663.  
  664. 6.18. MatchingRuleUseDescription
  665.  
  666.    Values of this syntax are encoded according to the following BNF:
  667.  
  668.       <MatchingRuleUseDescription> ::= "("
  669.           <oid>   -- MatchingRule identifier
  670.           [ "NAME" <DirectoryStrings> ]
  671.           [ "DESC" <DirectoryString> ]
  672.           [ "OBSOLETE" ]
  673.          "APPLIES" <oids>    -- AttributeType identifiers
  674.          ")"
  675.  
  676. 6.19. MHSORAddress
  677.  
  678.    Values of type MHSORAddress are encoded as strings, according to
  679.    the format defined in [11].
  680.  
  681. 6.20. NameAndOptionalUID
  682.  
  683.    The encoding of a value with the NameAndOptionalUID syntax is according
  684.    to the following BNF:
  685.  
  686.       <NameAndOptionalUID> ::= 
  687.                 <DistinguishedName> [ '#' <bitstring> ]
  688.  
  689.    Although the '#' character may occur in a string representation of a 
  690.    distinguished name, no additional special quoting is done.
  691.  
  692.    This syntax has been added subsequent to RFC 1778.
  693.  
  694.    Example:
  695.  
  696.       1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
  697.  
  698. 6.21. NameFormDescription
  699.  
  700.    Values of this syntax are encoded according to the following BNF:
  701.  
  702.       <NameFormDescription> ::= "("
  703.           <oid>   -- NameForm identifier
  704.           [ "NAME" <DirectoryStrings> ]
  705.           [ "DESC" <DirectoryString> ]
  706.           [ "OBSOLETE" ]
  707.           "OC" <oid>          -- Structural ObjectClass
  708.           "MUST" <oids>       -- AttributeTypes
  709.           [ "MAY" <oids> ]    -- AttributeTypes
  710.       ")"
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720. Wahl, Coulbeck, Howes, Kille                                   Page 12
  721.  
  722. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  723.  
  724. 6.22. NumericString
  725.  
  726.    The encoding of a string with the NumericString syntax is the string
  727.    value itself. Example:
  728.   
  729.       1997
  730.  
  731.  
  732. 6.23. ObjectClassDescription
  733.  
  734.    Values of this syntax are encoded according to the BNF in section 4.3.
  735.  
  736. 6.24. OID
  737.  
  738.    Values with OID (Object Identifier) syntax are encoded according to the
  739.    following BNF:
  740.  
  741.       <oid> ::= <descr> | <numericoid>
  742.  
  743.       <descr> ::= <keystring>
  744.  
  745.       <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
  746.  
  747.    In the above BNF, <descr> is the syntactic representation of an
  748.    object descriptor, which consists of letters and digits, starting 
  749.    with a letter. When encoding values with OID syntax, the first encoding
  750.    option MUST be used in preference to the second. That is, in encoding 
  751.    object identifiers, object descriptors (where assigned and known by 
  752.    the implementation) must be used in preference to numeric oids to 
  753.    the greatest extent possible. All permitted object descriptors for use
  754.    in LDAP are given in this document.  No other object descriptors may be 
  755.    used.  (Note that clients should expect that LDAPv2 implementations 
  756.    will return object descriptors other than those listed.)
  757.  
  758.    Example:
  759.  
  760.        1.2.3.4
  761.        cn
  762.  
  763. 6.25. OtherMailbox
  764.  
  765.    Values of the OtherMailbox syntax are encoded according to the
  766.    following BNF:
  767.  
  768.       <otherMailbox> ::= <mailbox-type> '$' <mailbox>
  769.  
  770.       <mailbox-type> ::= an encoded Printable String
  771.  
  772.       <mailbox> ::= an encoded IA5 String
  773.  
  774.    In the above, <mailbox-type> represents the type of mail system in
  775.    which the mailbox resides, for example "MCIMail"; and <mailbox> is the 
  776.    actual mailbox in the mail system defined by <mailbox-type>.
  777.  
  778.  
  779.  
  780. Wahl, Coulbeck, Howes, Kille                                   Page 13
  781.  
  782. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  783.  
  784. 6.26. Password
  785.  
  786.    Values with Password syntax are encoded as octet strings.
  787.  
  788.    Example: 
  789.  
  790.       secret
  791.  
  792. 6.27. PostalAddress
  793.  
  794.    Values with the PostalAddress syntax are encoded according to the 
  795.    following BNF:
  796.  
  797.       <postal-address> ::= <dstring> | <dstring> '$' <postal-address>
  798.  
  799.    In the above, each <dstring> component of a postal address value is
  800.    encoded as a value of type DirectoryString syntax.  Backslashes and 
  801.    dollar characters, if they occur in the component, are quoted as 
  802.    described in section 4.2. 
  803.  
  804.    Example:
  805.  
  806.       1234 Main St.$Anytown, CA 12345$USA
  807.       \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
  808.  
  809. 6.28. PresentationAddress
  810.  
  811.    Values with the PresentationAddress syntax are encoded to have the
  812.    representation described in [6].
  813.  
  814. 6.29. PrintableString
  815.  
  816.    The encoding of a value with PrintableString syntax is the string
  817.    value itself.  PrintableString is limited to the characters in 
  818.    production <p> of section 4.1.
  819.  
  820.    Example:
  821.  
  822.       This is a PrintableString
  823.  
  824. 6.30. TelephoneNumber
  825.  
  826.    Values with the TelephoneNumber syntax are encoded as if they were
  827.    Printable String types.  Telephone numbers are recommended in X.520 to
  828.    be in international form.  
  829.  
  830.    Example:
  831.  
  832.       +1 512 305 0280
  833.  
  834. 6.31. UTCTime
  835.  
  836.    Values with UTCTime syntax are encoded as if they were printable
  837.    strings with the strings containing a UTCTime value.  This is historical;
  838.    new attribute definitions will use GeneralizedTime instead.
  839.  
  840. Wahl, Coulbeck, Howes, Kille                                   Page 14
  841.  
  842. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  843.  
  844. 7. Object Classes
  845.  
  846.    Servers SHOULD recognize all the names of standard classes from section
  847.    7 of [12], as well as the names of the Internet classes from section
  848.    7 of [13].
  849.  
  850. 7.1. Extensible Object Class
  851.  
  852.    The extensibleObject object class, if present in an entry, permits that 
  853.    entry to optionally hold any attribute.  The MAY attribute list of this 
  854.    class is implicitly the set of all attributes known to the server.  
  855.  
  856.     ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 
  857.       SUP top AUXILIARY )  
  858.  
  859.    The mandatory attributes of the other object classes of this entry are 
  860.    still required to be present. 
  861.  
  862.    Note that not all servers will implement this object class, and those 
  863.    which do not will reject requests to add entries which contain this 
  864.    object class, or modify an entry to add this object class.
  865.  
  866. 8. Matching Rules
  867.  
  868.    Servers which implement extensibleMatch SHOULD recognize the following 
  869.    matching rules, used for equality matching, and be capable of 
  870.    performing the matching rules.  For all these rules, the
  871.    assertion syntax is the same as the value syntax.
  872.  
  873.     ( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 'OID' )
  874.     ( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 'DN' )
  875.     ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 'DirectoryString' )
  876.     ( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 'NumericString' )
  877.     ( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 'PostalAddress' )
  878.     ( 2.5.13.14 NAME 'integerMatch' SYNTAX 'INTEGER' )
  879.     ( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 'BitString' )  
  880.     ( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 'Password' )
  881.     ( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 'TelephoneNumber' )
  882.     ( 2.5.13.22 NAME 'presentationAddressMatch' SYNTAX 'PresentationAddress' )
  883.     ( 2.5.13.23 NAME 'uniqueMemberMatch' SYNTAX 'NameAndOptionalUID' )
  884.     ( 2.5.13.24 NAME 'protocolInformationMatch' SYNTAX 'ProtocolInformation' )
  885.     ( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 'GeneralizedTime' )
  886.     ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 'IA5String' )
  887.     ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 'IA5String' )
  888.  
  889.    When performing the caseIgnoreMatch, caseIgnoreListMatch, 
  890.    telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
  891.    multiple adjoining whitespace characters are treated the same as an 
  892.    individual space, and leading and trailing whitespace is ignored.
  893.  
  894. 9. Security Considerations
  895.  
  896.    Security issues are not discussed in this memo.
  897.  
  898.  
  899.  
  900. Wahl, Coulbeck, Howes, Kille                                   Page 15
  901.  
  902. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  903.  
  904. 10. Acknowledgements
  905.  
  906.    This document is based substantially on RFC 1778, written by Tim Howes,
  907.    Steve Kille, Wengyik Yeong and Colin Robbins.
  908.  
  909.    Many of the attribute syntax encodings defined in this document are
  910.    adapted from those used in the QUIPU and the IC R3 X.500 
  911.    implementations. The contributions of the authors of both these 
  912.    implementations in the specification of syntaxes in this document are 
  913.    gratefully acknowledged.
  914.  
  915. 11. Authors Addresses
  916.  
  917.        Mark Wahl
  918.        Critical Angle Inc.
  919.        4815 West Braker Lane #502-385
  920.        Austin, TX 78759
  921.        USA
  922.  
  923.        EMail:  M.Wahl@critical-angle.com
  924.  
  925.  
  926.        Andy Coulbeck
  927.        Isode Limited
  928.        The Dome, The Square
  929.        Richmond  TW9 1DT
  930.        United Kingdom
  931.  
  932.        Phone:  +44 181-332-9091
  933.        EMail:  A.Coulbeck@isode.com
  934.  
  935.        Tim Howes
  936.        Netscape Communications Corp.
  937.        501 E. Middlefield Rd
  938.        Mountain View, CA 94043
  939.        USA
  940.        
  941.        Phone:  +1 415 254-1900
  942.        EMail:   howes@netscape.com
  943.  
  944.  
  945.        Steve Kille
  946.        Isode Limited
  947.        The Dome, The Square
  948.        Richmond
  949.        TW9 1DT
  950.        UK
  951.  
  952.        Phone:  +44-181-332-9091
  953.        EMail:  S.Kille@isode.com
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960. Wahl, Coulbeck, Howes, Kille                                   Page 16
  961.  
  962. INTERNET-DRAFT   LDAPv3 Attribute Syntax Definitions           March 1997
  963.  
  964. 12. Bibliography
  965.  
  966.    [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 
  967.        (Version 3)", INTERNET-DRAFT <draft-ietf-asid-ldapv3-protocol-04.txt>, 
  968.        March 1997.
  969.  
  970.    [2] The Directory: Selected Attribute Types.  ITU-T Recommendation 
  971.        X.520, 1993.
  972.  
  973.    [3] The Directory: Models. ITU-T Recommendation X.501, 1993.
  974.  
  975.    [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 
  976.        Levels", INTERNET-DRAFT <draft-bradner-key-words-03.txt>.
  977.    
  978.    [5] M. Wahl, S. Kille, "A UTF-8 String Representation of Distinguished 
  979.        Names", INTERNET-DRAFT <draft-ietf-asid-ldapv3-dn-02.txt>, 
  980.        March 1997.
  981.  
  982.    [6] S. Kille, "A String Representation for Presentation Addresses",
  983.        RFC 1278, University College London, November 1991.
  984.  
  985.    [7] Terminal Equipment and Protocols for Telematic Services -
  986.        Standardization of Group 3 facsimile apparatus for document
  987.        transmission.  CCITT, Recommendation T.4.
  988.  
  989.    [8] JPEG File Interchange Format (Version 1.02).  Eric Hamilton, 
  990.        C-Cube Microsystems, Milpitas, CA, September 1, 1992.
  991.  
  992.    [9] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 
  993.        10646", RFC 2044, October 1996.
  994.  
  995.    [10] Universal Multiple-Octet Coded Character Set (UCS) - Architecture
  996.         and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.
  997.  
  998.    [11] H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson,
  999.         "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
  1000.         August 1993.
  1001.  
  1002.    [12] M. Wahl, "X.500(93) User Schema for use with LDAP", 
  1003.         INTERNET-DRAFT <draft-ietf-asid-ldapv3schema-x500-00.txt>,
  1004.         March 1997.
  1005.  
  1006.    [13] M. Wahl, "Pilot Internet Schema for use with LDAP", 
  1007.         INTERNET-DRAFT <draft-ietf-asid-ldapv3schema-pilot-00.txt>,
  1008.         March 1997.
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018. <draft-ietf-asid-ldapv3-attributes-04.txt> 
  1019. Expires: September 1997
  1020. Wahl, Coulbeck, Howes, Kille                                   Page 17
  1021.