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-02.txt < prev    next >
Text File  |  1996-10-17  |  26KB  |  560 lines
  1.  
  2. ASID Working Group                                            Y. Yaacovi
  3.     
  4. INTERNET-DRAFT                                                 Microsoft
  5.                                                                  M. Wahl
  6.                                                      Critical Angle Inc.
  7.                                                                K. Settle
  8.                                                                Microsoft
  9.                                                              T. Genovese
  10.                                                                Microsoft
  11.  
  12. Expires in six months from                               14 October 1996
  13. Intended Category: Standards Track
  14.  
  15.  
  16.                    Lightweight Directory Access Protocol:
  17.                   Extensions for Dynamic Directory Services
  18.                     <draft-ietf-asid-ldapv3ext-02.txt>
  19.  
  20. 1. Status of this Memo
  21.  
  22.    This document is an Internet-Draft.  Internet-Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its areas,
  24.    and its working groups.  Note that other groups may also distribute
  25.    working documents as Internet-Drafts.
  26.  
  27.    Internet-Drafts are draft documents valid for a maximum of six months
  28.    and may be updated, replaced, or obsoleted by other documents at any
  29.    time.  It is inappropriate to use Internet-Drafts as reference
  30.    material or to cite them other than as "work in progress."
  31.  
  32.    To learn the current status of any Internet-Draft, please check the
  33.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  34.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  35.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  36.  
  37. 2.  Abstract
  38.  
  39.    This document defines the requirements for dynamic directory services
  40.    and specifies the format of request and response extended operations
  41.    for supporting client-server interoperation in a dynamic directories
  42.    environment.
  43.  
  44.    The Lightweight Directory Access Protocol (LDAP) [1] supports
  45.    lightweight access to static directory services, allowing relatively
  46.    fast search and update access.  Static directory services store
  47.    information about people that persists in its accuracy and value over
  48.    a long period of time.
  49.    
  50.    Dynamic directory services are different in that they store
  51.    information about people that only persists in its accuracy and value
  52.    while people are online.  Though the protocol operations and
  53.    attributes used by dynamic directory services are similar to the ones
  54.    used for static directory services, clients that are bound to a
  55.    dynamic directory service need to periodically refresh their presence
  56.    at the server to keep directory entries from getting stale in the
  57.    presence of client application crashes.
  58.  
  59.    In addition, static directories may include dynamic information, in
  60.    the form of dynamic attributes in an otherwise static entry.  Such
  61.    information needs to be refreshed periodically in the same manner.
  62.  
  63.    A flow control mechanism from the server is also described that
  64.    allows a server to inform clients how often they should refresh 
  65.    their presence.
  66.    
  67. 3. Requirements
  68.  
  69.    The protocol extensions must allow accessing dynamic directories in a
  70.    standard LDAP manner, to allow clients to access static and dynamic
  71.    directories in the same way.
  72.  
  73.    By definition, dynamic entries or dynamic attributes are not
  74.    persistent and clients may go away gracefully or not.  The proposed
  75.    extensions must offer a way for a server to tell if entries or
  76.    attributes are still valid, and to do this in a way that will scale
  77.    for a relatively large number of users.  There also must be a
  78.    mechanism for clients to reestablish their entry or attributes with
  79.    the server.
  80.  
  81.    Finally, to allow clients to broadly use the dynamic extensions, 
  82.    the extensions need to be registered as standard LDAP extended
  83.    operations.
  84.  
  85. 4. Description of Approach
  86.  
  87.    The Lightweight Directory Access Protocol (LDAP) [1] permits
  88.    additional operation requests and responses to be added to the
  89.    protocol.  The support for dynamic directories takes advantage of
  90.    these to establish a mechanism to support dynamic directories 
  91.    which is fully integrated with LDAP.
  92.  
  93.    The approach described in this proposal defines dynamic entries and
  94.    dynamic attributes in order to allow implementing directories with
  95.    dynamic information.  An implementation of dynamic directories, must
  96.    be able to support both dynamic directory entries and dynamic
  97.    attributes.
  98.  
  99. 4.1. Dynamic Entries and the dynamicObject object class
  100.  
  101.    A dynamic entry is an object in the directory tree which has a
  102.    time-to-live associated with it.  This time-to-live is set when the
  103.    entry is created.  The time-to-live is automatically decremented, and
  104.    when it expires the dynamic entry disappears.  By invoking the
  105.    refresh extended operation (defined below) to re-set the time-to-live, a
  106.    client can cause the entry to remain present a while longer.
  107.  
  108.    A dynamic entry is created by including the objectClass value given
  109.    in section 6 in the list of attributes when adding an entry.  This
  110.    method is subject to standard access control restrictions.
  111.  
  112.    The extended operation covered here, allows a client to refresh a
  113.    dynamic entry by invoking at intervals refresh operations containing
  114.    that entry's name.  Dynamic entries will be treated the same as
  115.    non-dynamic entries when processing search, compare, add, delete,
  116.    modify and modifydn operations.  However if clients stop sending
  117.    refresh operations for an entry, then the server will automatically
  118.    and without notification remove that entry from the directory.  This
  119.    removal will be treated the same as if the entry had been deleted by
  120.    an LDAP protocol operation.
  121.  
  122.    There is no way to change a static entry into a dynamic one and vice-
  123.    versa.  If the client is using Modify with an objectClass of
  124.    dynamicObject on a static entry, the server must return a service
  125.    error either "objectClassModsProhibited" (if the server does not
  126.    allow objectClass modifications at all) or "objectClassViolation" 
  127.    (if the server does allow objectClass modifications in general).
  128.  
  129.    A dynamic entry may be removed by the client using the delete
  130.    operation.  This operation will be subject to access control
  131.    restrictions.
  132.  
  133.    A non-dynamic entry cannot be added subordinate to a dynamic entry:
  134.    the server must return an appropriate update or service error if this
  135.    is attempted.
  136.  
  137. 4.2. Dynamic Attributes
  138.  
  139.    A similar concept is dynamic attributes.  These attributes behave the
  140.    same as ordinary user attributes to Search, Compare and Modify
  141.    requests, except that if they time out they disappear from the entry
  142.    in which they are located.  (Unlike the dynamicObject class, the
  143.    entry itself does not disappear, and non-dynamic attributes are
  144.    unaffected).  Like dynamic entries, a static entry with dynamic 
  145.    attributes must have the entryTtl attribute which is described 
  146.    in section 6 below.
  147.  
  148.    Dynamic attributes do not necessarily introduce a new set of
  149.    attributes in the schema.  Any static attribute in the schema can be
  150.    made dynamic by including the ;dynamic attribute modifier with the
  151.    typename.  It is allowed to introduce new dynamic attributes which
  152.    are not useful in the static domain.  Such attributes will still require
  153.    including the ;dynamic attribute modifier with the typename to define
  154.    them as dynamic.
  155.  
  156.    A dynamic attribute may be a subtype of a non-dynamic attribute, ]
  157.    but a non-dynamic attribute must not be a subtype of a dynamic attribute.
  158.    Operational attributes and collective attributes must not be dynamic.
  159.    All dynamic attributes are considered to be user attributes, however
  160.    they are not guaranteed to be present in shadow copies of entries.
  161.  
  162.    A client may introduce dynamic attributes into an entry by using a
  163.    Modify request to add them, or by including them in the attribute
  164.    list of an Add Request.  If the attribute type is permitted in the entry
  165.    then the dynamic attribute is also permitted.  The client would
  166.    specify that the attribute is dynamic by including the tag ";dynamic"
  167.    with the typename.  Dynamic values may be changed, and the attributes
  168.    removed, by using the Modify request as normal.  If the entry is
  169.    deleted, dynamic attributes disappear immediately along with all the
  170.    non-dynamic.  A ;dynamic modifier on an attribute may not be used in
  171.    a compare request, or in a search request (either in the filter or
  172.    attributes requested for return).  This is in keeping with the
  173.    philosophy that dynamic attributes be indistinguishable from static
  174.    attributes as much as possible.
  175.  
  176.    The granularity of a dynamic attribute is the entire attribute
  177.    including all values.  Dynamic and static values may not be mixed
  178.    within a single attribute.  For example, suppose an existing static
  179.    entry had an attribute called "ipAddress" with the value "1.2.3.4".
  180.    A modification of the entry to add the value "5.4.3.2" to the attribute
  181.    "ipAddress;dynamic" would fail with a "constraintViolation" error.
  182.  
  183.    The addition and modification of dynamic attributes are subject to
  184.    schema and access control restrictions, as with non-dynamic
  185.    attributes.  Thus unless the extensibleObject object class is
  186.    present, generally an object class or content rule must be defined 
  187.    to permit those attributes to be present in an entry.  If their presence 
  188.    is controlled by an object class, then just as with non-dynamic
  189.    attributes, the object class value must have already been added
  190.    before the attributes are added.  The dynamicObject object class 
  191.    described in section 4.1 does not itself permit any particular 
  192.    dynamic attributes.
  193.  
  194.    Dynamic attributes in a particular entry are refreshed using the
  195.    Refresh extended operation.  All of the entry's dynamic attributes
  196.    are refreshed by a single refresh request.  The TTL given in the refresh
  197.    response applies to all of the entry's dynamic attributes.  There is
  198.    no way to refresh particular dynamic attributes within an entry at
  199.    different times, or to have different TTLs apply to different dynamic
  200.    attributes.
  201.  
  202.    If not refreshed, all dynamic attributes in an entry time out
  203.    simultaneously.  All the attributes which are dynamic with all their
  204.    values disappear atomically, as if the server had done a ModifyEntry
  205.    specifying that all the dynamic types were to be deleted from that
  206.    entry.  The client must not expect any dynamic attributes to be
  207.    present in an entry after the time-to-live for that entry has reached
  208.    zero.  However the attributes may not disappear immediately as
  209.    servers may only process timing out attributes at intervals 
  210.    (e.g.  every few minutes).
  211.  
  212.    Note that if an object class definition references a dynamic
  213.    attribute as a mandatory attribute, the entry will still time out, 
  214.    but a schema inconsistency will be present in that entry. 
  215.    (The objectClass attribute and its values always remain 
  216.    since objectClass is not a dynamic attribute.) Thus it is 
  217.    strongly recommended that designers not specify dynamic 
  218.    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
  223.    all of such an entry's attributes are implicitly dynamic, such use 
  224.    is 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
  257.    the 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
  270.    the 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
  273.    value 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
  287.    the 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
  301.    in 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
  309.    field will contain "noSuchObject".  If the entry is not dynamic, or  
  310.    does not 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,
  314.    the 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
  327.    other.  A client may open multiple connections, or close and then 
  328.    reopen a 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
  355.            class 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
  362.            entry 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
  380.    process timing out entries at intervals).  If the client wishes to 
  381.    ensure the entry does not exist it should issue a RemoveRequest for 
  382.    that entry.  Again, dynamic attributes behave the same: they will not 
  383.    be present in the DIT after they timed out, but the client should not 
  384.    require their 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.
  389.    Since the AddRequest is left unchanged and is not modified in this 
  390.    proposal to return this value, a client must issue a Refresh extended
  391.    operation immediately after an Add that created a dynamic entry.  
  392.    The Refresh 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
  397.    static entry to which it added dynamic attribute(s), it refreshes ALL 
  398.    the 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
  404.    entry 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
  446.    both 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
  457.    sufficient to avoid paging.  This is not a requirement.
  458.  
  459.    We expect LDAP servers to be able to store static and dynamic
  460.    entries.  If an LDAP server does not support dynamic entries, 
  461.    it should respond with an error code such as objectClassViolation.  
  462.    Such a server might still support setting dynamic attributes 
  463.    on a static entry.
  464.  
  465. 8.2 Client refresh behavior
  466.  
  467.    In some cases, the client might not get a Refresh response.  This may
  468.    happen as a result of a server crash after receiving the Refresh
  469.    request, the TCP/IP socket timing out in the connection case, or the
  470.    UDP packet getting lost in the connection-less case.
  471.  
  472.    It is recommended that in such a case, the client will retry the
  473.    Refresh operation immediately, and if this Refresh request does not
  474.    get a response as well, it will resort to its original Refresh cycle,
  475.    i.e.  send a Refresh request at its Client Refresh Period (CRP).
  476.  
  477.  
  478. 9. Localization
  479.    
  480.    The are no localization issues for this extended operation.
  481.  
  482. 10. Security Considerations
  483.  
  484.    Security issues are not addressed in this document.  Please note,
  485.    though, that anonymous clients are able to refresh entries which they
  486.    did not create.
  487.  
  488.    Also, Care should be taken in making use of information obtained from
  489.    directory servers that has been supplied by client, as it may now be
  490.    out of date.  In many networks, for example, IP addresses are
  491.    automatically assigned when a host connects to the network, and may
  492.    be reassigned if that host later disconnects.  An IP address obtained
  493.    from the directory may no longer be assigned to the host that placed
  494.    the address in the directory.  This issue is not specific to LDAP or
  495.    dynamic directories.
  496.  
  497. 11. Acknowledgments
  498.  
  499.    Design ideas included in this document are based on those discussed
  500.    in ASID and other IETF Working Groups.
  501.  
  502. 12. Authors Addresses
  503.  
  504.        Yoram Yaacovi
  505.        Microsoft
  506.        One Microsoft way
  507.        Redmond, WA 98052
  508.        USA
  509.  
  510.        Phone:  +1 206-936-9629
  511.        EMail:  yoramy@microsoft.com
  512.  
  513.        Mark Wahl
  514.        Critical Angle Inc.
  515.        4815 W. Braker Lane #502-385
  516.        Austin, TX 78759
  517.        USA
  518.  
  519.        EMail:  M.Wahl@critical-angle.com
  520.  
  521.        Kent Settle
  522.        Microsoft
  523.        One Microsoft way
  524.        Redmond, WA 98052
  525.        USA
  526.  
  527.        Phone:  +1 206-936-3027
  528.        EMail:  kentse@microsoft.com
  529.  
  530.  
  531.        Tony Genovese
  532.        Microsoft
  533.        One Microsoft way
  534.        Redmond, WA 98052
  535.        USA
  536.  
  537.        Phone:  +1 206-703-0852
  538.        EMail:  tonyg@microsoft.com
  539.  
  540. 13. Bibliography
  541.  
  542.    [1] M.Wahl, T.  Howes, S.  Kille, "Lightweight Directory Access
  543.        Protocol (Version 3)".  INTERNET DRAFT
  544.        <draft-ietf-asid-ldapv3-protocol-01.txt>
  545.  
  546.    [2] M.Wahl, A.Coulbeck, T.  Howes, S.  Kille, "Lightweight Directory
  547.        Access Protocol Standard and Pilot Attributes".  INTERNET DRAFT
  548.        <draft-ietf-asid-ldapv3-attributes-02.txt>
  549.  
  550.    [3] M.Wahl, S.Kille, "Lightweight Directory Access Protocol UTF-8
  551.        String Representation of Distinguished Names".  INTERNET DRAFT
  552.        <draft-ietf-asid-ldapv3-dn-00.txt>
  553.  
  554.  
  555.    Expires on six months from the post date (see top).
  556.  
  557.  
  558.  
  559.  
  560.