[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                               M. Wahl
INTERNET-DRAFT                                          Critical Angle Inc.
Expires in six months from                                   28 August 1996

        Application/Directory Profile for LDAP and X.500 Knowledge
                      <draft-wahl-know-mime-00.txt>

1.  Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference material
   or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

2.  Abstract

   This memo defines directory information profiles for representing
   directory distribution knowledge for an X.500 or LDAP directory system,
   to be carried in an application/directory MIME Content-Type. The
   profiles consists of type definitions and the corresponding format of
   values that each type is allowed to contain.  They are designed for simple
   generation and parsing by programs; the text-based format makes it
   easier for developers and directory administrators to debug problems.

   Additional documents will build on these specifications in defining
   text-based protocols for distributed directory server administration.

3.  Overview

   The Internet White Pages Directory service currently is built from a
   combination of X.500(88), X.500(93) and LDAP-capable servers.  No
   single server holds the entire directory tree, instead the tree is
   partitioned among the servers. There are two basic ways that the naming
   tree has been partitioned:

   The first is the Entry Data Block, or "EDB" model, which is primarily
   supported just by the QUIPU implementation.  In this model, all the
   immediate subordinates of a single entry in the tree, the context prefix,
   are mastered together in a single server.  The context prefix entry itself
   is not part of the EDB, for it is part of the immediate superior EDB.

   The second is the Naming Context model, supported by X.500-based
   servers.  In this model, an entry, the context prefix, and all its
   subordinates down to either the leaves or references to subordinate
   naming contexts are held in the same server.

   It is expected that LDAP servers will follow the Naming Context model.


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

   Knowledge is the information which describes the distribution of the
   directory hierarchy.  Each component of a servers' knowledge will
   consist of the name of a context prefix, and the list of servers to
   contact for progressing operations in the naming context identified
   by that context prefix.

   Operational bindings are defined in X.501 [7] are agreements between
   a pair of servers.  Hierarchical and Shadow operational bindings permit
   the exchange of knowledge information.  An operational binding is
   identified by a number, unique between a pair of servers.

   This document does not specify means to identify non-specific knowledge.

4.  The Knowledge Profile

   The profile is defined as follows, using the profile registration
   template from [1].

4.1. Profile Definition

   To: ietf-mime-direct@umich.edu
   Subject: Registration of application/directory MIME profile knowledge

   Profile name: knowledge

   Profile purpose: To hold information about hierarchical distribution
   of a directory.

   Profile types: NAME, ACCESSPOINT, BINDINGID

   Profile special notes:

      There are no ordering limitations on types within the content entity.

      The default transfer encoding for the profile is 7-Bit, if only
      US-ASCII equivalent characters are present in the content, otherwise
      it is quoted printable or base64.

      The default character set is ISO-10646-UTF-8 [2].  It is recommended
      that this NOT be changed to any other character set.  (UTF-8 is
      chosen as this is the character set used in the LDAP protocol itself
      for names and attributes.  In allows for all the characters in
      UniversalString without shifting character sets.  This makes it very
      easy for servers to handle.)

      There is no default language.  It is not expected that attributes in
      this profile would be provided directly to end users.

      The default location of the type values is inline with the profile
      type.  It is strongly recommended that no multimedia attributes be
      present in contents with this profile.

   Intended usage: COMMON

   The associated type definitions follow, using the type registration
   template from [1].


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

4.2.  Type definitions

4.2.1.  NAME Type Definition

   The NAME parameter, defined in [1], is used to convey the directory
   name of the context prefix.  There must be exactly one value of this
   parameter in a content.

   The value of this parameter is a UTF-8 string encoding of a Distinguished
   Name, as defined in [3].

   The "PROTO" subtype parameter must be present, and its value must be "LDAP".

   Type examples:

       NAME;PROTO=LDAP: CN=Babs Jensen, O=Babsco, C=US

       NAME;PROTO=LDAP: CN=#130442616273, O=#130442616273, C=US

4.2.2.  ACCESSPOINT Type Definition

   The ACCESSPOINT parameter is used to convey the means of access for
   this naming context.  There must be at least one value of this parameter
   in a context.


   The value of this parameter is encoded according to the following BNF:

   <AccessPoint> ::= <Preference> '#'  <Role> '#' <AccessPointData>

   <Preference> ::= <integer> |      -- or absent

   <Role> ::= 'master' | 'shadow' | 'gateway' | 'cache' |     -- or absent

   <AccessPointData> ::= <X500AccessPoint> |
                         <QuipuAccessPoint> |
                         <LDAPAccessPoint> |
                         <DNSAccessPoint> |
                         <URLAccessPoint>

   <X500AccessPoint> ::= 'X500' '#' <Serverdn> '#' <PresentationAddress>
                         [ '#' <SetOfProtocolInformation> ]

   <SetOfProtocolInformation> ::= <ProtocolInformation> |
                                  '(' <ProtocolInformationList> ')'

   <ProtocolInformationList> ::= <ProtocolInformation> |
                                 <ProtocolInformation> '$'
                                 <ProtocolInformationList>


   <QuipuAccessPoint> ::= 'QUIPU' '#' <Serverdn>

   <LDAPAccessPoint> ::= <Ldap389AP> | <Ldap636AP>

   <Ldap389AP> ::= 'LDAP' '#' [ <Serverdn> ] '#' <Hostnameportno>

   <Ldap636AP> ::= 'SSL-LDAP' '#' [ <Serverdn> ] '#' <Hostnameportno>


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

   <Serverdn> ::= <DN>

   <Hostnameportno> ::= <Hostnameorip> [ ':' <Portno>]

   <DNSAccessPoint> ::= 'DNS' '#' <Hostnameorip>

   <URLAccessPoint> ::= 'URL' '#' <Url>

   <Hostnameorip> ::= -- a fully-qualifed domain name or an IP address

   <Portno> ::= -- a TCP or UDP port number

   The encoding format of <DN> is given in [3], <PresentationAddress> in [4],
   <ProtocolInformation> in [5] and <Url> in [6].

   The <Preference> field, if present, takes as a value an integer between
   0 and 255 (inclusive).  It permits the sender to suggest relative
   preferences for the receiver to use when choosing between multiple values
   of ACCESSPOINT in this content.  In general, receivers should prefer
   access points with smaller values of preference.  If this field is absent,
   the sender does not indicate any particular relative preference for this
   value.

   The <Role> field, if present, takes on the following values:
     master: the server indicated in the access point holds the master
             copy of entries in this naming context.
     shadow: the server indicated in the access point holds a possibly
             incomplete shadow copy of entries in this naming context.
     gateway: substantial loss of content may occur if this server is
              contacted.
     cache: the server holds some information from this naming context
            which may be out of date.

   If the role field is absent, the sender does not indicate any particular
   role for the server named in the access point.

   The <X500AccessPoint> field specifies a single X.500 DSA.  It contains
   the DSA's Distinguished Name, presentation address, and an optional list
   of protocol information.  The DSA indicated will be able to perform
   operations on all entries in the naming context (possibly by contacting
   other servers or returning referrals).

   The <QuipuAccessPoint> field specifies a single X.500 DSA by its
   Distinguished Name.  The presentation address of the DSA must be obtained
   through other means, such as a content of profile "DSA".  The DSA
   indicated will be able to perform operations on entries subordinate to
   the context prefix, but not on the context prefix entry itself.

   The <LDAPAccessPoint> field specifies an LDAP server by its host name or
   IP address, and optional port number.  The default port number, 389 for
   plain LDAP and 636 for SSL-LDAP, should be used if the port number is not
   specified. The distinguished name of the server may optionally be provided.
   This server will be able to perform operations on all entries in the naming
   context (possibly by contacting other servers or returning referrals).


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

   The <DNSAccessPoint> field specifies a domain name system server by its
   host name or IP address. The <URLAccessPoint> field specifies a server
   based on its URL.  These are not currently used but are reserved for
   future extensibility.

   Example:

   AccessPoint: # # LDAP # # nameflow.dante.net

   Further examples are given in section 6.1 and 6.2.

4.2.2.1. Why a URL is not being used

   Not all the types of access described above have a URL scheme, and
   additional information is associated as each of the access points
   which are not part of today's URL definitions (such as preference).

   "URL-Unsafe" characters such as spaces or non-ASCII characters are
   extremely likely to occur in values, and that would lead to yet another
   layer of quoting, even though the content itself might be using a
   quoted-printable, base64 encoding.

   Philsophically, there is no single "data resource", like a particular
   entry, being identified in the access point.  Instead the access point
   could be used to access many different entries.

4.2.3.  BINDINGID Parameter

   This parameter should be present at most once in a content.  Its value
   is encoded according to the following BNF:

   <BindingID> ::= <Id> [ '.' <Version>]

   <Id> ::= <integer>

   <Version> ::= <integer>

   For example,

   BINDINGID: 100

   BINDINGID: 100.10

   This parameter is present only if there is an operational binding [7]
   between the sender and recipient.

5.  Related Profiles

   A MIME message containing contents of the "knowledge" profile may
   also carry contents with the "dsa", "subentry" or "cache-attributes"
   profiles.  Contents with these profiles may also be carried indpendently.

5.1. DSA Profile

   A "DSA" profile is defined as follows, using the profile registration
   template from [1].


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

   To: ietf-mime-direct@umich.edu
   Subject: Registration of application/directory MIME profile DSA

   Profile name: DSA

   Profile purpose: To hold information about a Directory System Agent
   (server).

   Profile types: NAME, PRESENTATIONADDRESS, SUPPORTEDAPPLICATIONCONTEXT,
                  BINDINGID, LASTMODIFIEDTIME

   Profile special notes:

      There are no ordering limitations on types within the content entity.

      The default transfer encoding for the profile is 7-Bit.

      The default character set is ISO-10646-UTF-8 [2].  It is recommended
      that this NOT be changed to any other character set.

      There is no default language.  It is not expected that attributes in
      this profile would be provided directly to end users.

      The default location of the type values is inline with the profile
      type.  It is strongly recommended that no multimedia attributes be
      present in contents with this profile.

      The following types are also likely to occur in this contents with
      this profile, however their values are not used by the recipient:
         CN, description, L, O, OU, seeAlso, knowledgeInformation,
         lastModifiedBy

   Intended usage: COMMON

   The associated type definitions follow, using the type registration
   template from [1].

5.1.1.  NAME Type Definition

   The NAME parameter, defined in [1], is used to convey the directory
   name of the server.  There must be exactly one value of this
   parameter in a content.

   The value of this parameter is a UTF-8 string encoding of a Distinguished
   Name, as defined in [3].

   The "PROTO" subtype parameter must be present, and its value must be "LDAP".

5.1.2.  PRESENTATIONADDRESS Type Definition

   The PRESENTATIONADDRESS parameter is used to convey the presentation address
   of the server.  There must be exactly one value of this parameter in a
   content.

   The value of this parameter is a Presentation Address as defined in [4].


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

5.1.3.  SUPPORTEDAPPLICATIONCONTEXT Type Definition

   The SUPPORTEDAPPLICATIONCONTEXT parameter is used to convey the
   application contexts supported by the server.  There may be any number of
   values of this parameter in a content.

   The value of this parameter is a string representation of an OBJECT
   IDENTIFIER, as described in [5].

   The following example values are among those likely to occur:

   supportedApplicationContext: 2.5.3.1     -- directory access
   supportedApplicationContext: 2.5.3.2     -- directory system
   supportedApplicationContext: 2.5.3.4     -- shadow consumer initiated
   supportedApplicationContext: 2.5.3.5     -- shadow supplier initiated
   supportedApplicationContext: 0.9.2342.19200300.99.4     -- QUIPU DSP
   supportedApplicationContext: 0.9.2342.19200300.100.8    -- Internet DSP

5.1.4.  LASTMODIFIEDTIME Type Definition

   The LASTMODIFIEDTIME parameter is used to convey the time this entry
   was last modified.  There may be at most one value of this parameter in
   a content.

   The value of the parameter is a UTCTime, as described in [5].

5.2. Subentry Profile

   A "SUBENTRY" profile is defined as follows, using the profile registration
   template from [1].


   To: ietf-mime-direct@umich.edu
   Subject: Registration of application/directory MIME profile SUBENTRY

   Profile name: SUBENTRY

   Profile purpose: To hold information from a subentry.

   Profile types: NAME, BINDINGID, subtreeSpecification, CN, dseType,
      entryACI, prescriptiveACI,
      creatorsName, createTimestamp, modifiersName, modifyTimestamp,
      dITStructureRules, nameForms, ditContentRules, objectClasses,
      attributeTypes, matchingRules, matchingRuleUse,
      collectiveLocalityName, collectiveStateOrProvinceName,
      collectiveStreetAddress, collectiveOrganizationName,
      collectiveOrganizationalUnitName, collectivePostalAddress,
      collectivePostalCode, collectivePostOfficeBox,
      collectivePhysicalDeliveryOfficeName,
      collectiveTelephoneNumber, collectiveTelexNumber,
      collectiveTeletexTerminalIdentifier,
      collectiveFacsimileTelephoneNumber,
      collectiveInternationaliSDNNumber

   Profile special notes:

      There are no ordering limitations on types within the content entity.


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

      The default transfer encoding for the profile is 7-Bit.

      The default character set is ISO-10646-UTF-8 [2].  It is recommended
      that this NOT be changed to any other character set.

      There is no default language.  It is not expected that attributes in
      this profile would be provided directly to end users.

      The default location of the type values is inline with the profile
      type.  It is strongly recommended that no multimedia attributes be
      present in contents with this profile.

   Intended usage: COMMON

   With the exception of NAME and BINDINGID, which are described above,
   the rest of type parameters are those likely to be in subentries.  They are
   as described in [5].

5.3.  Attributes for Caching Profile

   A "CACHE-ATTRIBUTES" profile is defined as follows, using the profile
   registration template from [1].

   To: ietf-mime-direct@umich.edu
   Subject: Registration of application/directory MIME profile CACHE-ATTRIBUTES

   Profile name: CACHE-ATTRIBUTES

   Profile purpose: To hold arbitrary attributes which may be cached
      and used in matching search filters.

   Profile types: NAME, BINDINGID, etc

   Profile special notes:

      There are no ordering limitations on types within the content entity.

      The default transfer encoding for the profile is 7-Bit.

      The default character set is ISO-10646-UTF-8 [2].  It is recommended
      that this NOT be changed to any other character set.

      There is no default language.

      The default location of the type values is inline with the profile
      type.  It is strongly recommended that no multimedia attributes be
      present in contents with this profile.

   Intended usage: COMMON

   With the exception of NAME and BINDINGID, which are described above,
   the content may contain any attribute of [5] which the sender wishes to
   have cached by the recipient.  These could include administrativeRole,
   accessControlScheme, objectClass, aliasedObjectName, description etc.


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

6.  Examples

   Section 6.1 is an example of what a server holding the naming context
   "O=Foo,C=US" might send to the server holding the naming context "C=US",
   in order to have the subordinate context added to the directory.  Section
   6.2 is an example of what the "C=US" server might return as a response.

6.1.

   MIME-Version: 1.0
   Content-Type: multipart/mixed; boundary="break"
   Content-Description: information about O=Foo,C=US

   --break
   Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8"

   Name;PROTO=LDAP: O=Foo, C=US
   AccessPoint: # master # LDAP # CN=Server, O=Foo, C=US # server.foo.com
   --break
   Content-Type: application/directory; profile="cache-attributes"; charset="iso-10646-utf-8"

   Name;PROTO=LDAP: O=Foo, C=US
   O: Foo
   Description: Makers of the Foo line of Widgets
   --break--


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

6.2.

   MIME-Version: 1.0
   Content-Type: multipart/mixed; boundary="break"
   Content-Description: information about O=Foo,C=US and superiors

   --break
   Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8"

   Name;PROTO=LDAP:
   AccessPoint: # gateway # LDAP # # nameflow.dante.net
   --break
   Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8"

   Name;PROTO=LDAP: C=US
   AccessPoint: 30 # master # QUIPU # CN=EDB Beetle
   AccessPoint: 10 # shadow # X500 # CN=U,C=US # "X500"/Internet=us.net+19999
   AccessPoint: 20 # gateway # LDAP # # nameflow.dante.net
   --break
   Content-Type: application/directory; profile="DSA"; charset="iso-10646-utf-8"

   Name;PROTO=LDAP: CN=EDB Beetle
   Description: the Endangered EDB-only Beetle
   Description: supports DAP, DSP, IDSP and QDSP
   PresentationAddress: "X500"/Internet=us.net+17003
   SupportedApplicationContext: 2.5.3.1
   SupportedApplicationContext: 2.5.3.2
   SupportedApplicationContext: 0.9.2342.19200300.99.4
   SupportedApplicationContext: 0.9.2342.19200300.100.8
   --break
   Content-Type: application/directory; profile="knowledge"; charset="iso-10646-utf-8"

   Name;PROTO=LDAP: O=Foo, C=US
   AccessPoint: 0 # master # LDAP # CN=Server, O=Foo, C=US # server.foo.com
   AccessPoint: 128 # gateway # X500 # CN=U,C=US # "X500"/Internet=us.net+19999
   --break
   Content-Type: application/directory; profile="cache-attributes"; charset="utf8"

   Name;PROTO=LDAP: C=US
   C: US
   CO: United States of America
   Description: Land of the Free
   Description: Home of the Brave
   --break--


7.  Security Considerations

   Internet mail is subject to many well known security attacks, including
   monitoring, replay, and forgery.  Care should be taken by any directory
   service in allowing information to leave the scope of the service
   itself, where any access controls can no longer be guaranteed.

   Applications should also take care to display directory data in a "safe"
   environment (e.g., PostScript-valued types).


INTERNET DRAFT   Application/Directory Profile for Knowledge   August 1996

8.  Bibliography

   [1] T. Howes, M. Smith, "A MIME Content-Type for Directory Information",
       INTERNET DRAFT <draft-ietf-asid-mime-direct-02.txt",  July 1996.

   [2] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1.

   [3] M. Wahl, S. Kille, "A UTF-8 String Representation of Distinguished
       Names", INTERNET DRAFT <draft-ietf-asid-ldapv3-dn-00.txt>, August 1996.

   [4] S. Kille, "A String Representation for Presentation Addresses",
       RFC 1278, University College London, November 1991.

   [5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "LDAP Standard and Pilot
       Attribute Definitions", INTERNET DRAFT
       <draft-ietf-asid-ldapv3-attributes-02.txt>, August 1996.

   [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
       Locations (URL)", RFC 1738, December 1994.

   [7] The Directory: Models. ITU-T Recommendation X.501, 1993.





































<draft-wahl-know-mime-00.txt>           Expires: February 28, 1997