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