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 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: ::= '#' '#' ::= | -- or absent ::= 'master' | 'shadow' | 'gateway' | 'cache' | -- or absent ::= | | | | ::= 'X500' '#' '#' [ '#' ] ::= | '(' ')' ::= | '$' ::= 'QUIPU' '#' ::= | ::= 'LDAP' '#' [ ] '#' ::= 'SSL-LDAP' '#' [ ] '#' INTERNET DRAFT Application/Directory Profile for Knowledge August 1996 ::= ::= [ ':' ] ::= 'DNS' '#' ::= 'URL' '#' ::= -- a fully-qualifed domain name or an IP address ::= -- a TCP or UDP port number The encoding format of is given in [3], in [4], in [5] and in [6]. The 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 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 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 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 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 field specifies a domain name system server by its host name or IP address. The 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: ::= [ '.' ] ::= ::= 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 , 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 , 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. Expires: February 28, 1997