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-ldapv3ext-03.txt < prev    next >
Text File  |  1997-04-16  |  26KB  |  556 lines
  1. ASID Working Group                                            Y. Yaacovi     
  2. INTERNET-DRAFT                                                 Microsoft
  3.                                                                  M. Wahl
  4.                                                      Critical Angle Inc.
  5.                                                                K. Settle
  6.                                                                Microsoft
  7.                                                              T. Genovese
  8.                                                                Microsoft
  9.  
  10. Expires in six months from                                 25 March 1997
  11. Intended Category: Standards Track
  12.  
  13.  
  14.                    Lightweight Directory Access Protocol:
  15.                   Extensions for Dynamic Directory Services
  16.                     <draft-ietf-asid-ldapv3ext-03.txt>
  17.  
  18. 1. Status of this Memo
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its areas,
  22.    and its working groups.  Note that other groups may also distribute
  23.    working documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet-Drafts as reference
  28.    material or to cite them other than as "work in progress."
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  32.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  33.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  34.  
  35. 2.  Abstract
  36.  
  37.    This document defines the requirements for dynamic directory services
  38.    and specifies the format of request and response extended operations
  39.    for supporting client-server interoperation in a dynamic directories
  40.    environment.
  41.  
  42.    The Lightweight Directory Access Protocol (LDAP) [1] supports
  43.    lightweight access to static directory services, allowing relatively
  44.    fast search and update access.  Static directory services store
  45.    information about people that persists in its accuracy and value over
  46.    a long period of time.
  47.    
  48.    Dynamic directory services are different in that they store
  49.    information about people that only persists in its accuracy and value
  50.    when it is being periodically refreshed.  This information is stored
  51.    as dynamic entries and/or dynamic attributes.  A typical use will be a
  52.    client or a person that is either online - in which case it has an
  53.    entry or attributes in the directory, or is offline - in which case
  54.    its entry or attributes disappear from the directory.  Though the
  55.    protocol operations and attributes used by dynamic directory services
  56.    are similar to the ones used for static directory services, clients
  57.    that store dynamic information in the directory need to periodically
  58.    refresh this information, in order to prevent it from disappearing.
  59.    If dynamic entries or attributes are not refreshed within a given
  60.    timeout, they will be removed from the directory.  For example, this
  61.    will happen if the client that set them goes offline.
  62.  
  63.    In addition, static directories may include dynamic information, in
  64.    the form of dynamic attributes in an otherwise static entry.  Such
  65.    information needs to be refreshed periodically in the same manner.
  66.  
  67.    A flow control mechanism from the server is also described that allows
  68.    a server to inform clients how often they should refresh their
  69.    presence.
  70.    
  71. 3. Requirements
  72.  
  73.    The protocol extensions must allow accessing dynamic information in a
  74.    directory in a standard LDAP manner, to allow clients to access static
  75.    and dynamic information in the same way. 
  76.  
  77.    By definition, dynamic entries or dynamic attributes are not
  78.    persistent and clients may go away gracefully or not.  The proposed
  79.    extensions must offer a way for a server to tell if entries or
  80.    attributes are still valid, and to do this in a way that is scalable.
  81.    There also must be a mechanism for clients to reestablish their entry
  82.    or attributes with the server.
  83.  
  84.    Finally, to allow clients to broadly use the dynamic extensions, the
  85.    extensions need to be registered as standard LDAP extended operations.
  86.  
  87. 4. Description of Approach
  88.  
  89.    The Lightweight Directory Access Protocol (LDAP) [1] permits
  90.    additional operation requests and responses to be added to the
  91.    protocol.  This proposal takes advantage of these to support
  92.    directories which contain dynamic information in a manner which
  93.    is fully integrated with LDAP.
  94.  
  95.    The approach described in this proposal defines dynamic entries and
  96.    dynamic attributes in order to allow implementing directories with
  97.    dynamic information.  An implementation of dynamic directories, must
  98.    be able to support both dynamic directory entries and dynamic
  99.    attributes.
  100.  
  101. 4.1. Dynamic Entries and the dynamicObject object class
  102.  
  103.    A dynamic entry is an object in the directory tree which has a
  104.    time-to-live associated with it.  This time-to-live is set when the
  105.    entry is created.  The time-to-live is automatically decremented, and
  106.    when it expires the dynamic entry disappears.  By invoking the refresh
  107.    extended operation (defined below) to re-set the time-to-live, a
  108.    client can cause the entry to remain present a while longer.
  109.  
  110.    A dynamic entry is created by including the objectClass value given in
  111.    section 6 in the list of attributes when adding an entry.  This method
  112.    is subject to standard access control restrictions.
  113.  
  114.    The extended operation covered here, allows a client to refresh a
  115.    dynamic entry by invoking at intervals refresh operations containing
  116.    that entry's name.  Dynamic entries will be treated the same as
  117.    non-dynamic entries when processing search, compare, add, delete,
  118.    modify and modifydn operations.  However if clients stop sending
  119.    refresh operations for an entry, then the server will automatically
  120.    and without notification remove that entry from the directory.  This
  121.    removal will be treated the same as if the entry had been deleted by
  122.    an LDAP protocol operation.
  123.  
  124.    There is no way to change a static entry into a dynamic one and vice-
  125.    versa.  If the client is using Modify with an objectClass of
  126.    dynamicObject on a static entry, the server must return a service
  127.    error either "objectClassModsProhibited" (if the server does not allow
  128.    objectClass modifications at all) or "objectClassViolation" (if the
  129.    server does allow objectClass modifications in general).
  130.  
  131.    A dynamic entry may be removed by the client using the delete
  132.    operation.  This operation will be subject to access control
  133.    restrictions.
  134.  
  135.    A non-dynamic entry cannot be added subordinate to a dynamic entry:
  136.    the server must return an appropriate update or service error if this
  137.    is attempted.
  138.  
  139. 4.2. Dynamic Attributes
  140.  
  141.    A similar concept is dynamic attributes.  These attributes behave the
  142.    same as ordinary user attributes to Search, Compare and Modify
  143.    requests, except that if they time out they disappear from the entry
  144.    in which they are located.  (Unlike the dynamicObject class, the entry
  145.    itself does not disappear, and non-dynamic attributes are unaffected).
  146.    Like dynamic entries, a static entry with dynamic attributes must have
  147.    the entryTtl attribute which is described in section 6 below.
  148.  
  149.    Dynamic attributes do not necessarily introduce a new set of
  150.    attributes in the schema.  Any static attribute in the schema can be
  151.    made dynamic by including the ;dynamic attribute modifier with the
  152.    typename.  It is allowed to introduce new dynamic attributes which are
  153.    not useful in the static domain.  Such attributes will still require
  154.    including the ;dynamic attribute modifier with the typename to define
  155.    them as dynamic.
  156.  
  157.    A dynamic attribute may be a subtype of a non-dynamic attribute, but a
  158.    non-dynamic attribute must not be a subtype of a dynamic attribute.
  159.    Operational attributes and collective attributes must not be dynamic.
  160.    All dynamic attributes are considered to be user attributes, however
  161.    they are not guaranteed to be present in shadow copies of entries.
  162.  
  163.    A client may introduce dynamic attributes into an entry by using a
  164.    Modify request to add them, or by including them in the attribute list
  165.    of an Add Request.  If the attribute type is permitted in the entry
  166.    then the dynamic attribute is also permitted.  The client would
  167.    specify that the attribute is dynamic by including the tag ";dynamic"
  168.    with the typename.  Dynamic values may be changed, and the attributes
  169.    removed, by using the Modify request as normal.  If the entry is
  170.    deleted, dynamic attributes disappear immediately along with all the
  171.    non-dynamic.  A ;dynamic modifier on an attribute may not be used in a
  172.    compare request, or in a search request (either in the filter or
  173.    attributes requested for return).  This is in keeping with the
  174.    philosophy that dynamic attributes be indistinguishable from static
  175.    attributes as much as possible. In such a case, a server is expected
  176.    to reject the request, returning 'invalidAttributeSyntax'.
  177.  
  178.    The granularity of a dynamic attribute is the entire attribute
  179.    including all values.  Dynamic and static values may not be mixed
  180.    within a single attribute.  For example, suppose an existing static
  181.    entry had an attribute called "ipAddress" with the value "1.2.3.4".  A
  182.    modification of the entry to add the value "5.4.3.2" to the attribute
  183.    "ipAddress;dynamic" would fail with a "constraintViolation" error.
  184.  
  185.    The addition and modification of dynamic attributes are subject to
  186.    schema and access control restrictions, as with non-dynamic
  187.    attributes.  Thus unless the extensibleObject object class is present,
  188.    generally an object class or content rule must be defined to permit
  189.    those attributes to be present in an entry.  If their presence is
  190.    controlled by an object class, then just as with non-dynamic
  191.    attributes, the object class value must have already been added before
  192.    the attributes are added.  The dynamicObject object class described in
  193.    section 4.1 does not itself permit any particular dynamic attributes.
  194.  
  195.    Dynamic attributes in a particular entry are refreshed using the
  196.    Refresh extended operation.  All of the entry's dynamic attributes are
  197.    refreshed by a single refresh request.  The TTL given in the refresh
  198.    response applies to all of the entry's dynamic attributes.  There is
  199.    no way to refresh particular dynamic attributes within an entry at
  200.    different times, or to have different TTLs apply to different dynamic
  201.    attributes.
  202.  
  203.    If not refreshed, all dynamic attributes in an entry time out
  204.    simultaneously.  All the attributes which are dynamic with all their
  205.    values disappear atomically, as if the server had done a ModifyEntry
  206.    specifying that all the dynamic types were to be deleted from that
  207.    entry.  The client must not expect any dynamic attributes to be
  208.    present in an entry after the time-to-live for that entry has reached
  209.    zero.  However the attributes may not disappear immediately as servers
  210.    may only process timing out attributes at intervals (e.g.  every few
  211.    minutes).
  212.  
  213.    Note that if an object class definition references a dynamic attribute
  214.    as a mandatory attribute, the entry will still time out, but a schema
  215.    inconsistency will be present in that entry.  (The objectClass
  216.    attribute and its values always remain since objectClass is not a
  217.    dynamic attribute.) Thus it is strongly recommended that designers not
  218.    specify dynamic attributes as anything other than optional attributes
  219.    of auxiliary classes.
  220.  
  221.    Dynamic attributes may be used within dynamic entries (i.e., entries
  222.    containing object class "dynamicObject", defined below), but since all
  223.    of such an entry's attributes are implicitly dynamic, such use is
  224.    superfluous.
  225.   
  226.  
  227. 5. Protocol Additions
  228.  
  229. 5.1 Refresh Request
  230.  
  231.    Refresh is a protocol operation sent by a client to tell the server
  232.    that the client is still alive and the dynamic directory entry or the
  233.    dynamic attributes of the entry are still accurate and valuable.  The
  234.    client sends a Refresh request periodically based on the value of the
  235.    client refresh period (CRP).  The server can request that the client
  236.    change this value.  As long as the server receives a Refresh request
  237.    within the timeout period, the directory entry is guaranteed to
  238.    persist on the server.  Clients implementers should be aware that
  239.    since the intervening network between the client and server is
  240.    unreliable, a Refresh request packet may be delayed or lost while in
  241.    transit.  If this occurs, the entry or the dynamic attributes may
  242.    disappear, and the client will need to detect this and re-add the
  243.    entry or the attributes.
  244.  
  245.    A client may request this operation by transmitting an LDAP PDU
  246.    containing an ExtendedRequest.  An LDAP ExtendedRequest is defined as
  247.    follows:
  248.  
  249.          ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
  250.                  requestName             [0] LDAPOID,
  251.                  requestValue            [1] OCTET STRING }
  252.         
  253.    The requestName field must be set to the string
  254.    "1.3.6.1.4.1.1466.101.119.1".
  255.  
  256.    The requestValue field will contain as a value the DER-encoding of the
  257.    following ASN.1 data type:
  258.  
  259.         SEQUENCE {
  260.                 entryName  [0] LDAPDN,
  261.                 requestTtl [1] INTEGER
  262.         }
  263.  
  264.    The entryName field is the UTF-8 string representation of the name of
  265.    the dynamic entry or the entry containing dynamic attributes [3].
  266.    This entry must already exist.
  267.  
  268.    The requestTtl is a time in seconds (between 1 and 31557600) that the
  269.    client requests that the entry or the dynamic attributes exists in the
  270.    directory before being automatically removed.  Servers are not
  271.    required to accept this value and might return a different TTL value
  272.    to the client.  Clients must be able to use this server-dictated value
  273.    as their CRP.
  274.  
  275. 5.2 Refresh Response
  276.  
  277.    If a server implements this extension, then when the request is made
  278.    it will return an LDAP PDU containing an ExtendedResponse.  An LDAP
  279.    ExtendedResponse is defined as follows:
  280.  
  281.         ExtendedResponse ::= [APPLICATION 24] SEQUENCE {      
  282.                 responseName            [0] LDAPOID OPTIONAL,
  283.                 response                [1] OCTET STRING OPTIONAL,
  284.                 standardResponse        [2] LDAPResult }
  285.  
  286.    The responseName field contains the same string as that present in the
  287.    request.
  288.  
  289.    The response field will contain as a value the DER-encoding of the
  290.    following ASN.1 data type:
  291.  
  292.         SEQUENCE {
  293.                 responseTtl [1] INTEGER
  294.         }
  295.  
  296.    The responseTtl field is the time in seconds which the server chooses
  297.    to have as the time-to-live field for that entry.  It must not be any
  298.    smaller than that which the client requested, and it may be larger.
  299.    Please note that for the case of a static entry with dynamic
  300.    attributes, this time-to-live applies to all the dynamic attributes in
  301.    this entry.
  302.  
  303.    If the operation was successful, the errorCode field in the
  304.    standardResponse part of an ExtendedResponse will be set to success.
  305.  
  306.    In case of an error, the responseTtl field will have the value 0, and
  307.    the errorCode field will contain an appropriate value, as follows: If
  308.    the entry named by entryName could not be located, the errorCode field
  309.    will contain "noSuchObject".  If the entry is not dynamic, or does not
  310.    have dynamic attributes, the errorCode field will contain
  311.    "objectClassViolation".  If the requester does not have permission to
  312.    refresh the entry, the errorCode field will contain
  313.    "insufficientAccessRights".  If the requestTtl field is too large, the
  314.    errorCode field will contain "sizeLimitExceeded".
  315.  
  316.    If a server does not implement this extension, it will return an LDAP
  317.    PDU containing an ExtendedResponse, which contains only the
  318.    standardResponse element (the responseName and response elements will
  319.    be absent).  The LDAPResult element will indicate the protocolError
  320.    result code.
  321.  
  322.    This request is permitted to be invoked when LDAP is carried by a
  323.    connectionless transport.
  324.  
  325.    When using a connection-oriented transport, there is no requirement
  326.    that this operation be on the same particular connection as any other.
  327.    A client may open multiple connections, or close and then reopen a
  328.    connection.
  329.  
  330. 6. Schema Additions
  331.  
  332.    All dynamic entries must have the dynamicObject value in their
  333.    objectClass attribute. This object class is defined as follows
  334.    (using the ObjectClassDescription notation of [2]):
  335.  
  336.    ( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
  337.      DESC 'This class, if present in an entry, indicates that this entry
  338.            has a limited lifetime and may disappear automatically when
  339.            its time-to-live has reached 0.  There are no mandatory
  340.            attributes of this class, however if the client has not
  341.            supplied a value for the entryTtl attribute, the server will
  342.            provide one.'
  343.      SUP top AUXILIARY )  
  344.  
  345.  
  346.    Furthermore, the dynamic entry or the static entry with dynamic
  347.    attributes must have the following operational attribute.  It is
  348.    described using the AttributeTypeDescription notation of [2]:
  349.  
  350.    ( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
  351.      DESC 'This operational attribute is maintained by the server and
  352.            appears to be present in every dynamic entry or an entry that
  353.            contains dynamic attributes.  The attribute is not present
  354.            when the entry does not contain the dynamicObject object class
  355.            or dynamic attributes.  The value of this attribute is the
  356.            time in seconds that the entry or the dynamic attributes in a
  357.            static entry will continue to exist before disappearing from
  358.            the directory.  In the absence of intervening refresh
  359.            operations, the values returned by reading the attribute in
  360.            two successive searches are guaranteed to be nonincreasing.
  361.            The smallest permissible value is 0, indicating that the entry
  362.            may disappear without warning.  The attribute is marked
  363.            NO-USER-MODIFICATION since it may only be changed using the
  364.            refresh operation.'
  365.      SYNTAX 'Integer' SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
  366.  
  367.  
  368. 7. Client and Server Requirements
  369.  
  370. 7.1 Client Requirements
  371.  
  372.    Once a dynamic entry has been created, clients are responsible for
  373.    invoking the refresh extended operation, in order to keep that entry
  374.    present in the directory.  The same holds true for keeping dynamic
  375.    attributes present on a static entry.
  376.  
  377.    Clients must not expect that a dynamic entry will be present in the
  378.    DIT after it has timed out, however it must not either require that
  379.    the server remove the entry immediately (some servers may only process
  380.    timing out entries at intervals).  If the client wishes to ensure the
  381.    entry does not exist it should issue a RemoveRequest for that entry.
  382.    Again, dynamic attributes behave the same: they will not be present in
  383.    the DIT after they timed out, but the client should not require their
  384.    immediate removal.
  385.  
  386.    Initially, a client needs to know how often it should send refresh
  387.    requests to the server.  This value is defined as the CRP (Client
  388.    Refresh Period) and is set by the server based on the entryTtl.  Since
  389.    the AddRequest is left unchanged and is not modified in this proposal
  390.    to return this value, a client must issue a Refresh extended operation
  391.    immediately after an Add that created a dynamic entry.  The Refresh
  392.    Response will return the CRP (in responseTtl) to the client.
  393.  
  394.    Clients must not issue the refresh request for dynamic entries which
  395.    they have not created or for static entries to which they did not add
  396.    dynamic attributes.  Please note that when a client refreshes a static
  397.    entry to which it added dynamic attribute(s), it refreshes ALL the
  398.    dynamic attributes in this entry, including ones added by other
  399.    clients.  Also note that servers which allow anonymous clients to
  400.    create and refresh dynamic entries and attributes will not be able to
  401.    enforce the above.
  402.  
  403.    Clients should always be ready to handle the case in which their entry
  404.    or dynamic attributes timed out.  In such a case, the Refresh
  405.    operation will fail with an error code such as noSuchObject, and the
  406.    client is expected to re-create its entry or re-add the dynamic
  407.    attributes.
  408.  
  409.    Clients should be prepared to experience refresh operations failing
  410.    with protocolError, even though the add and any previous refresh
  411.    requests succeeded.  This might happen if a proxy between the client
  412.    and the server goes down, and another proxy is used which does not
  413.    support the Refresh extended operation.
  414.  
  415.  
  416. 7.2 Server Requirements
  417.  
  418.    Servers are responsible for removing dynamic entries and dynamic
  419.    attributes when they time out.  Servers are not required to do this
  420.    immediately.
  421.   
  422.    Servers must enforce the structural rules listed in above section 4.
  423.  
  424.    Servers must ensure that the operational attribute described in
  425.    section 6 is present in dynamic entries or in static entries that
  426.    contain dynamic attributes.
  427.  
  428.    Servers are permitted to check the authentication of the client
  429.    invoking a refresh extended operation, and only permit the operation
  430.    if it matches that of the client which created the dynamic entry or
  431.    added dynamic attributes to this entry (please see a note about that
  432.    in section 7.1).  Servers may permit anonymous users to refresh
  433.    entries.
  434.  
  435.    Servers may require that a client which attempts to create a dynamic
  436.    entry have a remove permission for that entry.
  437.  
  438.    Servers which implement this extension must have the OBJECT
  439.    IDENTIFIERs, described above in section 5 for the request and
  440.    response, present as values of the supportedExtension field in the
  441.    root DSE.  They must also have as values in the attributeTypes and
  442.    objectClasses attributes of their subschema subentries, the
  443.    AttributeTypeDescription and ObjectClassDescription from section 6.
  444.  
  445.    An implementation of dynamic directories, must be able to support both
  446.    dynamic directory entries and dynamic attributes.
  447.  
  448. 8. Implementation issues
  449.  
  450. 8.1 Storage of dynamic information
  451.  
  452.    Dynamic information is expected to change very often.  In addition,
  453.    Refresh requests are expected to arrive at the server very often.
  454.    Disk-based databases that static directory services often use are
  455.    likely inappropriate for storing dynamic information.  We recommend
  456.    that server implementations store dynamic entries in memory sufficient
  457.    to avoid paging.  This is not a requirement.
  458.  
  459.    We expect LDAP servers to be able to store static and dynamic entries.
  460.    If an LDAP server does not support dynamic entries, it should respond
  461.    with an error code such as objectClassViolation.  Such a server might
  462.    still support setting dynamic attributes on a static entry.
  463.  
  464. 8.2 Client refresh behavior
  465.  
  466.    In some cases, the client might not get a Refresh response.  This may
  467.    happen as a result of a server crash after receiving the Refresh
  468.    request, the TCP/IP socket timing out in the connection case, or the
  469.    UDP packet getting lost in the connection-less case.
  470.  
  471.    It is recommended that in such a case, the client will retry the
  472.    Refresh operation immediately, and if this Refresh request does not
  473.    get a response as well, it will resort to its original Refresh cycle,
  474.    i.e.  send a Refresh request at its Client Refresh Period (CRP).
  475.  
  476.  
  477. 9. Localization
  478.    
  479.    The are no localization issues for this extended operation.
  480.  
  481. 10. Security Considerations
  482.  
  483.    Security issues are not addressed in this document.  Please note,
  484.    though, that anonymous clients are able to refresh entries which they
  485.    did not create.
  486.  
  487.    Also, Care should be taken in making use of information obtained from
  488.    directory servers that has been supplied by client, as it may now be
  489.    out of date.  In many networks, for example, IP addresses are
  490.    automatically assigned when a host connects to the network, and may be
  491.    reassigned if that host later disconnects.  An IP address obtained
  492.    from the directory may no longer be assigned to the host that placed
  493.    the address in the directory.  This issue is not specific to LDAP or
  494.    dynamic directories.
  495.  
  496. 11. Acknowledgments
  497.  
  498.    Design ideas included in this document are based on those discussed in
  499.    ASID and other IETF Working Groups.
  500.  
  501. 12. Authors Addresses
  502.  
  503.        Yoram Yaacovi
  504.        Microsoft
  505.        One Microsoft way
  506.        Redmond, WA 98052
  507.        USA
  508.  
  509.        Phone:  +1 206-936-9629
  510.        EMail:  yoramy@microsoft.com
  511.  
  512.        Mark Wahl
  513.        Critical Angle Inc.
  514.        4815 W. Braker Lane #502-385
  515.        Austin, TX 78759
  516.        USA
  517.  
  518.        EMail:  M.Wahl@critical-angle.com
  519.  
  520.        Kent Settle
  521.        Microsoft
  522.        One Microsoft way
  523.        Redmond, WA 98052
  524.        USA
  525.  
  526.        Phone:  +1 206-936-3027
  527.        EMail:  kentse@microsoft.com
  528.  
  529.  
  530.        Tony Genovese
  531.        Microsoft
  532.        One Microsoft way
  533.        Redmond, WA 98052
  534.        USA
  535.  
  536.        Phone:  +1 206-703-0852
  537.        EMail:  tonyg@microsoft.com
  538.  
  539. 13. Bibliography
  540.  
  541.    [1] M.Wahl, T.  Howes, S.  Kille, "Lightweight Directory Access
  542.        Protocol (Version 3)".  INTERNET DRAFT
  543.        <draft-ietf-asid-ldapv3-protocol-01.txt>
  544.  
  545.    [2] M.Wahl, A.Coulbeck, T.  Howes, S.  Kille, "Lightweight Directory
  546.        Access Protocol Standard and Pilot Attributes".  INTERNET DRAFT
  547.        <draft-ietf-asid-ldapv3-attributes-02.txt>
  548.  
  549.    [3] M.Wahl, S.Kille, "Lightweight Directory Access Protocol UTF-8
  550.        String Representation of Distinguished Names".  INTERNET DRAFT
  551.        <draft-ietf-asid-ldapv3-dn-00.txt>
  552.  
  553.  
  554.    Expires on six months from the post date (see top).
  555.  
  556.