home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-wahl-know-mime-00.txt < prev    next >
Text File  |  1996-08-29  |  23KB  |  628 lines
  1.  
  2. Network Working Group                                               M. Wahl
  3. INTERNET-DRAFT                                          Critical Angle Inc.
  4. Expires in six months from                                   28 August 1996
  5.  
  6.         Application/Directory Profile for LDAP and X.500 Knowledge
  7.                       <draft-wahl-know-mime-00.txt>
  8.  
  9. 1.  Status of this Memo
  10.  
  11.    This document is an Internet-Draft.  Internet-Drafts are working 
  12.    documents of the Internet Engineering Task Force (IETF), its areas, and
  13.    its working groups.  Note that other groups may also distribute working
  14.    documents as Internet-Drafts.
  15.  
  16.    Internet-Drafts are draft documents valid for a maximum of six months
  17.    and may be updated, replaced, or obsoleted by other documents at any
  18.    time.  It is inappropriate to use Internet-Drafts as reference material
  19.    or to cite them other than as "work in progress."
  20.  
  21.    To learn the current status of any Internet-Draft, please check the
  22.    "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
  23.    Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  24.    ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  25.  
  26. 2.  Abstract
  27.  
  28.    This memo defines directory information profiles for representing
  29.    directory distribution knowledge for an X.500 or LDAP directory system, 
  30.    to be carried in an application/directory MIME Content-Type. The 
  31.    profiles consists of type definitions and the corresponding format of 
  32.    values that each type is allowed to contain.  They are designed for simple
  33.    generation and parsing by programs; the text-based format makes it 
  34.    easier for developers and directory administrators to debug problems.
  35.  
  36.    Additional documents will build on these specifications in defining
  37.    text-based protocols for distributed directory server administration.
  38.  
  39. 3.  Overview
  40.  
  41.    The Internet White Pages Directory service currently is built from a 
  42.    combination of X.500(88), X.500(93) and LDAP-capable servers.  No 
  43.    single server holds the entire directory tree, instead the tree is 
  44.    partitioned among the servers. There are two basic ways that the naming 
  45.    tree has been partitioned: 
  46.  
  47.    The first is the Entry Data Block, or "EDB" model, which is primarily 
  48.    supported just by the QUIPU implementation.  In this model, all the 
  49.    immediate subordinates of a single entry in the tree, the context prefix, 
  50.    are mastered together in a single server.  The context prefix entry itself 
  51.    is not part of the EDB, for it is part of the immediate superior EDB.
  52.  
  53.    The second is the Naming Context model, supported by X.500-based  
  54.    servers.  In this model, an entry, the context prefix, and all its 
  55.    subordinates down to either the leaves or references to subordinate 
  56.    naming contexts are held in the same server.
  57.  
  58.    It is expected that LDAP servers will follow the Naming Context model.
  59.  
  60.  
  61. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  62.  
  63.    Knowledge is the information which describes the distribution of the 
  64.    directory hierarchy.  Each component of a servers' knowledge will 
  65.    consist of the name of a context prefix, and the list of servers to 
  66.    contact for progressing operations in the naming context identified
  67.    by that context prefix.
  68.  
  69.    Operational bindings are defined in X.501 [7] are agreements between
  70.    a pair of servers.  Hierarchical and Shadow operational bindings permit
  71.    the exchange of knowledge information.  An operational binding is 
  72.    identified by a number, unique between a pair of servers.
  73.  
  74.    This document does not specify means to identify non-specific knowledge.
  75.  
  76. 4.  The Knowledge Profile
  77.  
  78.    The profile is defined as follows, using the profile registration
  79.    template from [1].
  80.  
  81. 4.1. Profile Definition
  82.  
  83.    To: ietf-mime-direct@umich.edu
  84.    Subject: Registration of application/directory MIME profile knowledge
  85.  
  86.    Profile name: knowledge
  87.  
  88.    Profile purpose: To hold information about hierarchical distribution
  89.    of a directory.
  90.  
  91.    Profile types: NAME, ACCESSPOINT, BINDINGID
  92.  
  93.    Profile special notes:
  94.  
  95.       There are no ordering limitations on types within the content entity.
  96.   
  97.       The default transfer encoding for the profile is 7-Bit, if only
  98.       US-ASCII equivalent characters are present in the content, otherwise
  99.       it is quoted printable or base64.
  100.  
  101.       The default character set is ISO-10646-UTF-8 [2].  It is recommended 
  102.       that this NOT be changed to any other character set.  (UTF-8 is 
  103.       chosen as this is the character set used in the LDAP protocol itself
  104.       for names and attributes.  In allows for all the characters in 
  105.       UniversalString without shifting character sets.  This makes it very
  106.       easy for servers to handle.)
  107.  
  108.       There is no default language.  It is not expected that attributes in
  109.       this profile would be provided directly to end users.  
  110.  
  111.       The default location of the type values is inline with the profile 
  112.       type.  It is strongly recommended that no multimedia attributes be 
  113.       present in contents with this profile.
  114.   
  115.    Intended usage: COMMON  
  116.  
  117.    The associated type definitions follow, using the type registration
  118.    template from [1].
  119.  
  120.  
  121. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  122.  
  123. 4.2.  Type definitions
  124.  
  125. 4.2.1.  NAME Type Definition
  126.  
  127.    The NAME parameter, defined in [1], is used to convey the directory
  128.    name of the context prefix.  There must be exactly one value of this
  129.    parameter in a content.
  130.  
  131.    The value of this parameter is a UTF-8 string encoding of a Distinguished
  132.    Name, as defined in [3].  
  133.  
  134.    The "PROTO" subtype parameter must be present, and its value must be "LDAP".
  135.  
  136.    Type examples:
  137.       
  138.        NAME;PROTO=LDAP: CN=Babs Jensen, O=Babsco, C=US
  139.  
  140.        NAME;PROTO=LDAP: CN=#130442616273, O=#130442616273, C=US
  141.  
  142. 4.2.2.  ACCESSPOINT Type Definition
  143.  
  144.    The ACCESSPOINT parameter is used to convey the means of access for
  145.    this naming context.  There must be at least one value of this parameter
  146.    in a context.
  147.  
  148.  
  149.    The value of this parameter is encoded according to the following BNF:
  150.  
  151.    <AccessPoint> ::= <Preference> '#'  <Role> '#' <AccessPointData>
  152.  
  153.    <Preference> ::= <integer> |      -- or absent
  154.  
  155.    <Role> ::= 'master' | 'shadow' | 'gateway' | 'cache' |     -- or absent
  156.  
  157.    <AccessPointData> ::= <X500AccessPoint> | 
  158.                          <QuipuAccessPoint> |
  159.                          <LDAPAccessPoint> |
  160.                          <DNSAccessPoint> |
  161.                          <URLAccessPoint>
  162.  
  163.    <X500AccessPoint> ::= 'X500' '#' <Serverdn> '#' <PresentationAddress> 
  164.                          [ '#' <SetOfProtocolInformation> ]
  165.  
  166.    <SetOfProtocolInformation> ::= <ProtocolInformation> | 
  167.                                   '(' <ProtocolInformationList> ')'
  168.  
  169.    <ProtocolInformationList> ::= <ProtocolInformation> | 
  170.                                  <ProtocolInformation> '$'
  171.                                  <ProtocolInformationList>
  172.  
  173.  
  174.    <QuipuAccessPoint> ::= 'QUIPU' '#' <Serverdn>
  175.  
  176.    <LDAPAccessPoint> ::= <Ldap389AP> | <Ldap636AP>
  177.  
  178.    <Ldap389AP> ::= 'LDAP' '#' [ <Serverdn> ] '#' <Hostnameportno>
  179.  
  180.    <Ldap636AP> ::= 'SSL-LDAP' '#' [ <Serverdn> ] '#' <Hostnameportno>
  181.  
  182.  
  183. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  184.  
  185.    <Serverdn> ::= <DN>
  186.  
  187.    <Hostnameportno> ::= <Hostnameorip> [ ':' <Portno>]
  188.    
  189.    <DNSAccessPoint> ::= 'DNS' '#' <Hostnameorip>
  190.  
  191.    <URLAccessPoint> ::= 'URL' '#' <Url>
  192.  
  193.    <Hostnameorip> ::= -- a fully-qualifed domain name or an IP address
  194.  
  195.    <Portno> ::= -- a TCP or UDP port number
  196.  
  197.    The encoding format of <DN> is given in [3], <PresentationAddress> in [4], 
  198.    <ProtocolInformation> in [5] and <Url> in [6].
  199.  
  200.    The <Preference> field, if present, takes as a value an integer between
  201.    0 and 255 (inclusive).  It permits the sender to suggest relative 
  202.    preferences for the receiver to use when choosing between multiple values 
  203.    of ACCESSPOINT in this content.  In general, receivers should prefer 
  204.    access points with smaller values of preference.  If this field is absent, 
  205.    the sender does not indicate any particular relative preference for this 
  206.    value.
  207.  
  208.    The <Role> field, if present, takes on the following values:
  209.      master: the server indicated in the access point holds the master
  210.              copy of entries in this naming context.
  211.      shadow: the server indicated in the access point holds a possibly 
  212.              incomplete shadow copy of entries in this naming context.
  213.      gateway: substantial loss of content may occur if this server is 
  214.               contacted. 
  215.      cache: the server holds some information from this naming context 
  216.             which may be out of date.
  217.  
  218.    If the role field is absent, the sender does not indicate any particular
  219.    role for the server named in the access point.
  220.  
  221.    The <X500AccessPoint> field specifies a single X.500 DSA.  It contains 
  222.    the DSA's Distinguished Name, presentation address, and an optional list
  223.    of protocol information.  The DSA indicated will be able to perform 
  224.    operations on all entries in the naming context (possibly by contacting
  225.    other servers or returning referrals).
  226.  
  227.    The <QuipuAccessPoint> field specifies a single X.500 DSA by its 
  228.    Distinguished Name.  The presentation address of the DSA must be obtained
  229.    through other means, such as a content of profile "DSA".  The DSA 
  230.    indicated will be able to perform operations on entries subordinate to 
  231.    the context prefix, but not on the context prefix entry itself.
  232.  
  233.    The <LDAPAccessPoint> field specifies an LDAP server by its host name or
  234.    IP address, and optional port number.  The default port number, 389 for 
  235.    plain LDAP and 636 for SSL-LDAP, should be used if the port number is not 
  236.    specified. The distinguished name of the server may optionally be provided. 
  237.    This server will be able to perform operations on all entries in the naming 
  238.    context (possibly by contacting other servers or returning referrals).
  239.  
  240.  
  241. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  242.  
  243.    The <DNSAccessPoint> field specifies a domain name system server by its
  244.    host name or IP address. The <URLAccessPoint> field specifies a server 
  245.    based on its URL.  These are not currently used but are reserved for 
  246.    future extensibility.
  247.  
  248.    Example:
  249.  
  250.    AccessPoint: # # LDAP # # nameflow.dante.net
  251.  
  252.    Further examples are given in section 6.1 and 6.2.
  253.  
  254. 4.2.2.1. Why a URL is not being used 
  255.  
  256.    Not all the types of access described above have a URL scheme, and 
  257.    additional information is associated as each of the access points
  258.    which are not part of today's URL definitions (such as preference).
  259.  
  260.    "URL-Unsafe" characters such as spaces or non-ASCII characters are 
  261.    extremely likely to occur in values, and that would lead to yet another
  262.    layer of quoting, even though the content itself might be using a 
  263.    quoted-printable, base64 encoding.
  264.  
  265.    Philsophically, there is no single "data resource", like a particular 
  266.    entry, being identified in the access point.  Instead the access point 
  267.    could be used to access many different entries.
  268.  
  269. 4.2.3.  BINDINGID Parameter
  270.  
  271.    This parameter should be present at most once in a content.  Its value
  272.    is encoded according to the following BNF:
  273.  
  274.    <BindingID> ::= <Id> [ '.' <Version>]
  275.  
  276.    <Id> ::= <integer>
  277.  
  278.    <Version> ::= <integer>
  279.  
  280.    For example,
  281.  
  282.    BINDINGID: 100
  283.  
  284.    BINDINGID: 100.10
  285.  
  286.    This parameter is present only if there is an operational binding [7] 
  287.    between the sender and recipient.
  288.  
  289. 5.  Related Profiles
  290.  
  291.    A MIME message containing contents of the "knowledge" profile may 
  292.    also carry contents with the "dsa", "subentry" or "cache-attributes"
  293.    profiles.  Contents with these profiles may also be carried indpendently.
  294.  
  295. 5.1. DSA Profile
  296.  
  297.    A "DSA" profile is defined as follows, using the profile registration
  298.    template from [1].
  299.  
  300.  
  301. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  302.  
  303.    To: ietf-mime-direct@umich.edu
  304.    Subject: Registration of application/directory MIME profile DSA
  305.  
  306.    Profile name: DSA
  307.  
  308.    Profile purpose: To hold information about a Directory System Agent 
  309.    (server).
  310.  
  311.    Profile types: NAME, PRESENTATIONADDRESS, SUPPORTEDAPPLICATIONCONTEXT, 
  312.                   BINDINGID, LASTMODIFIEDTIME
  313.  
  314.    Profile special notes:
  315.  
  316.       There are no ordering limitations on types within the content entity.
  317.   
  318.       The default transfer encoding for the profile is 7-Bit.  
  319.  
  320.       The default character set is ISO-10646-UTF-8 [2].  It is recommended 
  321.       that this NOT be changed to any other character set.
  322.  
  323.       There is no default language.  It is not expected that attributes in
  324.       this profile would be provided directly to end users.  
  325.  
  326.       The default location of the type values is inline with the profile 
  327.       type.  It is strongly recommended that no multimedia attributes be 
  328.       present in contents with this profile.
  329.   
  330.       The following types are also likely to occur in this contents with
  331.       this profile, however their values are not used by the recipient:
  332.          CN, description, L, O, OU, seeAlso, knowledgeInformation,
  333.          lastModifiedBy
  334.  
  335.    Intended usage: COMMON 
  336.  
  337.    The associated type definitions follow, using the type registration
  338.    template from [1].
  339.  
  340. 5.1.1.  NAME Type Definition
  341.  
  342.    The NAME parameter, defined in [1], is used to convey the directory
  343.    name of the server.  There must be exactly one value of this
  344.    parameter in a content.
  345.  
  346.    The value of this parameter is a UTF-8 string encoding of a Distinguished
  347.    Name, as defined in [3].  
  348.  
  349.    The "PROTO" subtype parameter must be present, and its value must be "LDAP".
  350.  
  351. 5.1.2.  PRESENTATIONADDRESS Type Definition
  352.  
  353.    The PRESENTATIONADDRESS parameter is used to convey the presentation address
  354.    of the server.  There must be exactly one value of this parameter in a 
  355.    content.
  356.  
  357.    The value of this parameter is a Presentation Address as defined in [4].
  358.  
  359.  
  360. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  361.  
  362. 5.1.3.  SUPPORTEDAPPLICATIONCONTEXT Type Definition
  363.  
  364.    The SUPPORTEDAPPLICATIONCONTEXT parameter is used to convey the 
  365.    application contexts supported by the server.  There may be any number of 
  366.    values of this parameter in a content.
  367.  
  368.    The value of this parameter is a string representation of an OBJECT 
  369.    IDENTIFIER, as described in [5].
  370.  
  371.    The following example values are among those likely to occur:
  372.  
  373.    supportedApplicationContext: 2.5.3.1     -- directory access
  374.    supportedApplicationContext: 2.5.3.2     -- directory system
  375.    supportedApplicationContext: 2.5.3.4     -- shadow consumer initiated
  376.    supportedApplicationContext: 2.5.3.5     -- shadow supplier initiated
  377.    supportedApplicationContext: 0.9.2342.19200300.99.4     -- QUIPU DSP
  378.    supportedApplicationContext: 0.9.2342.19200300.100.8    -- Internet DSP
  379.  
  380. 5.1.4.  LASTMODIFIEDTIME Type Definition
  381.  
  382.    The LASTMODIFIEDTIME parameter is used to convey the time this entry
  383.    was last modified.  There may be at most one value of this parameter in
  384.    a content.
  385.  
  386.    The value of the parameter is a UTCTime, as described in [5]. 
  387.  
  388. 5.2. Subentry Profile
  389.  
  390.    A "SUBENTRY" profile is defined as follows, using the profile registration
  391.    template from [1].
  392.  
  393.  
  394.    To: ietf-mime-direct@umich.edu
  395.    Subject: Registration of application/directory MIME profile SUBENTRY
  396.  
  397.    Profile name: SUBENTRY
  398.  
  399.    Profile purpose: To hold information from a subentry.
  400.  
  401.    Profile types: NAME, BINDINGID, subtreeSpecification, CN, dseType, 
  402.       entryACI, prescriptiveACI,
  403.       creatorsName, createTimestamp, modifiersName, modifyTimestamp,
  404.       dITStructureRules, nameForms, ditContentRules, objectClasses,
  405.       attributeTypes, matchingRules, matchingRuleUse, 
  406.       collectiveLocalityName, collectiveStateOrProvinceName,
  407.       collectiveStreetAddress, collectiveOrganizationName,
  408.       collectiveOrganizationalUnitName, collectivePostalAddress,
  409.       collectivePostalCode, collectivePostOfficeBox,
  410.       collectivePhysicalDeliveryOfficeName,
  411.       collectiveTelephoneNumber, collectiveTelexNumber,
  412.       collectiveTeletexTerminalIdentifier,
  413.       collectiveFacsimileTelephoneNumber,
  414.       collectiveInternationaliSDNNumber
  415.  
  416.    Profile special notes:
  417.  
  418.       There are no ordering limitations on types within the content entity.
  419.  
  420.  
  421. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  422.   
  423.       The default transfer encoding for the profile is 7-Bit.  
  424.  
  425.       The default character set is ISO-10646-UTF-8 [2].  It is recommended 
  426.       that this NOT be changed to any other character set.
  427.  
  428.       There is no default language.  It is not expected that attributes in
  429.       this profile would be provided directly to end users.  
  430.  
  431.       The default location of the type values is inline with the profile 
  432.       type.  It is strongly recommended that no multimedia attributes be 
  433.       present in contents with this profile.
  434.  
  435.    Intended usage: COMMON 
  436.  
  437.    With the exception of NAME and BINDINGID, which are described above,
  438.    the rest of type parameters are those likely to be in subentries.  They are 
  439.    as described in [5].
  440.  
  441. 5.3.  Attributes for Caching Profile
  442.  
  443.    A "CACHE-ATTRIBUTES" profile is defined as follows, using the profile 
  444.    registration template from [1].
  445.  
  446.    To: ietf-mime-direct@umich.edu
  447.    Subject: Registration of application/directory MIME profile CACHE-ATTRIBUTES
  448.  
  449.    Profile name: CACHE-ATTRIBUTES
  450.  
  451.    Profile purpose: To hold arbitrary attributes which may be cached
  452.       and used in matching search filters.
  453.  
  454.    Profile types: NAME, BINDINGID, etc
  455.  
  456.    Profile special notes:
  457.  
  458.       There are no ordering limitations on types within the content entity.
  459.   
  460.       The default transfer encoding for the profile is 7-Bit.
  461.  
  462.       The default character set is ISO-10646-UTF-8 [2].  It is recommended 
  463.       that this NOT be changed to any other character set.
  464.  
  465.       There is no default language.  
  466.  
  467.       The default location of the type values is inline with the profile 
  468.       type.  It is strongly recommended that no multimedia attributes be 
  469.       present in contents with this profile.
  470.  
  471.    Intended usage: COMMON 
  472.  
  473.    With the exception of NAME and BINDINGID, which are described above, 
  474.    the content may contain any attribute of [5] which the sender wishes to 
  475.    have cached by the recipient.  These could include administrativeRole,
  476.    accessControlScheme, objectClass, aliasedObjectName, description etc.
  477.  
  478.  
  479. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  480.  
  481. 6.  Examples
  482.  
  483.    Section 6.1 is an example of what a server holding the naming context 
  484.    "O=Foo,C=US" might send to the server holding the naming context "C=US", 
  485.    in order to have the subordinate context added to the directory.  Section
  486.    6.2 is an example of what the "C=US" server might return as a response.
  487.  
  488. 6.1. 
  489.  
  490.    MIME-Version: 1.0 
  491.    Content-Type: multipart/mixed; boundary="break"
  492.    Content-Description: information about O=Foo,C=US
  493.    
  494.    --break
  495.    Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8"
  496.    
  497.    Name;PROTO=LDAP: O=Foo, C=US
  498.    AccessPoint: # master # LDAP # CN=Server, O=Foo, C=US # server.foo.com
  499.    --break
  500.    Content-Type: application/directory; profile="cache-attributes"; charset="iso-10646-utf-8"
  501.    
  502.    Name;PROTO=LDAP: O=Foo, C=US
  503.    O: Foo
  504.    Description: Makers of the Foo line of Widgets
  505.    --break--
  506.  
  507.  
  508. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  509.  
  510. 6.2.
  511.  
  512.    MIME-Version: 1.0
  513.    Content-Type: multipart/mixed; boundary="break"
  514.    Content-Description: information about O=Foo,C=US and superiors
  515.    
  516.    --break
  517.    Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8"
  518.   
  519.    Name;PROTO=LDAP:
  520.    AccessPoint: # gateway # LDAP # # nameflow.dante.net
  521.    --break
  522.    Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8"
  523.  
  524.    Name;PROTO=LDAP: C=US
  525.    AccessPoint: 30 # master # QUIPU # CN=EDB Beetle
  526.    AccessPoint: 10 # shadow # X500 # CN=U,C=US # "X500"/Internet=us.net+19999
  527.    AccessPoint: 20 # gateway # LDAP # # nameflow.dante.net
  528.    --break
  529.    Content-Type: application/directory; profile="DSA"; charset="iso-10646-utf-8"
  530.  
  531.    Name;PROTO=LDAP: CN=EDB Beetle
  532.    Description: the Endangered EDB-only Beetle
  533.    Description: supports DAP, DSP, IDSP and QDSP
  534.    PresentationAddress: "X500"/Internet=us.net+17003
  535.    SupportedApplicationContext: 2.5.3.1
  536.    SupportedApplicationContext: 2.5.3.2
  537.    SupportedApplicationContext: 0.9.2342.19200300.99.4
  538.    SupportedApplicationContext: 0.9.2342.19200300.100.8
  539.    --break
  540.    Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8"
  541.    
  542.    Name;PROTO=LDAP: O=Foo, C=US
  543.    AccessPoint: 0 # master # LDAP # CN=Server, O=Foo, C=US # server.foo.com
  544.    AccessPoint: 128 # gateway # X500 # CN=U,C=US # "X500"/Internet=us.net+19999
  545.    --break
  546.    Content-Type: application/directory; profile="cache-attributes"; charset="utf8"
  547.    
  548.    Name;PROTO=LDAP: C=US
  549.    C: US
  550.    CO: United States of America
  551.    Description: Land of the Free
  552.    Description: Home of the Brave
  553.    --break--
  554.  
  555.  
  556. 7.  Security Considerations
  557.  
  558.    Internet mail is subject to many well known security attacks, including
  559.    monitoring, replay, and forgery.  Care should be taken by any directory
  560.    service in allowing information to leave the scope of the service
  561.    itself, where any access controls can no longer be guaranteed. 
  562.  
  563.    Applications should also take care to display directory data in a "safe" 
  564.    environment (e.g., PostScript-valued types).
  565.  
  566.  
  567. INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996
  568.  
  569. 8.  Bibliography
  570.    
  571.    [1] T. Howes, M. Smith, "A MIME Content-Type for Directory Information",
  572.        INTERNET DRAFT <draft-ietf-asid-mime-direct-02.txt",  July 1996.
  573.  
  574.    [2] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1.
  575.  
  576.    [3] M. Wahl, S. Kille, "A UTF-8 String Representation of Distinguished 
  577.        Names", INTERNET DRAFT <draft-ietf-asid-ldapv3-dn-00.txt>, August 1996.
  578.  
  579.    [4] S. Kille, "A String Representation for Presentation Addresses",
  580.        RFC 1278, University College London, November 1991.
  581.  
  582.    [5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "LDAP Standard and Pilot 
  583.        Attribute Definitions", INTERNET DRAFT 
  584.        <draft-ietf-asid-ldapv3-attributes-02.txt>, August 1996.
  585.  
  586.    [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
  587.        Locations (URL)", RFC 1738, December 1994.
  588.  
  589.    [7] The Directory: Models. ITU-T Recommendation X.501, 1993.
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627. <draft-wahl-know-mime-00.txt>           Expires: February 28, 1997
  628.