mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-01-18 11:05:48 +08:00
1. adding LDAP relevant RFC's
This commit is contained in:
Stuart Lynne
parent
653846f8e9
commit
6252c1871a
3363
doc/rfc/rfc1274.txt
Normal file
3363
doc/rfc/rfc1274.txt
Normal file
File diff suppressed because it is too large
Load Diff
202
doc/rfc/rfc1275.txt
Normal file
202
doc/rfc/rfc1275.txt
Normal file
@ -0,0 +1,202 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S.E. Hardcastle-Kille
|
||||
Requests for Comments 1275 University College London
|
||||
November 1991
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Replication Requirements to provide an Internet Directory using X.500
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Status of this Memo
|
||||
This memo provides information for the Internet community. It
|
||||
does not specify an Internet standard. Distribution of this memo
|
||||
is unlimited.
|
||||
Abstract
|
||||
|
||||
This RFCconsiders certain deficiencies of the 1988 X.500
|
||||
standard, which need to be addressed before an effective open
|
||||
Internet Directory can be established using these protocols and
|
||||
services [CCI88]. The only areas considered are primary
|
||||
problems, to which solutions must be found before a pilot can be
|
||||
deployed. This RFCconcerns itself with deficiencies which can
|
||||
only be addressed by use of additional protocol or procedures for
|
||||
distributed operation.
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1275 Replication Requirements November 1991
|
||||
|
||||
|
||||
1 Distributed Operation Extensions
|
||||
|
||||
The Internet Directory will operate DSAs over TCP/IP using RFC 1006
|
||||
[RC87], and DSAs over the an ISO Network Service. Distributed
|
||||
operation procedures should not require full connectivity.
|
||||
|
||||
|
||||
2 Knowledge Replication
|
||||
|
||||
Knowledge information is critical to resolution of names, and
|
||||
performing searches. Knowledge information high up the tree needs to
|
||||
be widely available. Consider resolving a name below ``Country=US''.
|
||||
To do this, a DSA needs to have full knowledge at this point. Many
|
||||
DSAs need to be able to do this, in order to give reasonable response
|
||||
and availability. It would be an unacceptable bottleneck to force
|
||||
such resolution to a single or small number of DSAs. To replicate
|
||||
this knowledge widely, a systematic approach to replication is needed.
|
||||
|
||||
|
||||
3 Data Replication
|
||||
|
||||
Searches are often made at the root and country level, and this is a
|
||||
vital service (e.g., an approximate match of an organisation name).
|
||||
Data needs to be collected in such a way that this sort of searching
|
||||
is reasonably efficient. The usual X.500 approach of subordinate
|
||||
references militates against this. At a node in the DIT, subordinate
|
||||
references to the entries below are held. These entries will be in
|
||||
many DSAs, each of which needs to be accessed in order to perform the
|
||||
single level search. It is suggested that replication of data is
|
||||
necessary to achieve this.
|
||||
|
||||
The major requirement for this replication is high up the DIT, where
|
||||
information must be replicated between different implementations. At
|
||||
lower levels of the DIT, it is reasonable for DSAs to be of the same
|
||||
implementation and to use implementation specific techniques in order
|
||||
to achieve performance and availability.
|
||||
|
||||
|
||||
4 Alternate DSAs
|
||||
|
||||
When a DSA Referral is returned, only the master DSA is indicated.
|
||||
This will lead to a single point of failure. It seems important to
|
||||
allow for additional references to slave copies, in order to get
|
||||
|
||||
|
||||
Hardcastle-Kille Page 1
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1275 Replication Requirements November 1991
|
||||
|
||||
|
||||
better availability. This needs to be solved in conjunction with the
|
||||
problem described in the previous section.
|
||||
|
||||
|
||||
5 Guidelines for use of Replication
|
||||
|
||||
To be effective, the replication specification needs to provide
|
||||
guidelines for deployment in the pilot, in order to meet the desired
|
||||
service criteria.
|
||||
|
||||
|
||||
6 Some scaling targets
|
||||
|
||||
Most techniques for replication have scaling limits. It is important
|
||||
that mechanisms used do not stress the limits of the mechanism. The
|
||||
order of magnitude envisioned in the pilot is 100 000 non-leaf entries
|
||||
and several million leaf entries.
|
||||
|
||||
|
||||
References
|
||||
|
||||
[CCI88] The Directory --- overview of concepts, models and services,
|
||||
December 1988. CCITT X.500 Series Recommendations.
|
||||
|
||||
[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services
|
||||
on top of the TCP. Request for Comments 1006, Northrop
|
||||
Corporation Technology Center, May 1987.
|
||||
|
||||
|
||||
7 Security Considerations
|
||||
|
||||
Security considerations are not discussed in this memo.
|
||||
|
||||
|
||||
8 Author's Address
|
||||
|
||||
Steve Hardcastle-Kille
|
||||
Department of Computer Science
|
||||
University College London
|
||||
Gower Street
|
||||
WC1E 6BT
|
||||
England
|
||||
|
||||
|
||||
|
||||
Hardcastle-Kille Page 2
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1275 Replication Requirements November 1991
|
||||
|
||||
|
||||
Phone: +44-71-380-7294
|
||||
|
||||
EMail: S.Kille@CS.UCL.AC.UK
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardcastle-Kille Page 3
|
||||
|
||||
839
doc/rfc/rfc1279.txt
Normal file
839
doc/rfc/rfc1279.txt
Normal file
@ -0,0 +1,839 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S.E. Hardcastle-Kille
|
||||
Requests for Comments 1279 University College London
|
||||
November 1991
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
X.500 and Domains
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Status of this Memo
|
||||
This memo defines an Experimental Protocol for the Internet
|
||||
community. Discussion and suggestions for improvement are
|
||||
requested. Please refer to the current edition of the ``IAB
|
||||
Official Protocol Standards'' for the standardization state and
|
||||
status of this protocol. Distribution of this memo is unlimited.
|
||||
Abstract
|
||||
|
||||
This RFCconsiders X.500 in relation to Internet and UK Domains.
|
||||
A basic model of X.500 providing a higher level and more
|
||||
descriptive naming structure is emphasised. In addition, a
|
||||
mapping of domains onto X.500 is proposed, which gives a range of
|
||||
new management and user facilities over and above those currently
|
||||
available. This specification proposes an experimental new
|
||||
mechanism to access and manage domain information on the Internet
|
||||
and in the UK Academic Community. There is no current intention
|
||||
to provide an operational replacement for DNS.
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
1 The Domain Name System
|
||||
|
||||
The Domain (Nameserver) System (DNS) provides a hierarchical resource
|
||||
labelling system [Moc87a] [Moc87b] [Lar83]. Example domains are:
|
||||
|
||||
MIT.EDU
|
||||
VENERA.ISI.EDU
|
||||
CS.UCL.AC.UK
|
||||
|
||||
|
||||
Entries usually have a single name, although pointers to entries (not
|
||||
subtrees) may be provided by CNAME records. Information (resource
|
||||
records) is associated with each entry. Name components are typically
|
||||
chosen to be shortish (e.g., ``CS'').
|
||||
RFC 822 mailbox names are closely related [Cro82]. For example:
|
||||
|
||||
|
||||
<S.Kille@CS.UCL.AC.UK>
|
||||
|
||||
The local-part of the RFC 822 mailbox can be considered as one level
|
||||
lower in the domain hierarchy.
|
||||
|
||||
|
||||
2 X.500
|
||||
|
||||
The OSI Directory, usually known as X.500, provides a very general
|
||||
naming framework [CCI88]. A basic usage of X.500 is to provide
|
||||
Organisationally Structured Names. A Schema for this is defined
|
||||
within the standard. Name components will typically have longish
|
||||
values. This is an example directory name represented in Tabular
|
||||
form:
|
||||
|
||||
|
||||
Country GB
|
||||
Organisation University College London
|
||||
Organisational Unit Computer Science
|
||||
Common Name Stephen E. Hardcastle-Kille
|
||||
|
||||
This can also be written in the ``User Friendly Name'' notation
|
||||
defined in [HK91]. This syntax is used for names in the rest of this
|
||||
document:
|
||||
|
||||
|
||||
Stephen E. Hardcastle-Kille, Computer Science,
|
||||
|
||||
Hardcastle-Kille Page 1
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
University College London, GB
|
||||
|
||||
This type of structure is termed ``organisational X.500''. This is a
|
||||
subset of the general capabilities.
|
||||
|
||||
|
||||
3 The basic model
|
||||
|
||||
X.500 has as much relation to the DNS as DNS has to ARP. Paul
|
||||
Mockapetris
|
||||
|
||||
|
||||
This is, essentially, the position adopted here. The basic model is
|
||||
that organisational X.500 is providing a layer of naming at the level
|
||||
above domain names. These structured names can be considered to form
|
||||
a naming layer above domain names. There are the following key
|
||||
differences:
|
||||
|
||||
o Organisational X.500 tends to use longer and more descriptive
|
||||
values
|
||||
|
||||
o The organisational X.500 DIT is slightly shallower than the DNS
|
||||
tree
|
||||
|
||||
o X.500 has a richer information framework than DNS
|
||||
|
||||
|
||||
These differences suggest that the following should NOT be done:
|
||||
|
||||
o Represent X.500 information in the DNS
|
||||
|
||||
o Have an algorithmic mapping between the two hierarchies
|
||||
|
||||
This note proposes to represent DNS information in the DIT, and to
|
||||
provide for a loose coupling between the two trees. This note does
|
||||
not propose an equivalencing of X.500 and Domains.
|
||||
|
||||
The proposed model is illustrated in Figure 1. Both an organisational
|
||||
and domain structure is represented in the DIT, by use of appropriate
|
||||
object classes and attribute types. A weak linkage is provided
|
||||
between the two parts of the tree by use of special attributes. Here,
|
||||
the linkage is 1:1, but it may be more complex for some parts of the
|
||||
organisational DIT or domain namespace. The linkage is achieved by
|
||||
use of special attributes, as described in Section 11.
|
||||
|
||||
Hardcastle-Kille Page 2
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
j jZ Z
|
||||
|
||||
j j ZZ
|
||||
jj Z Z
|
||||
jjj ZZ
|
||||
|
||||
Domain Component=UK Country Name=GB
|
||||
|
|
||||
|
|
||||
|
|
||||
Domain Component=AC Organisation Name=Univeristy College London
|
||||
|
||||
* BB
|
||||
ss BBB
|
||||
|
||||
Domain Component=UCL Org Unit Name=Computer Science
|
||||
| *
|
||||
|
||||
|| ss
|
||||
Domain Component=CS Common Name=Steve Kille
|
||||
|
||||
| *
|
||||
| ss
|
||||
|
||||
Domain Component=S.Kille
|
||||
Figure 1: Example X.500 tree
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardcastle-Kille Page 3
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
4 Representing Domains in X.500
|
||||
|
||||
Domains are at the level below X.500 names of the form illustrated in
|
||||
the previous section. However, it is also possible to use X.500 in
|
||||
other ways. In particular, there are benefits from representing
|
||||
Domains in X.500. Note that this is very different to equivalencing,
|
||||
as no attempt is made to represent X.500 information within the domain
|
||||
scheme. There are the following potential advantages:
|
||||
|
||||
|
||||
o Domain Services (DNS and NRS) could be replaced with an OSI
|
||||
service (some may not view this as an advantage). This is
|
||||
particularly attractive for OSI services, where use of a non-OSI
|
||||
directory may be inappropriate.
|
||||
|
||||
o For Internet sites, access to domain information (beyond MX
|
||||
records) could be provided for systems registered remotely. For
|
||||
UK Academic Community sites, access to domain information for
|
||||
domains not registered in the NRS could be given. For sites
|
||||
neither on the Internet nor in the UK Academic Community there
|
||||
will usually be even more of an advantage, as they usually have
|
||||
very limited information on domains.
|
||||
|
||||
o Assuming that information is downloaded from an X.500 database
|
||||
into a DNS or NRS system, the remote management facilities of
|
||||
X.500 could be used. This is possible because of the extra
|
||||
security features of X.500.
|
||||
|
||||
Note: For initial work, the converse situation of information
|
||||
being mastered in Domain Databases and uploaded into the X.500
|
||||
DIT is more likely.
|
||||
|
||||
o User access to the domain data, and in particular searching, could
|
||||
be provided. This would allow users to browse the domain
|
||||
namespace, and to determine information associated with the
|
||||
domains.
|
||||
|
||||
o The X.500 framework would allow for additional management
|
||||
information to be stored, and to relate the domain names into a
|
||||
more complex structure of information. For example, this might
|
||||
allow for the managers of a system to be identified, and
|
||||
information on how to contact the manager.
|
||||
|
||||
|
||||
|
||||
Hardcastle-Kille Page 4
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
o A facility to map RFC 822 mailbox into a Directory Name (and thus
|
||||
access other user information on the basis of this key) could be
|
||||
provided. This may be useful for the user to determine
|
||||
information about a message originator.
|
||||
|
||||
o This technique may be useful to facilitate introduction of
|
||||
security, as it will enable certificates to be associated with
|
||||
domains and mailboxes. This may be very useful for the privacy
|
||||
enchanced mail work [Lin89].
|
||||
|
||||
|
||||
5 Representing Domain Names
|
||||
|
||||
A new attribute syntax is defined:
|
||||
|
||||
|
||||
CaseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
|
||||
IA5String
|
||||
MATCHES FOR EQUALITY SUBSTRINGS ORDERING
|
||||
|
||||
|
||||
A new attribute and two new object classes are defined:
|
||||
|
||||
|
||||
DomainComponent ATTRIBUTE
|
||||
WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax
|
||||
SINGLE VALUE
|
||||
|
||||
Domain OBJECT-CLASS
|
||||
SUBCLASS OF top
|
||||
MUST CONTAIN -DomainComponent"
|
||||
MAY CONTAIN -AssociatedName,
|
||||
organizationName,
|
||||
organizationalAttributeSet,
|
||||
manager"
|
||||
|
||||
RFC822Mailbox OBJECT-CLASS
|
||||
SUBCLASS OF Domain
|
||||
MAY CONTAIN -commonName,
|
||||
surname,
|
||||
description,
|
||||
telephoneNumber,
|
||||
postalAttributeSet,
|
||||
telecommunicationAttributeSet "
|
||||
|
||||
Hardcastle-Kille Page 5
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
Note that the attribute AssociatedName is defined in Section 11. The
|
||||
manager attribute is defined in the COSINE and Internet naming
|
||||
architecture [BHK91]. It allows a manager to be associated with the
|
||||
domain, which is useful where the manager of the domain is different
|
||||
to the manager of the object defined by the AssociatedName. This will
|
||||
allow any domain to be represented in an X.500 hierarchy. The local
|
||||
part of an RFC 822 mailbox is treated as a special sort of domain
|
||||
component, and so these can be represented in the tree as a natural
|
||||
extension of the hierarchy.
|
||||
For example, consider the mailbox S.Kille@cs.ucl.ac.uk. This will
|
||||
lead to the following structure in the DIT:
|
||||
|
||||
___________________________________________
|
||||
|_Object_Class__|RDN_Type________|RDN_Value_|
|
||||
| Domain |DomainComponent |UK |
|
||||
| Domain |DomainComponent |AC |
|
||||
| Domain |DomainComponent |UCL |
|
||||
| Domain |DomainComponent |CS |
|
||||
|_RFC822Mailbox_|DomainComponent_|S.Kille__ |
|
||||
|
||||
This can be represented in User Friendly Name format as:
|
||||
|
||||
|
||||
DomainComponent=S.Kille, DomainComponent=CS, DomainComponent=UCL,
|
||||
DomainComponent=AC, DomainComponent=UK
|
||||
|
||||
Note that the RFC822Mailbox Object Class is a subclass of Domain.
|
||||
Some attributes are allowed to be associated with these objects.
|
||||
There may be other additional management attributes which it is useful
|
||||
to define (e.g., Machine Type, Owner, Location etc.). This allows
|
||||
some information which truly belongs to the domain to be represented
|
||||
there. It also allows for further information to be associated with
|
||||
the domain/mailbox when there is not a relevant part of the
|
||||
organisationally structure DIT to be pointed at. When there is an
|
||||
associated part of the DIT, information from that part of the DIT
|
||||
should not be duplicated in the domain entry.
|
||||
|
||||
|
||||
6 Wildcards
|
||||
|
||||
|
||||
Wildcards are supported by having "*" as a special domain component
|
||||
name. If there is a need to emulate wildcard matching using the
|
||||
directory, the following algorithm must be employed. For example, the
|
||||
|
||||
Hardcastle-Kille Page 6
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
wildcard entry for *.*.PODUNK.COM would be represented in the DIT as:
|
||||
|
||||
DomainComponent=*, DomainComponent=*,
|
||||
DomainComponent=MIT, DomainComponent=COM
|
||||
|
||||
|
||||
If A.B.PODUNK.COM is looked up in the directory, the query will fail
|
||||
and indicate that two components are matched. A substitution should
|
||||
be made, and *.*.PODUNK.COM looked up explicitly to identify the
|
||||
associated information.
|
||||
|
||||
|
||||
7 DNS Information
|
||||
|
||||
DNS information can be associated with an entry in the DIT. It is
|
||||
important that this is done in a manner which is exactly equivalent to
|
||||
the information stored in the DNS. This will allow the DIT to have
|
||||
information loaded from the DNS or vice versa. All (authoritative)
|
||||
records associated with a domain will be stored in the DIT. There is
|
||||
no attempt made by the OSI Directory to emulate DNS caching or TTL
|
||||
handling. It is assumed that the master entries are maintained by use
|
||||
of DNS Zone Transfer (or equivalent), and that they can be treated as
|
||||
authoritative. There is a need to define an attribute syntax which
|
||||
represents a DNS record. This then allows DNS records to be stored in
|
||||
the DIT. There are three possible encodings of this record:
|
||||
|
||||
ASN.1 Encoded This is the most natural approach in terms of X.500.
|
||||
However, it would require all users of this service to handle the
|
||||
new syntax, which would be awkward. There is a problem with
|
||||
handling the resource format in a general manner.
|
||||
|
||||
DNS Binary Encoded Use the formally defined record syntax. This
|
||||
would be convenient for access to the data by DNS related
|
||||
software, but would be an awkward encoding for independent X.500
|
||||
DUAs.
|
||||
|
||||
Text encoded Use of a text encoding derived from the DNS
|
||||
specifications. This is straightforward to map onto DNS protocol,
|
||||
and easy to support in a naive X.500 DUA. This approach is chosen.
|
||||
|
||||
|
||||
The syntax is defined in IA5 characters. The BNF of the record uses
|
||||
the definitions of section 5.1 of RFC 1035. It is
|
||||
|
||||
|
||||
Hardcastle-Kille Page 7
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
<rr> [ ";" <comment> ]
|
||||
|
||||
Three examples of this (for domain C.ISI.EDU) might be:
|
||||
|
||||
|
||||
500 A 10.1.0.52 ; Basic address record
|
||||
IN 600 MX 10 VENERA.ISI.EDU. ; MX record
|
||||
600 IN MX 10 VENERA.ISI.EDU. ; MX record - other order
|
||||
|
||||
Note that:
|
||||
|
||||
|
||||
o The class and TTL may be in either order (following RFC 1035)
|
||||
|
||||
o The class defaults to IN
|
||||
|
||||
o Domains must always be fully specified (i.e., master file
|
||||
abbreviate rules are not used).
|
||||
|
||||
o The TTL for a record must always be present (this saves looking at
|
||||
the parent entry to find the SOA record).
|
||||
|
||||
o Records (e.g., SOA) may be multiline. Lines should be separated
|
||||
with the two IA5 characters <CR><LF>.
|
||||
|
||||
CNAME records are mapped symmetrically onto Directory Aliases.
|
||||
|
||||
This is now defined in terms of attribute and object class
|
||||
definitions. A single record type is defined, as opposed to one
|
||||
attribute type per record type. This allows the definition to not
|
||||
require extension when new DNS Record types are define. However,
|
||||
there is some loss of efficiency if only a single record type is
|
||||
needed, as filtering must be done by the DUA.
|
||||
Similarly, no distinction is made on the basis of DNS class. This
|
||||
means that if there are two class hierarchies, that they must be
|
||||
represented in a single DIT, and that information for different
|
||||
classes must be separated by DUA filtering.
|
||||
|
||||
|
||||
DNSDomain OBJECT-CLASS
|
||||
SUBCLASS OF Domain
|
||||
MAY CONTAIN -
|
||||
DNSRecord "
|
||||
|
||||
|
||||
Hardcastle-Kille Page 8
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
DNSRecord ATTRIBUTE
|
||||
ATTRIBUTE-SYNTAX IA5String
|
||||
MATCHES FOR EQUALITY
|
||||
|
||||
|
||||
Lookup of a domain is achieved by translating it algorithmically to a
|
||||
Distinguished Name (DN), and reading back attributes desired. This
|
||||
information can be managed and searched in a straightforward fashion.
|
||||
|
||||
The information may also be downloaded into a DNS database. This
|
||||
should be done by use of zone transfer. A tool to perform zone
|
||||
transfer (in both directions) between a DNS Server and a DSA would
|
||||
seem to be both straightforward and useful. This would be a key tool
|
||||
in a transition to X.500 based management of the DNS. It would also
|
||||
allow a large part of the DNS namespace to be rapidly made available
|
||||
in an X.500 pilot.
|
||||
Inverse information can be derived by the usual IN-ADDR domain, which
|
||||
will be represented in the same manner in the DIT.
|
||||
|
||||
|
||||
8 NRS Information
|
||||
|
||||
Information associated with the UK NRS (Name Registration Scheme) can
|
||||
be handled in a similar manner [Lar83]. This is being developed in a
|
||||
separate document by Alan Turland.
|
||||
|
||||
|
||||
9 Application Entity Titles
|
||||
|
||||
In many cases, Application entities will be closely related to
|
||||
domains. In some cases, it may be appropriate to give Application
|
||||
Entities names which are related to the DNS part of the DIT. In this
|
||||
case, the Domain Name will be used to identify the application, and
|
||||
the entry for the domain will also be of object class Application
|
||||
Process. The children of this entry will identify Application
|
||||
Entities, with names such as ``FTAM Service''.
|
||||
|
||||
|
||||
10 Networks
|
||||
|
||||
|
||||
It is clearly useful to represent networks within the DIT. A short
|
||||
note on how to do this is given here. It is likely that this
|
||||
specification will later be evolved in a separate document. This
|
||||
|
||||
Hardcastle-Kille Page 9
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
defines an Object Class for a general network, and shows how it can be
|
||||
subclassed to define technology specific networks.
|
||||
|
||||
Network OBJECT-CLASS
|
||||
SUBCLASS OF TOP
|
||||
MAY CONTAIN -
|
||||
Manager,
|
||||
Locality,
|
||||
Description "
|
||||
|
||||
IPNetwork OBJECT-CLASS
|
||||
SUBCLASS OF Network
|
||||
MUST CONTAIN -AssociatedDomain"
|
||||
|
||||
|
||||
The Network Object Class allows networks to be defined, and for useful
|
||||
attributes to be associated with the entry. A network will often
|
||||
appear in more than one organisational structure, and this linkage
|
||||
should be achieved by use of aliases. This grouping can facilitate
|
||||
management of networks.
|
||||
The subclass IPNetwork mandates linkage into the DNS part of the DIT.
|
||||
This will be represented in the DIT using the structures of RFC 1101
|
||||
[Moc89]. Both of the domains which identify the network should be
|
||||
represented in the Object Class. For example, a network might have
|
||||
the (user friendly) name:
|
||||
|
||||
UCL-Ethernet, University College London, GB
|
||||
|
||||
|
||||
This would have associated domains 0.0.40.128.IN-ADDR.ARPA and
|
||||
UCL-ETHERNET.UCL.AC.UK. These would both have the analogous DIT
|
||||
representations. For example:
|
||||
|
||||
DomainComponent=0, DomainComponent=0, DomainComponent=40,
|
||||
DomainComponent=128, DomainComponent=IN-ADDR, DomainComponent=ARPA
|
||||
|
||||
|
||||
11 Linkage
|
||||
|
||||
|
||||
There is a need to associate the organisational X.500 DIT and the DNS
|
||||
tree. The objects represented are different (Domain 6= Organisation;
|
||||
Person 6= RFC 822 Mailbox). Therefore aliasing is not an appropriate
|
||||
linkage. However, in many cases, there is a linkage which is rather
|
||||
|
||||
Hardcastle-Kille Page 10
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
stronger than that implied by the seeAlso attribute. Therefore, we
|
||||
define new attributes, which represent this stronger cross-linkage.
|
||||
The same mechanism can be used to link a domains with an Application
|
||||
Entity or an Application Process.
|
||||
Links from the organisational X.500 DIT to the DNS tree are provided
|
||||
by a new attribute, which could be present in Organisation or
|
||||
Organisational Unit entries.
|
||||
|
||||
|
||||
ObjectWithAssociatedDomain OBJECT-CLASS
|
||||
SUBCLASS OF top
|
||||
MUST CONTAIN -AssociatedDomain"
|
||||
|
||||
AssociatedDomain ATTRIBUTE
|
||||
WITH ATTRIBUTE-SYNTAX ia5StringSyntax
|
||||
|
||||
For example, the organisational entry:
|
||||
|
||||
University College London, GB
|
||||
|
||||
|
||||
would have an attribute:
|
||||
|
||||
AssociatedDomain = UCL.AC.UK
|
||||
|
||||
|
||||
Similarly, an RFC 822 mailbox attribute is used to link entries of
|
||||
Person Object Class to their associated DNS entry. This attribute is
|
||||
defined in the Cosine and Internet Naming Architecture [BHK91].
|
||||
Conversely, there are pointers from the DNS represented tree into the
|
||||
organisational X.500 DIT:
|
||||
|
||||
|
||||
AssociatedName ATTRIBUTE
|
||||
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
|
||||
|
||||
This attribute is associated with the Domain object class.
|
||||
|
||||
This entry is used to provide linkage from the DNS X.500 Hierarchy
|
||||
into the organisational X.500 hierarchy. Where such entries do not
|
||||
exist, attributes in the DNS entry (such as phone number) may be used.
|
||||
It is recommended that information is not duplicated. The preferred
|
||||
setup is for the DNS attributes to be rather skeletal, with pointers
|
||||
into the organisational X.500 DIT.
|
||||
|
||||
Hardcastle-Kille Page 11
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
For example, the domain UCL.AC.UK would be represented in the DIT as:
|
||||
|
||||
DomainComponent=UCL, DomainComponent=AC,
|
||||
DomainComponent=UK
|
||||
|
||||
|
||||
This entry would have in it an AssociatedName attribute with value:
|
||||
|
||||
University College London, GB
|
||||
|
||||
|
||||
This example shows a simple case with 1:1 linkage. There are cases
|
||||
where a domain might be associated with multiple organisations, or an
|
||||
organisation with multiple domains.
|
||||
|
||||
|
||||
12 Conclusions and proposals for evaluation
|
||||
|
||||
Experiments should be undertaken to determine the practicality and
|
||||
utility of this scheme, in a pilot environment. A possible approach
|
||||
to this experimentation is described in Appendix A.
|
||||
Object Identifiers have been assigned for this purpose in the Cosine
|
||||
and Internet Naming Architecture [BHK91].
|
||||
|
||||
|
||||
References
|
||||
|
||||
[BHK91] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
|
||||
X.500 schema. Request for Comments RFC 1274, Department of
|
||||
Computer Science, University College London, November 1991.
|
||||
|
||||
[CCI88] The Directory --- overview of concepts, models and services,
|
||||
December 1988. CCITT X.500 Series Recommendations.
|
||||
|
||||
[Cro82] D.H. Crocker. Standard of the format of ARPA internet text
|
||||
messages. Request for Comments 822, University of Delaware,
|
||||
August 1982.
|
||||
|
||||
[HK91] S.E. Hardcastle-Kille. Using the OSI directory to achieve
|
||||
user friendly naming. Request for Comments in preparation,
|
||||
Department of Computer Science, University College London,
|
||||
November 1991.
|
||||
|
||||
|
||||
|
||||
Hardcastle-Kille Page 12
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
[Lar83] J. Larmouth. JNT name registration technical guide, April
|
||||
1983.
|
||||
|
||||
[Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail:
|
||||
Part 1 --- Message Encipherment and Authentication
|
||||
Procedures. Request for Comments 1113, Bolt, Beranek, and
|
||||
Newman, August 1989.
|
||||
|
||||
[Moc87a] P. Mockapetris. Domain names - concepts and facilities.
|
||||
Request for Comments RFC 1034, USC/Information Sciences
|
||||
Institute, November 1987.
|
||||
|
||||
[Moc87b] P. Mockapetris. Domain names - implementation and
|
||||
specification. Request for Comments RFC 1035,
|
||||
USC/Information Sciences Institute, November 1987.
|
||||
|
||||
[Moc89] P. Mockapetris. DNS encoding of network names and other
|
||||
types. Request for Comments RFC 1101, USC/Information
|
||||
Sciences Institute, April 1989.
|
||||
|
||||
|
||||
13 Security Considerations
|
||||
|
||||
This memo does not directly address security issues. However, due to
|
||||
the facilities of X.500, this proposal could lead to a more secure way
|
||||
to access and manage domain information.
|
||||
|
||||
|
||||
14 Author's Address
|
||||
|
||||
Steve Hardcastle-Kille
|
||||
Department of Computer Science
|
||||
University College London
|
||||
Gower Street
|
||||
WC1E 6BT
|
||||
England
|
||||
|
||||
Phone: +44-71-380-7294
|
||||
|
||||
|
||||
EMail: S.Kille@CS.UCL.AC.UK
|
||||
|
||||
|
||||
|
||||
|
||||
Hardcastle-Kille Page 13
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
A Possible Deployment Approach
|
||||
|
||||
This appendix notes a possible approach to deploying an experiment to
|
||||
evaluate this mechanism. The following components of a possible
|
||||
experiment are noted.
|
||||
|
||||
|
||||
1. User tool. This will take a domain or mailbox as input. This
|
||||
will be looked up in the DIT. This tool should be capable of:
|
||||
|
||||
o Attempting to correct user input
|
||||
|
||||
o Helping browsing
|
||||
|
||||
o Looking up information associated with the domain (or mailbox)
|
||||
and associated name, in particular the manager (of both domain
|
||||
and associated name) and information on the manager (e.g.,
|
||||
phone number and mailbox).
|
||||
|
||||
o Supply DNS records
|
||||
|
||||
o Handle IN-ADDR.ARPA inverse lookups if supplied with an IP
|
||||
Address
|
||||
|
||||
o Look up networks
|
||||
|
||||
2. A procedural library to allow user interfaces to make easy use of
|
||||
these facilities.
|
||||
|
||||
3. Zone transfer tool. This will use the zone transfer protocol to
|
||||
transfer information between a DSA and Domain Nameserver. When
|
||||
writing to the DSA, attributes in an entry which are not DNS
|
||||
records should remain untouched.
|
||||
|
||||
4. Linkage patching tool. When the organisational DIT is
|
||||
established, associated domain pointers are usually inserted. A
|
||||
tool can be written to search the DIT and insert the reverse
|
||||
pointers.
|
||||
|
||||
5. DNS Manager Tool. This will allow user addition of additional
|
||||
information into the DNS part of the DIT. A standard DUA can
|
||||
probably be used for this.
|
||||
|
||||
|
||||
|
||||
Hardcastle-Kille Page 14
|
||||
|
||||
|
||||
|
||||
|
||||
RFC 1279 X.500 and Domains November 1991
|
||||
|
||||
|
||||
6. Mailbox download tool. This will allow download of local
|
||||
mailboxes, with pointers to the user entries.
|
||||
|
||||
7. Emulation DNS Server, using the Directory as a database. The
|
||||
server should maintain a permanent connection to its local DSA. As
|
||||
there is no OSI bind, the response of this server can be at least
|
||||
as fast as a normal DNS server. There can be two variants of this
|
||||
server.
|
||||
|
||||
(a) Using a local DSA as a local database but using DNS
|
||||
distributed operations.
|
||||
|
||||
(b) Do all lookups in the directory (using Directory Distributed
|
||||
Operations).
|
||||
|
||||
An initial experiment is straightforward. The Zone Transfer Tool (3)
|
||||
can be used to download a large part of the DNS space into a single
|
||||
DSA (there will be some restrictions, as parts of the DNS hierarchy do
|
||||
not permit zone transfer). This can be used repeatedly to maintain
|
||||
the information. The linkage patching tool (4) can be used to put in
|
||||
pointers to parts of the DIT. The user tool can then be used (by all
|
||||
sites participation the the directory pilot) to look up domain
|
||||
information. This will allow the utility of the approach to be
|
||||
evaluated. The manager tool (5) will allow extra information to be
|
||||
added to parts of the DNS tree.
|
||||
|
||||
The next stage will be to distribute the DNS part of the DIT over
|
||||
multiple DSAs using Directory distribution techniques.
|
||||
The emulation DNS Server (7) will be useful to ensure that equivalent
|
||||
functionality is being offered by the Directory. It can also be used
|
||||
to examine performance differences.
|
||||
A final step is to master some parts of the DNS hierarchy in the DIT.
|
||||
Because of the zone transfer technique, this will be entirely
|
||||
transparent to the DNS user. Management benefits can then be
|
||||
examined.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardcastle-Kille Page 15
|
||||
|
||||
227
doc/rfc/rfc1308.txt
Normal file
227
doc/rfc/rfc1308.txt
Normal file
@ -0,0 +1,227 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group C. Weider
|
||||
Request for Comments: 1308 ANS
|
||||
FYI: 13 J. Reynolds
|
||||
ISI
|
||||
March 1992
|
||||
|
||||
|
||||
Executive Introduction to Directory Services
|
||||
Using the X.500 Protocol
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. It does
|
||||
not specify an Internet standard. Distribution of this memo is
|
||||
unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This document is an Executive Introduction to Directory Services
|
||||
using the X.500 protocol. It briefly discusses the deficiencies in
|
||||
currently deployed Internet Directory Services, and then illustrates
|
||||
the solutions provided by X.500.
|
||||
|
||||
This FYI RFC is a product of the Directory Information Services
|
||||
(pilot) Infrastructure Working Group (DISI). A combined effort of
|
||||
the User Services and the OSI Integration Areas of the Internet
|
||||
Engineering Task Force (IETF).
|
||||
|
||||
1. INTRODUCTION
|
||||
|
||||
The Internet is growing at a phenomenal rate, with no deceleration in
|
||||
sight. Every month thousands of new users are added. New networks
|
||||
are added literally almost every day. In fact, it is entirely
|
||||
conceivable that in the future every human with access to a computer
|
||||
will be able to interact with every other over the Internet and her
|
||||
sister networks. However, the ability to interact with everyone is
|
||||
only useful if one can locate the people with whom they need to work.
|
||||
Thus, as the Internet grows, one of the limitations imposed on the
|
||||
effective use of the network will be determined by the quality and
|
||||
coverage of Directory Services available.
|
||||
|
||||
Directory Services in this paper refers not only to the types of
|
||||
services provided by the telephone companies' White Pages, but to
|
||||
resource location, Yellow Pages services, mail address lookup, etc.
|
||||
We will take a brief look at the services available today, and at the
|
||||
problems they have, and then we will show how the X.500 standard
|
||||
solves those problems.
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 1]
|
||||
|
||||
RFC 1308 Executive Intro to X.500 March 1992
|
||||
|
||||
|
||||
2. CURRENT SERVICES AND THEIR LIMITATIONS
|
||||
|
||||
In the interests of brevity, we will only look at the WHOIS service,
|
||||
and at the DNS. Each will illustrate a particular philosophy, if you
|
||||
will, of Directory Services.
|
||||
|
||||
The WHOIS service is maintained by the Defense Data Network Network
|
||||
Information Center, or DDN NIC. It is currently maintained at GSI
|
||||
for the IP portion of the Internet. It contains information about IP
|
||||
networks, IP network managers, a scattering of well-known personages
|
||||
in the Internet, and a large amount of information related
|
||||
specifically to the MILNET systems. As the NIC is responsible for
|
||||
assigning new networks out of the pool of IP addresses, it is very
|
||||
easily able to collect this information when a new network is
|
||||
registered. However, the WHOIS database is big enough and
|
||||
comprehensive enough to exhibit many of the flaws of a large
|
||||
centralized database. First, centralized location of the WHOIS
|
||||
database causes slow response during times of peak querying activity,
|
||||
storage limitations, and also causes the entire service to be
|
||||
unavailable if the link to GSI is broken. Second, centralized
|
||||
administration of the database, where any changes to the database
|
||||
have to be mailed off to GSI for human transcription into the
|
||||
database, increases the turnaround time before the changes are
|
||||
propagated, and also introduces another source of potential error in
|
||||
the accuracy of the information. These particular problems affect to
|
||||
different degrees any system which attempts to provide Directory
|
||||
Services through a centralized database.
|
||||
|
||||
The Domain Name Service, or DNS, contains information about the
|
||||
mapping of host and domain names, such as, "home.ans.net", to IP
|
||||
addresses. This is done so that humans can use easily remembered
|
||||
names for machines rather than strings of numbers. It is maintained
|
||||
in a distributed fashion, with each DNS server providing nameservice
|
||||
for a limited number of domains. Also, secondary nameservers can be
|
||||
identified for each domain, so that one unreachable network will not
|
||||
necessarily cut off nameservice. However, even though the DNS is
|
||||
superlative at providing these services, there are some problems when
|
||||
we attempt to provide other Directory Services in the DNS. First, the
|
||||
DNS has very limited search capabilities. Second, the DNS supports
|
||||
only a small number of data types. Adding new data types, such as
|
||||
photographs, would involve very extensive implementation changes.
|
||||
|
||||
3. THE X.500 SOLUTION
|
||||
|
||||
X.500 is a CCITT protocol which is designed to build a distributed,
|
||||
global directory. It offers the following features:
|
||||
|
||||
* Decentralized Maintenance:
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 2]
|
||||
|
||||
RFC 1308 Executive Intro to X.500 March 1992
|
||||
|
||||
|
||||
Each site running X.500 is responsible ONLY for its local part of
|
||||
the Directory, so updates and maintenance can be done instantly.
|
||||
|
||||
* Powerful Searching Capabilities:
|
||||
X.500 provides powerful searching facilities that allow users to
|
||||
construct arbitrarily complex queries.
|
||||
|
||||
* Single Global Namespace:
|
||||
Much like the DNS, X.500 provides a single homogeneous namespace
|
||||
to users. The X.500 namespace is more flexible and expandable
|
||||
than the DNS.
|
||||
|
||||
* Structured Information Framework:
|
||||
X.500 defines the information framework used in the Directory,
|
||||
allowing local extensions.
|
||||
|
||||
* Standards-Based Directory Services:
|
||||
As X.500 can be used to build a standards-based directory,
|
||||
applications which require directory information (e-mail,
|
||||
automated resources locators, special-purpose directory tools)
|
||||
can access a planet's worth of information in a uniform manner,
|
||||
no matter where they are based or currently running.
|
||||
|
||||
With these features alone, X.500 is being used today to provide the
|
||||
backbone of a global White Pages service. There is almost 3 years of
|
||||
operational experience with X.500, and it is being used widely in
|
||||
Europe and Australia in addition to North America. In addition, the
|
||||
various X.500 implementations add some other features, such as
|
||||
photographs in G3-FAX format, and color photos in JPEG format.
|
||||
However, as X.500 is standards based, there are very few
|
||||
incompatibilities between the various versions of X.500, and as the
|
||||
namespace is consistent, the information in the Directory can be
|
||||
accessed by any implementation. Also, work is being done in providing
|
||||
Yellow Pages services and other information resource location tasks
|
||||
in the Directory.
|
||||
|
||||
However, there are some limitations to the X.500 technology as it is
|
||||
currently implemented. One price that is paid for the flexibility in
|
||||
searching is a decline in the speed of the searching. This is because
|
||||
a) searches over a part of the distributed namespace may have to
|
||||
traverse the network, and some implementations cache all the
|
||||
responses before giving them to the user, and b) some early
|
||||
implementations performed search slowly anyway. A second problem with
|
||||
the implementations is that for security reasons only a limited
|
||||
amount of information is returned to the user; for example, if a
|
||||
search turns up 1000 hits, only 20 or so are returned to the user.
|
||||
Although this number is tunable, it does mean that someone with a big
|
||||
search will have to do a lot of work. The performance of the
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 3]
|
||||
|
||||
RFC 1308 Executive Intro to X.500 March 1992
|
||||
|
||||
|
||||
Directory, while increasing rapidly in the last two years, is still
|
||||
not able to provide real-time directory services for such things as
|
||||
routing protocols. However, work is being done to speed up service.
|
||||
|
||||
The X.500 Directory is taking us closer to the day when we will
|
||||
indeed have the entire world on our desktops, and X.500 will help
|
||||
insure that we can find whom and what we need.
|
||||
|
||||
4: FOR FURTHER INFORMATION
|
||||
|
||||
For a more detailed technical introduction to X.500 and an extensive
|
||||
bibliography, see "Technical Overview of Directory Services Using the
|
||||
X.500 Protocol", by Weider, Reynolds, and Heker. This is available
|
||||
from the NIC as FYI 14, RFC 1309. For a catalogue of X.500
|
||||
implementations, see "A Catalog of Available X.500 Implementations",
|
||||
ed. Lang and Wright. This is available from the NIC as FYI 11, RFC
|
||||
1292.
|
||||
|
||||
5: SECURITY CONSIDERATIONS
|
||||
|
||||
Security issues are not discussed in this paper.
|
||||
|
||||
6: AUTHORS' ADDRESSES
|
||||
|
||||
Chris Weider
|
||||
Advanced Network and Services, Inc.
|
||||
2901 Hubbard, G-1
|
||||
Ann Arbor, MI 48105-2437
|
||||
|
||||
Phone (313) 663-2482
|
||||
E-mail: weider@ans.net
|
||||
|
||||
Joyce K. Reynolds
|
||||
Information Sciences Institute
|
||||
University of Southern California
|
||||
4676 Admirality Way
|
||||
Marina del Rey, CA 90292
|
||||
|
||||
Phone: (310) 822-1511
|
||||
E-Mail: jkrey@isi.edu
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 4]
|
||||
|
||||
899
doc/rfc/rfc1309.txt
Normal file
899
doc/rfc/rfc1309.txt
Normal file
@ -0,0 +1,899 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group C. Weider
|
||||
Request for Comments: 1309 ANS
|
||||
FYI: 14 J. Reynolds
|
||||
ISI
|
||||
S. Heker
|
||||
JvNC
|
||||
March 1992
|
||||
|
||||
|
||||
Technical Overview of Directory Services
|
||||
Using the X.500 Protocol
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. It does
|
||||
not specify an Internet standard. Distribution of this memo is
|
||||
unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This document is an overview of the X.500 standard for people not
|
||||
familiar with the technology. It compares and contrasts Directory
|
||||
Services based on X.500 with several of the other Directory services
|
||||
currently in use in the Internet. This paper also describes the
|
||||
status of the standard and provides references for further
|
||||
information on X.500 implementations and technical information.
|
||||
|
||||
A primary purpose of this paper is to illustrate the vast
|
||||
functionality of the X.500 protocol and to show how it can be used to
|
||||
provide a global directory for human use, and can support other
|
||||
applications which would benefit from directory services, such as
|
||||
main programs.
|
||||
|
||||
This FYI RFC is a product of the Directory Information Services
|
||||
(pilot) Infrastructure Working Group (DISI). A combined effort of
|
||||
the User Services and the OSI Integration Areas of the Internet
|
||||
Engineering Task Force (IETF).
|
||||
|
||||
1. INTRODUCTION
|
||||
|
||||
As the pace of industry, science, and technological development
|
||||
quickened over the past century, it became increasingly probable that
|
||||
someone in a geographically distant location would be trying to solve
|
||||
the same problems you were trying to solve, or that someone in a
|
||||
geographically distant location would have some vital information
|
||||
which impinged on your research or business. The stupendous growth
|
||||
in the telecommunications industry, from telegraphs to telephones to
|
||||
computer networks, has alleviated the problem of being able to
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 1]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
communicate with another person, PROVIDED THAT YOU KNOW HOW TO REACH
|
||||
THEM.
|
||||
|
||||
Thus, along with the expansion of the telecommunications
|
||||
infrastructure came the development of Directory Services. In this
|
||||
paper, we will discuss various models of directory services, the
|
||||
limitations of current models, and some solutions provided by the
|
||||
X.500 standard to these limitations.
|
||||
|
||||
2 MODELS OF DIRECTORY SERVICES
|
||||
|
||||
2.1 The telephone company's directory services.
|
||||
|
||||
A model many people think of when they hear the words "Directory
|
||||
Services" is the directory service provided by the local telephone
|
||||
company. A local telephone company keeps an on-line list of the names
|
||||
of people with phone service, along with their phone numbers and
|
||||
their address. This information is available by calling up Directory
|
||||
Assistance, giving the name and address of the party whose number you
|
||||
are seeking, and waiting for the operator to search his database. It
|
||||
is additionally available by looking in a phone book published yearly
|
||||
on paper.
|
||||
|
||||
The phone companies are able to offer this invaluable service because
|
||||
they administer the pool of phone numbers. However, this service has
|
||||
some limitations. For instance, you can find someone's number only if
|
||||
you know their name and the city or location in which they live. If
|
||||
two or more people have listings for the same name in the same
|
||||
locality, there is no additional information which with to select the
|
||||
correct number. In addition, the printed phone book can have
|
||||
information which is as much as a year out of date, and the phone
|
||||
company's internal directory can be as much as two weeks out of date.
|
||||
A third problem is that one actually has to call Directory assistance
|
||||
in a given area code to get information for that area; one cannot
|
||||
call a single number consistently.
|
||||
|
||||
For businesses which advertise in the Yellow Pages, there is some
|
||||
additional information stored for each business; unfortunately, that
|
||||
information is unavailable through Directory Assistance and must be
|
||||
gleaned from the phone book.
|
||||
|
||||
2.2 Some currently available directory services on the Internet.
|
||||
|
||||
As the Internet is comprised of a vast conglomeration of different
|
||||
people, computers, and computer networks, with none of the hierarchy
|
||||
imposed by the phone system on the area codes and exchange prefixes,
|
||||
any directory service must be able to deal with the fact that the
|
||||
Internet is not structured; for example, the hosts foo.com and
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 2]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
v2.foo.com may be on opposite sides of the world, the .edu domain
|
||||
maps onto an enormous number of organizations, etc. Let's look at a
|
||||
few of the services currently available on the Internet for directory
|
||||
type services.
|
||||
|
||||
2.2.1 The finger protocol.
|
||||
|
||||
The finger protocol, which has been implemented for UNIX systems and
|
||||
a small number of other machines, allows one to "finger" a specific
|
||||
person or username to a host running the protocol. This is invoked by
|
||||
typing, for example, "finger clw@mazatzal.merit.edu". A certain set
|
||||
of information is returned, as this example from a UNIX system finger
|
||||
operation shows, although the output format is not specified by the
|
||||
protocol:
|
||||
|
||||
Login name: clw In real life: Chris Weider
|
||||
Directory: /usr/clw Shell: /bin/csh
|
||||
On since Jul 25 09:43:42 4 hours 52 minutes Idle Time
|
||||
Plan:
|
||||
Home: 971-5581
|
||||
|
||||
where the first three lines of information are taken from the UNIX
|
||||
operating systems information and the line(s) of information
|
||||
following the "Plan:" line are taken from a file named .plan which
|
||||
each user modifies. Limitations of the fingerd program include: a)
|
||||
One must already know which host to finger to find a specific person,
|
||||
b) since primarily UNIX machines run fingerd, people who reside on
|
||||
other types of operating systems are not locateable by this method,
|
||||
c) fingerd is often disabled on UNIX systems for security purposes,
|
||||
d) if one wishes to be found on more than one system, one must make
|
||||
sure that all the .plan files are consistent, and e) there is no way
|
||||
to search the .plan files on a given host to (for example) find
|
||||
everyone on mazatzal.merit.edu who works on X.500. Thus, fingerd has
|
||||
a limited usefulness as a piece of the Internet Directory.
|
||||
|
||||
2.2.2 whois
|
||||
|
||||
The whois utility, which is available on a wide of variety of
|
||||
systems, works by querying a centralized database maintained at the
|
||||
DDN NIC, which was for many years located at SRI International in
|
||||
Menlo Park, California, and is now located at GSI. This database
|
||||
contains a large amount of information which primarily deals with
|
||||
people and equipment which is used to build the Internet. SRI (and
|
||||
now GSI) has been able to collect the information in the WHOIS
|
||||
database as part of its role as the Network Information Center for
|
||||
the TCP/IP portion of the Internet.
|
||||
|
||||
The whois utility is ubiquitous, and has a very simple interface. A
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 3]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
typical whois query look like:
|
||||
|
||||
whois Reynolds
|
||||
|
||||
and returns information like:
|
||||
|
||||
Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL
|
||||
(702) 426-2604 (DSN) 830-2604
|
||||
Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL
|
||||
(908) 532-3817 (DSN) 992-3817
|
||||
Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL
|
||||
(DSN) 723-3358
|
||||
Reynolds, Joseph T. (JTR10) JREYNOLDS@PAXRV-NES.NAVY.MIL
|
||||
011-63-47-885-3194 (DSN) 885-3194
|
||||
Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU (213) 822-1511
|
||||
Reynolds, Keith (KR35) keithr@SCO.CO (408) 425-7222
|
||||
Reynolds, Kenneth (KR94) (502) 454-2950
|
||||
Reynolds, Kevin A. (KR39) REYNOLDS@DUGWAY-EMH1.ARMY.MIL
|
||||
(801) 831-5441 (DSN) 789-5441
|
||||
Reynolds, Lee B. (LBR9) reynolds@TECHNET.NM.ORG (505) 345-6555
|
||||
|
||||
a further lookup on Joyce Reynolds with this command line:
|
||||
|
||||
whois JKR1
|
||||
|
||||
returns:
|
||||
|
||||
Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU
|
||||
University of Southern California
|
||||
Information Sciences Institute
|
||||
4676 Admiralty Way
|
||||
Marina del Rey, CA 90292
|
||||
(310) 822-1511
|
||||
|
||||
Record last updated on 07-Jan-91.
|
||||
|
||||
The whois database also contains information about Domain Name System
|
||||
(DNS) and has some information about hosts, major regional networks,
|
||||
and large parts of the MILNET system.
|
||||
|
||||
The WHOIS database is large enough and comprehensive enough to
|
||||
exhibit many of the flaws of a large centralized database: a) As the
|
||||
database is maintained on one machine, a processor bottleneck forces
|
||||
slow response during times of peak querying activity, even if many of
|
||||
these queries are unrelated, b) as the database is maintained on one
|
||||
machine, a storage bottleneck forces the database administrators to
|
||||
severely limit the amount of information which can be kept on each
|
||||
entry in the database, c) all changes to the database have to be
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 4]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
mailed to a "hostmaster" and then physically reentered into the
|
||||
database, increasing both the turnaround time and the likelihood for
|
||||
a mistake in transcription.
|
||||
|
||||
2.2.3 The Domain Name System
|
||||
|
||||
The Domain Name System is used in the Internet to keep track of host
|
||||
to IP address mapping. The basic mechanism is that each domain, such
|
||||
as merit.edu or k-12.edu, is registered with the NIC, and at time of
|
||||
registration, a primary and (perhaps) some secondary nameservers are
|
||||
identified for that domain. Each of these nameservers must provide
|
||||
host name to IP address mapping for each host in the domain. Thus,
|
||||
the nameservice is supplied in a distributed fashion. It is also
|
||||
possible to split a domain into subdomains, with a different
|
||||
nameserver for each subdomain.
|
||||
|
||||
Although in many cases one uses the DNS without being aware of it,
|
||||
because humans prefer to remember names and not IP addresses, it is
|
||||
possible to interactively query the DNS with the nslookup utility. A
|
||||
sample session using the nslookup utility:
|
||||
|
||||
home.merit.edu(1): nslookup
|
||||
Default Server: merit.edu
|
||||
Address: 35.42.1.42
|
||||
|
||||
> scanf.merit.edu
|
||||
Server: merit.edu
|
||||
Address: 35.42.1.42
|
||||
|
||||
Name: scanf.merit.edu
|
||||
Address: 35.42.1.92
|
||||
|
||||
> 35.42.1.92
|
||||
Server: merit.edu
|
||||
Address: 35.42.1.42
|
||||
|
||||
Name: [35.42.1.92]
|
||||
Address: 35.42.1.92
|
||||
|
||||
Thus, we can explicitly determine the address associated with a given
|
||||
host. Reverse name mapping is also possible with the DNS, as in this
|
||||
example:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 5]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
home.merit.edu(2): traceroute ans.net
|
||||
traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte packets
|
||||
1 t3peer (35.1.1.33) 11 ms 5 ms 5 ms
|
||||
2 enss (35.1.1.1) 6 ms 6 ms 6 ms
|
||||
.................
|
||||
9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49 ms
|
||||
10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46 ms
|
||||
|
||||
At each hop of the traceroute, the program attempts to do a reverse
|
||||
lookup through the DNS and displays the results when successful.
|
||||
|
||||
Although the DNS has served superlatively for the purpose it was
|
||||
developed, i.e. to allow maintenance of the namespace in a
|
||||
distributed fashion, and to provide very rapid lookups in the
|
||||
namespace, there are, of course, some limitations. Although there has
|
||||
been some discussion of including other types of information in the
|
||||
DNS, to find a given person at this time, assuming you know where she
|
||||
works, you have to use a combination of the DNS and finger to even
|
||||
make a stab at finding her. Also, the DNS has very limited search
|
||||
capabilities right now. The lack of search capabilities alone shows
|
||||
that we cannot provide a rich Directory Service through the DNS.
|
||||
|
||||
3: THE X.500 MODEL OF DIRECTORY SERVICE
|
||||
|
||||
X.500 is a CCITT protocol which is designed to build a distributed,
|
||||
global directory. It offers the following features:
|
||||
|
||||
* Decentralized Maintenance:
|
||||
Each site running X.500 is responsible ONLY for its local part
|
||||
of the Directory, so updates and maintenance can be done instantly.
|
||||
|
||||
* Powerful Searching Capabilities:
|
||||
X.500 provides powerful searching facilities that allow users to
|
||||
construct arbitrarily complex queries.
|
||||
|
||||
* Single Global Namespace:
|
||||
Much like the DNS, X.500 provides a single homogeneous namespace
|
||||
to users. The X.500 namespace is more flexible and expandable
|
||||
than the DNS.
|
||||
|
||||
* Structured Information Framework:
|
||||
X.500 defines the information framework used in the directory,
|
||||
allowing local extensions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 6]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
* Standards-Based Directory:
|
||||
As X.500 can be used to build a standards-based directory,
|
||||
applications which require directory information (e-mail,
|
||||
automated resource locators, special-purpose directory tools)
|
||||
can access a planet's worth of information in a uniform manner,
|
||||
no matter where they are based or currently running.
|
||||
|
||||
3.1 Acronym City, or How X.500 Works
|
||||
|
||||
The '88 version of the X.500 standard talks about 3 models required
|
||||
to build the X.500 Directory Service: the Directory Model, the
|
||||
Information Model, and the Security Model. In this section, we will
|
||||
provide a brief overview of the Directory and Information Models
|
||||
sufficient to explain the vast functionality of X.500.
|
||||
|
||||
3.1.1 The Information Model
|
||||
|
||||
To illustrate the Information Model, we will first show how
|
||||
information is held in the Directory, then we will show what types of
|
||||
information can be held in the Directory, and then we will see how
|
||||
the information is arranged so that we can retrieve the desired
|
||||
pieces from the Directory.
|
||||
|
||||
3.1.1.1 Entries
|
||||
|
||||
The primary construct holding information in the Directory is the
|
||||
"entry". Each Directory entry contains information about one object;
|
||||
for example, a person, a computer network, or an organization. Each
|
||||
entry is built from a collection of "attributes", each of which holds
|
||||
a single piece of information about the object. Some attributes which
|
||||
might be used to build an entry for a person would be "surname",
|
||||
"telephonenumber", "postaladdress", etc. Each attribute has an
|
||||
associated "attribute syntax", which describes the type of data that
|
||||
attribute contains, for example, photo data, a time code, or a string
|
||||
of letters and numbers. As an example, let's look at part of an entry
|
||||
for a person.
|
||||
|
||||
Entry for John Smith contains:
|
||||
|
||||
attribute ---> surName= Smith <--- attribute value
|
||||
|---> telephoneNumber= 999-9999 <--- attribute value
|
||||
|---> title= Janitor <--- attribute value
|
||||
...
|
||||
|
||||
The attribute syntax for the surName attribute would be
|
||||
CaseIgnoreString, which would tell X.500 that surName could contain
|
||||
any string, and case would not matter; the attribute syntax for the
|
||||
telephoneNumber attribute would be TelephoneNumber, which would
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 7]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
specify that telephoneNumber could contain a string composed of
|
||||
digits, dashes, parenthesis, and a plus sign. The attribute syntax
|
||||
for the title attribute would also be CaseIgnoreString. A good
|
||||
analogy in database terms for what we've seen so far might be to
|
||||
think of a Directory entry as a database record, an attribute as a
|
||||
field in that record, and an attribute syntax as a field type
|
||||
(decimal number, string) for a field in a record.
|
||||
|
||||
3.1.1.2 Object Classes
|
||||
|
||||
At this point in our description of the information model, we have no
|
||||
way of knowing what type of object a given entry represents. X.500
|
||||
uses the concept of an "object class" to specify that information,
|
||||
and an attribute named "objectClass" which each entry contains to
|
||||
specify to which object class(es) the entry belongs.
|
||||
|
||||
Each object class in X.500 has a definition which lists the set of
|
||||
mandatory attributes, which must be present, and a set of optional
|
||||
attributes, which may be present, in an entry of that class. An given
|
||||
object class A may be a subclass of another class B, in which case
|
||||
object class A inherits all the mandatory and optional attributes of
|
||||
B in addition to its own.
|
||||
|
||||
The object classes in X.500 are arranged in a hierarchical manner
|
||||
according to class inheritance; the following diagram shows a part of
|
||||
the object class hierarchy.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 8]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
_____________
|
||||
| | "top" has one mandatory
|
||||
| top | attribute "objectClass",
|
||||
|_____________| and nooptional attributes.
|
||||
| | |
|
||||
| | | every other object class is a
|
||||
________________| | | subclass of "top"...
|
||||
| | ...
|
||||
______|________ _____|_______
|
||||
| | | |"organization" inherits one
|
||||
| country | | organization |mandatory attribute from
|
||||
|_______________| |_______________|"top", "objectClass"; adds one
|
||||
more mandatory attribute "O"
|
||||
"country" inherits one (for organization), and has
|
||||
mandatory attribute from "top", many optional attributes. Any
|
||||
"objectClass", adds one more subclass of "organization"
|
||||
mandatory attribute "c" (for would inherit all of the
|
||||
country), and has two optional mandatory and optional
|
||||
attributes, "description" and attributes from "organization"
|
||||
"searchGuide". Any subclass of including the attribute which
|
||||
"country" would inherit all of the "organization" inherited
|
||||
mandatory and optional attributes from "top".
|
||||
of the "country" class, including
|
||||
the attribute which "country"
|
||||
inherited from "top".
|
||||
|
||||
Figure 1.
|
||||
|
||||
One major benefit of the object class concept is that it is in many
|
||||
cases very easy to create a new object class which is only a slight
|
||||
modification or extension of a previous class. For example, if I have
|
||||
already defined an object class for "person" which contains a
|
||||
person's name, phone number, address, and fax number, I can easily
|
||||
define an "Internet person" object class by defining "Internet
|
||||
person" as a subclass of "person", with the additional optional
|
||||
attribute of "e-mail address". Thus in my definition of the "Internet
|
||||
Person" object class, all my "person" type attributes are inherited
|
||||
from "person". There are other benefits which are beyond the scope of
|
||||
this paper.
|
||||
|
||||
3.1.1.3 X.500's namespace.
|
||||
|
||||
X.500 hierarchically organizes the namespace in the Directory
|
||||
Information Base (DIB); recall that this hierarchical organization is
|
||||
called the Directory Information Tree (DIT). Each entry in the DIB
|
||||
occupies a certain location in the DIT. An entry which has no
|
||||
children is called a leaf entry, an entry which has children is
|
||||
called a non-leaf node. Each entry in the DIT contains one or more
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 9]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
attributes which together comprise the Relative Distinguished Name
|
||||
(RDN) of that entry, there is a "root" entry (which has no
|
||||
attributes, a special case) which forms the base node of the DIT. The
|
||||
Distinguished Name of a specific entry is the sequence of RDNs of the
|
||||
entries on the path from the root entry to the entry in question. A
|
||||
diagram here will help to clarify this:
|
||||
|
||||
Level of DIT Root RDN Distinguished Name
|
||||
|
||||
root * nothing { }
|
||||
/ | \
|
||||
country (other / | \
|
||||
things at this / | \ c=us {c=us}
|
||||
level) c=gb c=us c=ca
|
||||
/ | \
|
||||
/ | \
|
||||
/ | \
|
||||
organization o=SRI o=Merit o=DEC o=Merit {c=us, o=Merit}
|
||||
(other things / | \
|
||||
at this level) / | \
|
||||
/ | \
|
||||
Third level cn=Chris Weider cn=Chris Weider {c=us, o=Merit,
|
||||
cn=Chris Weider}
|
||||
|
||||
Figure 2: Building a DN from RDNs (adapted from a
|
||||
diagram in the X.500 (88) Blue Book)
|
||||
|
||||
Each entry in this tree contains more attributes than have been shown
|
||||
here, but in each case only one attribute for each entry has been
|
||||
used for that entry's RDN. As noted above, any entry in the tree
|
||||
could use more than one attribute to build its RDN. X.500 also allows
|
||||
the use of alias names, so that the entry {c=us, o=Merit, cn=Chris
|
||||
Weider} could be also found through an alias entry such as {c=us,
|
||||
o=SRI, ou=FOX Project, cn=Drone 1} which would point to the first
|
||||
entry.
|
||||
|
||||
3.1.2 The Directory Model
|
||||
|
||||
Now that we've seen what kinds of information can be kept in the
|
||||
Directory, we should look at how the Directory stores this
|
||||
information and how a Directory users accesses the information. There
|
||||
are two components of this model: a Directory User Agent (DUA), which
|
||||
accesses the Directory on behalf of a user, and the Directory System
|
||||
Agent, which can be viewed as holding a particular subset of the DIB,
|
||||
and can also provide an access point to the Directory for a DUA.
|
||||
|
||||
Now, the entire DIB is distributed through the world-wide collection
|
||||
of DSAs which form the Directory, and the DSAs employ two techniques
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 10]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
to allow this distribution to be transparent to the user, called
|
||||
"chaining" and "referral". The details of these two techniques would
|
||||
take up another page, so it suffices to say that to each user, it
|
||||
appears that the entire global directory is on her desktop. (Of
|
||||
course, if the information requested is on the other side of the
|
||||
world, it may seem that the desktop directory is a bit slow for that
|
||||
request...)
|
||||
|
||||
3.2 The functionality of X.500
|
||||
|
||||
To describe the functionality of X.500, we will need to separate
|
||||
three stages in the evolution of X.500: 1) the 1988 standard, 2)
|
||||
X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard.
|
||||
We will list some of the features described in the 1988 standard,
|
||||
show how they were implemented in QUIPU, and discuss where the 1992
|
||||
standard will take us. The QUIPU implementation was chosen because
|
||||
a) it is widely used in the U.S. and European Directory Services
|
||||
Pilot projects, and b) it works well. For a survey of other X.500
|
||||
implementations and a catalogue of DUAs, see [Lang].
|
||||
|
||||
3.2.1 Functionality in X.500 (88)
|
||||
|
||||
There are a number of advantages that the X.500 Directory accrues
|
||||
simply by virtue of the fact that it is distributed, not limited to a
|
||||
single machine. Among these are:
|
||||
|
||||
* An enormously large potential namespace.
|
||||
Since the Directory is not limited to a single machine, many
|
||||
hundreds of machines can be used to store Directory entries.
|
||||
|
||||
* The ability to allow local administration of local data.
|
||||
An organization or group can run a local DSA to master their
|
||||
information, facilitating much more accurate data throughout
|
||||
the Directory.
|
||||
|
||||
The functionality built into the X.500(88) standard includes:
|
||||
|
||||
* Advanced searching capabilities.
|
||||
The Directory supports arbitrarily complex searches at an
|
||||
attribute level. As the object classes a specific entry
|
||||
belongs to is maintained in the objectClass attribute, this
|
||||
also allows Directory searches for specific types of objects.
|
||||
Thus, one could search the c=US subtree for anyone with a last
|
||||
name beginning with S, who also has either a fax number in the
|
||||
(313) area code or an e-mail address ending in umich.edu.
|
||||
This feature of X.500 also helps to provide the basic
|
||||
functionality for a Yellow Pages service.
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 11]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
* A uniform namespace with local extensibility.
|
||||
The Directory provides a uniform namespace, but local
|
||||
specialized directories can also be implemented. Locally
|
||||
defined extensions can include new object classes, new
|
||||
attributes, and new attribute types.
|
||||
|
||||
* Security issues.
|
||||
The X.500 (88) standards define two types of security for
|
||||
Directory data: Simple Authentication (which uses passwords),
|
||||
and Strong Authentication (which uses cryptographic keys).
|
||||
Simple authentication has been widely implemented, strong
|
||||
authentication has been less widely implemented. Each of
|
||||
these authentication techniques are invoked when a user or
|
||||
process attempts a Directory operation through a DUA.
|
||||
|
||||
In addition to the global benefits of the X.500 standard, there are
|
||||
many local benefits. One can use their local DSA for company or
|
||||
campus wide directory services; for example, the University of
|
||||
Michigan is providing all the campus directory services through
|
||||
X.500. The DUAs are available for a wide range of platforms,
|
||||
including X-Windows systems and Macintoshes.
|
||||
|
||||
3.2.2 Functionality added by QUIPU.
|
||||
|
||||
Functionality beyond the X.500 (88) standard implemented by QUIPU
|
||||
includes:
|
||||
|
||||
* Access control lists.
|
||||
An access control list is a way to provide security for each
|
||||
attribute of an entry. For example, each attribute in a given
|
||||
entry can be permitted for detect, compare, read, and modify
|
||||
permissions based on the reader's membership in various groups.
|
||||
For example, one can specify that some information in a given
|
||||
entry is public, some can be read only by members of the
|
||||
organization, and some can only be modified by the owner of
|
||||
the entry.
|
||||
|
||||
* Replication.
|
||||
Replication provides a method whereby frequently accessed
|
||||
information in a DSA other than the local one can be kept by
|
||||
the local DSA on a "slave" basis, with updates of the "slave"
|
||||
data provided automatically by QUIPU from the "master" data
|
||||
residing on the foreign DSA. This provides alternate access
|
||||
points to that data, and can make searches and retrievals
|
||||
more rapid as there is much less overhead in the form or
|
||||
network transport.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 12]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
3.3 Current limitations of the X.500 standard and implementations.
|
||||
|
||||
As flexible and forward looking as X.500 is, it certainly was not
|
||||
designed to solve everyone's needs for all time to come. X.500 is not
|
||||
a general purpose database, nor is it a Data Base Management System
|
||||
(DBMS). X.500 defines no standards for output formats, and it
|
||||
certainly doesn't have a report generation capability. The technical
|
||||
mechanisms are not yet in place for the Directory to contain
|
||||
information about itself, thus new attributes and new attribute types
|
||||
are rather slowly distributed (by hand).
|
||||
|
||||
Searches can be slow, for two reasons: a) searches across a widely
|
||||
distributed portion of the namespace (c=US, for example) has a delay
|
||||
which is partially caused by network transmission times, and can be
|
||||
compounded by implementations that cache the partial search returns
|
||||
until everyone has reported back, and b) some implementations are
|
||||
slow at searching anyway, and this is very sensitive to such things
|
||||
as processor speed and available swap space. Another implementation
|
||||
"problem" is a tradeoff with security for the Directory: most
|
||||
implementations have an administrative limit on the amount of
|
||||
information which can be returned for a specific search. For
|
||||
example, if a search returns 1000 hits, 20 of those might be
|
||||
displayed, with the rest lost. Thus a person performing a large
|
||||
search might have to perform a number of small searches. This was
|
||||
implemented because an organization might want to make it hard to
|
||||
"troll" for the organization's entire database.
|
||||
|
||||
Also, there is at the moment no clear consensus on the ideal shape of
|
||||
the DIT, or on the idea structure of the object tree. This can make
|
||||
it hard to add to the current corpus of X.500 work, and the number of
|
||||
RFCs on various aspects of the X.500 deployment is growing monthly.
|
||||
|
||||
Despite this, however, X.500 is very good at what it was designed to
|
||||
do; i.e., to provide primary directory services and "resource
|
||||
location" for a wide band oftypes of information.
|
||||
|
||||
3.4 Things to be added in X.500 (92).
|
||||
|
||||
The 1988 version of the X.500 standard proved to be quite sufficient
|
||||
to start building a Directory Service. However, many of the new
|
||||
functions implemented in QUIPU were necessary if the Directory were
|
||||
to function in a reasonable manner. X.500 (92) will include
|
||||
formalized and standardized versions of those advances, including
|
||||
|
||||
* A formalized replication procedure.
|
||||
|
||||
* Enhanced searching capacities.
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 13]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
* Formalization of access control mechanisms, including access
|
||||
control lists.
|
||||
|
||||
Each of these will provide a richer Directory, but you don't have to
|
||||
wait for them! You can become part of the Directory today!
|
||||
|
||||
4: WHAT X.500 CAN DO FOR YOU TODAY
|
||||
|
||||
4.1 Current applications of X.500
|
||||
|
||||
X.500 is filling Directory Services needs in a large number of
|
||||
countries. As a directory to locate people, it is provided in the
|
||||
U.S. as the White Pages Pilot Project, run by PSI, and in Europe
|
||||
under the PARADISE Project as a series of nation-wide pilots. It is
|
||||
also being used by the FOX Project in the United States to provide
|
||||
WHOIS services for people and networks, and to provide directories of
|
||||
objects as disparate as NIC Profiles and a pilot K-12 Educators
|
||||
directory. It is also being investigated for its ability to provide
|
||||
resource location facilities and to provide source location for WAIS
|
||||
servers. In fact, in almost every area where one could imagine
|
||||
needing a directory service (particularly for distributed directory
|
||||
services), X.500 is either providing those services or being expanded
|
||||
to provide those services.
|
||||
|
||||
In particular, X.500 was envisioned by its creators as providing
|
||||
directory services for electronic mail, specifically for X.400. It is
|
||||
being used in this fashion today at the University of Michigan:
|
||||
everyone at the University has a unified mail address, e.g.
|
||||
Chris.Weider@umich.edu. An X.500 server then reroutes that mail to
|
||||
the appropriate user's real mail address in a transparent fashion.
|
||||
Similarly, Sprint is using X.500 to administrate the address space
|
||||
for its internal X.400 mail systems.
|
||||
|
||||
Those of us working on X.500 feel that X.500's strengths lie in
|
||||
providing directory services for people and objects, and for
|
||||
providing primary resource location for a large number of online
|
||||
services. We think that X.500 is a major component (though not the
|
||||
only one) of a global Yellow Pages service. We would also like to
|
||||
encourage each of you to join your national pilot projects; the more
|
||||
coverage we can get, the easier you will be able to find the people
|
||||
you need to contact.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 14]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
5. For Further Information
|
||||
|
||||
For further information, the authors recommend the following
|
||||
documents:
|
||||
|
||||
Weider, C., and J. Reynolds, "Executive Introduction to Directory
|
||||
Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI,
|
||||
March 1992.
|
||||
|
||||
Lang, R., and R. Wright, Editors, "A Catalog of Available X.500
|
||||
Implementations", FYI 11, RFC 1292, SRI International, Lawrence
|
||||
Berkeley Laboratory, January 1992.
|
||||
|
||||
Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
|
||||
X.500 Schema", RFC 1274, University College London, November 1991.
|
||||
|
||||
Hardcastle-Kille, S., "Replication Requirements to provide an
|
||||
Internet Directory using X.500", RFC 1275, University College
|
||||
London, November, 1991.
|
||||
|
||||
Hardcastle-Kille, S., "Replication and Distributed Operations
|
||||
extensions to provide an Internet Directory using X.500", RFC
|
||||
1276, University College London, November 1991.
|
||||
|
||||
Hardcastle-Kille, S., "Encoding Network Addresses to support
|
||||
operation over non-OSI lower layers", RFC 1277, University College
|
||||
London, November 1991.
|
||||
|
||||
Hardcastle-Kille, S., " A string encoding of Presentation
|
||||
Address", RFC 1278, University College London, November 1991.
|
||||
|
||||
Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University
|
||||
College London, November 1991.
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
Security issues are discussed in section 3.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 15]
|
||||
|
||||
RFC 1309 Technical Overview of X.500 March 1992
|
||||
|
||||
|
||||
7. Authors' Addresses
|
||||
|
||||
Chris Weider
|
||||
Advanced Network and Services, Inc.
|
||||
2901 Hubbard G-1
|
||||
Ann Arbor, MI 48105-2437
|
||||
|
||||
Phone (313) 663-2482
|
||||
E-mail: weider@ans.net
|
||||
|
||||
|
||||
Joyce K. Reynolds
|
||||
Information Sciences Institute
|
||||
University of Southern California
|
||||
4676 Admirality Way
|
||||
Marina del Rey, CA 90292
|
||||
|
||||
Phone: (310) 822-1511
|
||||
EMail: jkrey@isi.edu
|
||||
|
||||
|
||||
Sergio Heker
|
||||
JvNCnet
|
||||
Princeton University
|
||||
6 von Neumann Hall
|
||||
Princeton, NJ 08544
|
||||
|
||||
Phone: (609) 258-2400
|
||||
Email: heker@nisc.jvnc.net
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DISI Working Group [Page 16]
|
||||
|
||||
1123
doc/rfc/rfc1430.txt
Normal file
1123
doc/rfc/rfc1430.txt
Normal file
File diff suppressed because it is too large
Load Diff
1571
doc/rfc/rfc1617.txt
Normal file
1571
doc/rfc/rfc1617.txt
Normal file
File diff suppressed because it is too large
Load Diff
1459
doc/rfc/rfc1781.txt
Normal file
1459
doc/rfc/rfc1781.txt
Normal file
File diff suppressed because it is too large
Load Diff
171
doc/rfc/rfc1960.txt
Normal file
171
doc/rfc/rfc1960.txt
Normal file
@ -0,0 +1,171 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group T. Howes
|
||||
Request for Comments: 1960 University of Michigan
|
||||
Obsoletes: 1558 June 1996
|
||||
Category: Standards Track
|
||||
|
||||
A String Representation of LDAP Search Filters
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
1. Abstract
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) [1] defines a
|
||||
network representation of a search filter transmitted to an LDAP
|
||||
server. Some applications may find it useful to have a common way of
|
||||
representing these search filters in a human-readable form. This
|
||||
document defines a human-readable string format for representing LDAP
|
||||
search filters.
|
||||
|
||||
2. LDAP Search Filter Definition
|
||||
|
||||
An LDAP search filter is defined in [1] as follows:
|
||||
|
||||
Filter ::= CHOICE {
|
||||
and [0] SET OF Filter,
|
||||
or [1] SET OF Filter,
|
||||
not [2] Filter,
|
||||
equalityMatch [3] AttributeValueAssertion,
|
||||
substrings [4] SubstringFilter,
|
||||
greaterOrEqual [5] AttributeValueAssertion,
|
||||
lessOrEqual [6] AttributeValueAssertion,
|
||||
present [7] AttributeType,
|
||||
approxMatch [8] AttributeValueAssertion
|
||||
}
|
||||
|
||||
SubstringFilter ::= SEQUENCE {
|
||||
type AttributeType,
|
||||
SEQUENCE OF CHOICE {
|
||||
initial [0] LDAPString,
|
||||
any [1] LDAPString,
|
||||
final [2] LDAPString
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 1]
|
||||
|
||||
RFC 1960 LDAP Search Filters June 1996
|
||||
|
||||
|
||||
AttributeValueAssertion ::= SEQUENCE {
|
||||
attributeType AttributeType,
|
||||
attributeValue AttributeValue
|
||||
}
|
||||
|
||||
AttributeType ::= LDAPString
|
||||
|
||||
AttributeValue ::= OCTET STRING
|
||||
|
||||
LDAPString ::= OCTET STRING
|
||||
|
||||
where the LDAPString above is limited to the IA5 character set. The
|
||||
AttributeType is a string representation of the attribute type name
|
||||
and is defined in [1]. The AttributeValue OCTET STRING has the form
|
||||
defined in [2]. The Filter is encoded for transmission over a
|
||||
network using the Basic Encoding Rules defined in [3], with
|
||||
simplifications described in [1].
|
||||
|
||||
3. String Search Filter Definition
|
||||
|
||||
The string representation of an LDAP search filter is defined by the
|
||||
following grammar. It uses a prefix format.
|
||||
|
||||
<filter> ::= '(' <filtercomp> ')'
|
||||
<filtercomp> ::= <and> | <or> | <not> | <item>
|
||||
<and> ::= '&' <filterlist>
|
||||
<or> ::= '|' <filterlist>
|
||||
<not> ::= '!' <filter>
|
||||
<filterlist> ::= <filter> | <filter> <filterlist>
|
||||
<item> ::= <simple> | <present> | <substring>
|
||||
<simple> ::= <attr> <filtertype> <value>
|
||||
<filtertype> ::= <equal> | <approx> | <greater> | <less>
|
||||
<equal> ::= '='
|
||||
<approx> ::= '~='
|
||||
<greater> ::= '>='
|
||||
<less> ::= '<='
|
||||
<present> ::= <attr> '=*'
|
||||
<substring> ::= <attr> '=' <initial> <any> <final>
|
||||
<initial> ::= NULL | <value>
|
||||
<any> ::= '*' <starval>
|
||||
<starval> ::= NULL | <value> '*' <starval>
|
||||
<final> ::= NULL | <value>
|
||||
|
||||
<attr> is a string representing an AttributeType, and has the format
|
||||
defined in [1]. <value> is a string representing an AttributeValue,
|
||||
or part of one, and has the form defined in [2]. If a <value> must
|
||||
contain one of the characters '*' or '(' or ')', these characters
|
||||
should be escaped by preceding them with the backslash '\' character.
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 2]
|
||||
|
||||
RFC 1960 LDAP Search Filters June 1996
|
||||
|
||||
|
||||
Note that although both the <substring> and <present> productions can
|
||||
produce the 'attr=*' construct, this construct is used only to denote
|
||||
a presence filter.
|
||||
|
||||
4. Examples
|
||||
|
||||
This section gives a few examples of search filters written using
|
||||
this notation.
|
||||
|
||||
(cn=Babs Jensen)
|
||||
(!(cn=Tim Howes))
|
||||
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
|
||||
(o=univ*of*mich*)
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Security considerations are not discussed in this memo.
|
||||
|
||||
6. Bibliography
|
||||
|
||||
[1] Yeong, W., Howes, T., and S. Kille, "Lightweight
|
||||
Directory Access Protocol", RFC 1777, March 1995.
|
||||
|
||||
[2] Howes, R., Kille, S., Yeong, W., and C. Robbins, "The String
|
||||
Representation of Standard Attribute Syntaxes", RFC 1778,
|
||||
March 1995.
|
||||
|
||||
[3] Specification of Basic Encoding Rules for Abstract Syntax
|
||||
Notation One (ASN.1). CCITT Recommendation X.209, 1988.
|
||||
|
||||
7. Author's Address
|
||||
|
||||
Tim Howes
|
||||
University of Michigan
|
||||
ITD Research Systems
|
||||
535 W William St.
|
||||
Ann Arbor, MI 48103-4943
|
||||
USA
|
||||
|
||||
Phone: +1 313 747-4454
|
||||
EMail: tim@umich.edu
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 3]
|
||||
|
||||
339
doc/rfc/rfc2044.txt
Normal file
339
doc/rfc/rfc2044.txt
Normal file
@ -0,0 +1,339 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group F. Yergeau
|
||||
Request for Comments: 2044 Alis Technologies
|
||||
Category: Informational October 1996
|
||||
|
||||
|
||||
UTF-8, a transformation format of Unicode and ISO 10646
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. This memo
|
||||
does not specify an Internet standard of any kind. Distribution of
|
||||
this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly
|
||||
define a 16 bit character set which encompasses most of the world's
|
||||
writing systems. 16-bit characters, however, are not compatible with
|
||||
many current applications and protocols, and this has led to the
|
||||
development of a few so-called UCS transformation formats (UTF), each
|
||||
with different characteristics. UTF-8, the object of this memo, has
|
||||
the characteristic of preserving the full US-ASCII range: US-ASCII
|
||||
characters are encoded in one octet having the usual US-ASCII value,
|
||||
and any octet with such a value can only be an US-ASCII character.
|
||||
This provides compatibility with file systems, parsers and other
|
||||
software that rely on US-ASCII values but are transparent to other
|
||||
values.
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Unicode Standard, version 1.1 [UNICODE], and ISO/IEC 10646-1:1993
|
||||
[ISO-10646] jointly define a 16 bit character set, UCS-2, which
|
||||
encompasses most of the world's writing systems. ISO 10646 further
|
||||
defines a 31-bit character set, UCS-4, with currently no assignments
|
||||
outside of the region corresponding to UCS-2 (the Basic Multilingual
|
||||
Plane, BMP). The UCS-2 and UCS-4 encodings, however, are hard to use
|
||||
in many current applications and protocols that assume 8 or even 7
|
||||
bit characters. Even newer systems able to deal with 16 bit
|
||||
characters cannot process UCS-4 data. This situation has led to the
|
||||
development of so-called UCS transformation formats (UTF), each with
|
||||
different characteristics.
|
||||
|
||||
UTF-1 has only historical interest, having been removed from ISO
|
||||
10646. UTF-7 has the quality of encoding the full Unicode repertoire
|
||||
using only octets with the high-order bit clear (7 bit US-ASCII
|
||||
values, [US-ASCII]), and is thus deemed a mail-safe encoding
|
||||
([RFC1642]). UTF-8, the object of this memo, uses all bits of an
|
||||
octet, but has the quality of preserving the full US-ASCII range:
|
||||
|
||||
|
||||
|
||||
Yergeau Informational [Page 1]
|
||||
|
||||
RFC 2044 UTF-8 October 1996
|
||||
|
||||
|
||||
US-ASCII characters are encoded in one octet having the normal US-
|
||||
ASCII value, and any octet with such a value can only stand for an
|
||||
US-ASCII character, and nothing else.
|
||||
|
||||
UTF-16 is a scheme for transforming a subset of the UCS-4 repertoire
|
||||
into a pair of UCS-2 values from a reserved range. UTF-16 impacts
|
||||
UTF-8 in that UCS-2 values from the reserved range must be treated
|
||||
specially in the UTF-8 transformation.
|
||||
|
||||
UTF-8 encodes UCS-2 or UCS-4 characters as a varying number of
|
||||
octets, where the number of octets, and the value of each, depend on
|
||||
the integer value assigned to the character in ISO 10646. This
|
||||
transformation format has the following characteristics (all values
|
||||
are in hexadecimal):
|
||||
|
||||
- Character values from 0000 0000 to 0000 007F (US-ASCII repertoire)
|
||||
correspond to octets 00 to 7F (7 bit US-ASCII values).
|
||||
|
||||
- US-ASCII values do not appear otherwise in a UTF-8 encoded charac-
|
||||
ter stream. This provides compatibility with file systems or
|
||||
other software (e.g. the printf() function in C libraries) that
|
||||
parse based on US-ASCII values but are transparent to other val-
|
||||
ues.
|
||||
|
||||
- Round-trip conversion is easy between UTF-8 and either of UCS-4,
|
||||
UCS-2 or Unicode.
|
||||
|
||||
- The first octet of a multi-octet sequence indicates the number of
|
||||
octets in the sequence.
|
||||
|
||||
- Character boundaries are easily found from anywhere in an octet
|
||||
stream.
|
||||
|
||||
- The lexicographic sorting order of UCS-4 strings is preserved. Of
|
||||
course this is of limited interest since the sort order is not
|
||||
culturally valid in either case.
|
||||
|
||||
- The octet values FE and FF never appear.
|
||||
|
||||
UTF-8 was originally a project of the X/Open Joint
|
||||
Internationalization Group XOJIG with the objective to specify a File
|
||||
System Safe UCS Transformation Format [FSS-UTF] that is compatible
|
||||
with UNIX systems, supporting multilingual text in a single encoding.
|
||||
The original authors were Gary Miller, Greger Leijonhufvud and John
|
||||
Entenmann. Later, Ken Thompson and Rob Pike did significant work for
|
||||
the formal UTF-8.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Yergeau Informational [Page 2]
|
||||
|
||||
RFC 2044 UTF-8 October 1996
|
||||
|
||||
|
||||
A description can also be found in Unicode Technical Report #4 [UNI-
|
||||
CODE]. The definitive reference, including provisions for UTF-16
|
||||
data within UTF-8, is Annex R of ISO/IEC 10646-1 [ISO-10646].
|
||||
|
||||
2. UTF-8 definition
|
||||
|
||||
In UTF-8, characters are encoded using sequences of 1 to 6 octets.
|
||||
The only octet of a "sequence" of one has the higher-order bit set to
|
||||
0, the remaining 7 bits being used to encode the character value. In
|
||||
a sequence of n octets, n>1, the initial octet has the n higher-order
|
||||
bits set to 1, followed by a bit set to 0. The remaining bit(s) of
|
||||
that octet contain bits from the value of the character to be
|
||||
encoded. The following octet(s) all have the higher-order bit set to
|
||||
1 and the following bit set to 0, leaving 6 bits in each to contain
|
||||
bits from the character to be encoded.
|
||||
|
||||
The table below summarizes the format of these different octet types.
|
||||
The letter x indicates bits available for encoding bits of the UCS-4
|
||||
character value.
|
||||
|
||||
UCS-4 range (hex.) UTF-8 octet sequence (binary)
|
||||
0000 0000-0000 007F 0xxxxxxx
|
||||
0000 0080-0000 07FF 110xxxxx 10xxxxxx
|
||||
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx
|
||||
|
||||
0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
|
||||
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
|
||||
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx
|
||||
|
||||
Encoding from UCS-4 to UTF-8 proceeds as follows:
|
||||
|
||||
1) Determine the number of octets required from the character value
|
||||
and the first column of the table above.
|
||||
|
||||
2) Prepare the high-order bits of the octets as per the second column
|
||||
of the table.
|
||||
|
||||
3) Fill in the bits marked x from the bits of the character value,
|
||||
starting from the lower-order bits of the character value and
|
||||
putting them first in the last octet of the sequence, then the
|
||||
next to last, etc. until all x bits are filled in.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Yergeau Informational [Page 3]
|
||||
|
||||
RFC 2044 UTF-8 October 1996
|
||||
|
||||
|
||||
The algorithm for encoding UCS-2 (or Unicode) to UTF-8 can be
|
||||
obtained from the above, in principle, by simply extending each
|
||||
UCS-2 character with two zero-valued octets. However, UCS-2 val-
|
||||
ues between D800 and DFFF, being actually UCS-4 characters trans-
|
||||
formed through UTF-16, need special treatment: the UTF-16 trans-
|
||||
formation must be undone, yielding a UCS-4 character that is then
|
||||
transformed as above.
|
||||
|
||||
Decoding from UTF-8 to UCS-4 proceeds as follows:
|
||||
|
||||
1) Initialize the 4 octets of the UCS-4 character with all bits set
|
||||
to 0.
|
||||
|
||||
2) Determine which bits encode the character value from the number of
|
||||
octets in the sequence and the second column of the table above
|
||||
(the bits marked x).
|
||||
|
||||
3) Distribute the bits from the sequence to the UCS-4 character,
|
||||
first the lower-order bits from the last octet of the sequence and
|
||||
proceeding to the left until no x bits are left.
|
||||
|
||||
If the UTF-8 sequence is no more than three octets long, decoding
|
||||
can proceed directly to UCS-2 (or equivalently Unicode).
|
||||
|
||||
A more detailed algorithm and formulae can be found in [FSS_UTF],
|
||||
[UNICODE] or Annex R to [ISO-10646].
|
||||
|
||||
3. Examples
|
||||
|
||||
The Unicode sequence "A<NOT IDENTICAL TO><ALPHA>." (0041, 2262, 0391,
|
||||
002E) may be encoded as follows:
|
||||
|
||||
41 E2 89 A2 CE 91 2E
|
||||
|
||||
The Unicode sequence "Hi Mom <WHITE SMILING FACE>!" (0048, 0069,
|
||||
0020, 004D, 006F, 006D, 0020, 263A, 0021) may be encoded as follows:
|
||||
|
||||
48 69 20 4D 6F 6D 20 E2 98 BA 21
|
||||
|
||||
The Unicode sequence representing the Han characters for the Japanese
|
||||
word "nihongo" (65E5, 672C, 8A9E) may be encoded as follows:
|
||||
|
||||
E6 97 A5 E6 9C AC E8 AA 9E
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Yergeau Informational [Page 4]
|
||||
|
||||
RFC 2044 UTF-8 October 1996
|
||||
|
||||
|
||||
MIME registrations
|
||||
|
||||
This memo is meant to serve as the basis for registration of a MIME
|
||||
character encoding (charset) as per [RFC1521]. The proposed charset
|
||||
parameter value is "UTF-8". This string would label media types
|
||||
containing text consisting of characters from the repertoire of ISO
|
||||
10646-1 encoded to a sequence of octets using the encoding scheme
|
||||
outlined above.
|
||||
|
||||
Security Considerations
|
||||
|
||||
Security issues are not discussed in this memo.
|
||||
|
||||
Acknowledgments
|
||||
|
||||
The following have participated in the drafting and discussion of
|
||||
this memo:
|
||||
|
||||
James E. Agenbroad Andries Brouwer
|
||||
Martin J. D|rst David Goldsmith
|
||||
Edwin F. Hart Kent Karlsson
|
||||
Markus Kuhn Michael Kung
|
||||
Alain LaBonte Murray Sargent
|
||||
Keld Simonsen Arnold Winkler
|
||||
|
||||
Bibliography
|
||||
|
||||
[FSS_UTF] X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm.
|
||||
22p. pbk. 172g. 4/95, X/Open Company Ltd., "File Sys-
|
||||
tem Safe UCS Transformation Format (FSS_UTF)", X/Open
|
||||
Preleminary Specification, Document Number P316. Also
|
||||
published in Unicode Technical Report #4.
|
||||
|
||||
[ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Infor-
|
||||
mation technology -- Universal Multiple-Octet Coded
|
||||
Character Set (UCS) -- Part 1: Architecture and Basic
|
||||
Multilingual Plane. UTF-8 is described in Annex R,
|
||||
adopted but not yet published. UTF-16 is described in
|
||||
Annex Q, adopted but not yet published.
|
||||
|
||||
[RFC1521] Borenstein, N., and N. Freed, "MIME (Multipurpose
|
||||
Internet Mail Extensions) Part One: Mechanisms for
|
||||
Specifying and Describing the Format of Internet Mes-
|
||||
sage Bodies", RFC 1521, Bellcore, Innosoft, September
|
||||
1993.
|
||||
|
||||
[RFC1641] Goldsmith, D., and M. Davis, "Using Unicode with
|
||||
MIME", RFC 1641, Taligent inc., July 1994.
|
||||
|
||||
|
||||
|
||||
Yergeau Informational [Page 5]
|
||||
|
||||
RFC 2044 UTF-8 October 1996
|
||||
|
||||
|
||||
[RFC1642] Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe
|
||||
Transformation Format of Unicode", RFC 1642,
|
||||
Taligent, Inc., July 1994.
|
||||
|
||||
[UNICODE] The Unicode Consortium, "The Unicode Standard --
|
||||
Worldwide Character Encoding -- Version 1.0", Addison-
|
||||
Wesley, Volume 1, 1991, Volume 2, 1992. UTF-8 is
|
||||
described in Unicode Technical Report #4.
|
||||
|
||||
[US-ASCII] Coded Character Set--7-bit American Standard Code for
|
||||
Information Interchange, ANSI X3.4-1986.
|
||||
|
||||
Author's Address
|
||||
|
||||
Francois Yergeau
|
||||
Alis Technologies
|
||||
100, boul. Alexis-Nihon
|
||||
Suite 600
|
||||
Montreal QC H4M 2P2
|
||||
Canada
|
||||
|
||||
Tel: +1 (514) 747-2547
|
||||
Fax: +1 (514) 747-2561
|
||||
EMail: fyergeau@alis.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Yergeau Informational [Page 6]
|
||||
|
||||
563
doc/rfc/rfc2164.txt
Normal file
563
doc/rfc/rfc2164.txt
Normal file
@ -0,0 +1,563 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Kille
|
||||
Request for Comments: 2164 Isode Ltd.
|
||||
Obsoletes: 1838 January 1998
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
|
||||
Use of an X.500/LDAP directory to support MIXER address mapping
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
1 MIXER X.400/RFC 822 Mappings
|
||||
|
||||
MIXER (RFC 2156) defines an algorithm for use of a set of global
|
||||
mapping between X.400 and RFC 822 addresses [4]. This specification
|
||||
defines how to represent and maintain these mappings (MIXER
|
||||
Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP
|
||||
directory. Mechanisms for representing OR Address and Domain
|
||||
hierarchies within the DIT are defined in [5, 2]. These techniques
|
||||
are used to define two independent subtrees in the DIT, which contain
|
||||
the mapping information. The benefits of this approach are:
|
||||
|
||||
1. The mapping information is kept in a clearly defined area which
|
||||
can be widely replicated in an efficient manner. The tree is
|
||||
constrained to hold only information needed to support the
|
||||
mapping. This is important as gateways need good access to the
|
||||
entire mapping.
|
||||
|
||||
2. It facilitates migration from a table-based approach.
|
||||
|
||||
3. It handles the issues of "missing components" in a natural
|
||||
manner.
|
||||
|
||||
An alternative approach which is not taken is to locate the
|
||||
information in the routing subtrees. The benefits of this
|
||||
would be:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 1]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
o It is the "natural" location, and will also help to
|
||||
ensure correct administrative authority for a mapping
|
||||
definition.
|
||||
|
||||
o The tree will usually be accessed for routing, and so it
|
||||
will be efficient for addresses which are being routed.
|
||||
|
||||
This is not done, as the benefits of the approach proposed are
|
||||
greater.
|
||||
|
||||
MCGAMs are global. A MIXER gateway may use any set of MCGAMs. A key
|
||||
use of the directory is to enable MIXER gateways to share MCGAMs and
|
||||
to share the effort of maintaining and publishing MCGAMs. This
|
||||
specification and MIXER also recognise that there is not a single
|
||||
unique location for publication of all MCGAMs. This specification
|
||||
allows for multiple sets of MCGAMs to be published. Each set of
|
||||
MCGAMs is published under a single part of the directory. There are
|
||||
four mappings, which are represented by two subtrees located under
|
||||
any part of the DIT. For the examples the location defined below is
|
||||
used:
|
||||
|
||||
|
||||
OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
|
||||
|
||||
These subtree roots are of object class subtree, and use the
|
||||
mechanism for representing subtrees defined in [1].
|
||||
|
||||
|
||||
X.400 to RFC 822 This table gives the equivalence mapping from X.400
|
||||
to RFC 822. There is an OR Address tree under this. An example
|
||||
entry is:
|
||||
|
||||
PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822,
|
||||
OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
|
||||
|
||||
RFC 822 to X.400 There is a domain tree under this. This table holds
|
||||
the equivalence mapping from RFC 822 to X.400, and the gateway
|
||||
mapping defined in RFC 1327. An example entry is:
|
||||
|
||||
DomainComponent=ISODE, DomainComponent=COM,
|
||||
CN=RFC 822 to X.400,
|
||||
OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
|
||||
|
||||
The values of the table mapping are defined by use of two new object
|
||||
classes, as specified in Figure 1. The objects give pointers to the
|
||||
mapped components.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 2]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
2 Omitted Components
|
||||
|
||||
In MIXER, it is possible to have omitted components in OR Addresses
|
||||
on either side of the mapping. A mechanism to represent such omitted
|
||||
components is defined in Figure 2. The attribute at-or-address-
|
||||
component-type is set to the X.500 attribute type associated with the
|
||||
omitted component (e.g.,
|
||||
|
||||
|
||||
rFC822ToX400Mapping OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {domain-component}
|
||||
MAY CONTAIN {
|
||||
associatedORAddress|
|
||||
associatedX400Gateway}
|
||||
ID oc-rfc822-to-x400-mapping}
|
||||
|
||||
x400ToRFC822Mapping OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MAY CONTAIN { 10
|
||||
associatedDomain|
|
||||
associatedInternetGateway}
|
||||
ID oc-x400-to-rfc822-mapping}
|
||||
|
||||
associatedORAddress ATTRIBUTE ::= {
|
||||
SUBTYPE OF distinguishedName
|
||||
SINGLE VALUE
|
||||
ID at-associated-or-address}
|
||||
|
||||
20
|
||||
associatedX400Gateway ATTRIBUTE ::= {
|
||||
SUBTYPE OF mhs-or-addresses
|
||||
MULTI VALUE
|
||||
ID at-associated-x400-gateway}
|
||||
|
||||
associatedDomain ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX caseIgnoreIA5String
|
||||
SINGLE VALUE
|
||||
ID at-associated-domain} 30
|
||||
|
||||
associatedInternetGateway ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX caseIgnoreIA5String
|
||||
MULTI VALUE
|
||||
ID at-associated-internet-gateway}
|
||||
|
||||
|
||||
Figure 1: Object Classes for MIXER mappings
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 3]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
omittedORAddressComponent OBJECT-CLASS ::=
|
||||
SUBCLASS OF {top}
|
||||
MUST Contain {
|
||||
oRAddressComponentType
|
||||
}
|
||||
ID oc-omitted-or-address-component}
|
||||
|
||||
|
||||
oRAddressComponentType ATTRIBUTE ::= {
|
||||
SUBTYPE OF objectIdentifier 10
|
||||
SINGLE VALUE
|
||||
ID at-or-address-component-type}
|
||||
|
||||
Figure 2: Omitted OR Address Component
|
||||
|
||||
|
||||
at-prmd-name). This mechanism is for use only within the X.400 to
|
||||
RFC 822 subtree and for the at-associated-or-address attribute.
|
||||
|
||||
3 Mapping from X.400 to RFC 822
|
||||
|
||||
As an example, consider the mapping from the OR Address:
|
||||
|
||||
|
||||
P=Isode; A=Mailnet; C=FI
|
||||
|
||||
This would be keyed by the directory entry:
|
||||
|
||||
PRMD=Isode, ADMD=Mailnet, C=FI, CN=X.400 to RFC 822,
|
||||
OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
|
||||
|
||||
and return the mapping from the associatedDomain attribute, which
|
||||
gives the domain which this OR address maps to. This attribute is
|
||||
used to define authoritative mappings, which are placed in the open
|
||||
community tree. The manager of an MCGAM shall make the appropriate
|
||||
entry.
|
||||
|
||||
The Internet gateway mapping defined in MIXER[4] is provided by the
|
||||
associatedInternetGateway attribute. This value may identify
|
||||
multiple possible associated gateways. This information is looked up
|
||||
at the same time as mapped OR addresses. In effect, this provides a
|
||||
fallback mapping, which is found if there is no equivalence mapping.
|
||||
Because of the nature of the mapping an OR Address will map to either
|
||||
a gateway or a domain, but not both. Thus, there shall never be both
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 4]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
an associatedDomain and associatedInternetGateway attribute present
|
||||
in the same entry. Functionally, mapping takes place exactly
|
||||
according to MIXER. The longest match is found by the following
|
||||
algorithm.
|
||||
|
||||
1. Take the OR Address, and derive a directory name. This will be
|
||||
the OR Address as far as the lowest OU.
|
||||
|
||||
2. Look up the entire name derived from the MIXER key in the in the
|
||||
X.400 to RFC 822 subtree. This lookup will either succeed, or it
|
||||
will fail and indicate the longest possible match, which can then
|
||||
be looked up.
|
||||
|
||||
3. Check for an associatedDomain or associatedInternetGateway
|
||||
attribute in the matched entry.
|
||||
|
||||
The mapping can always be achieved with two lookups. Because of the
|
||||
availability of aliases, some of the table mappings may be
|
||||
simplified. In addition, the directory can support mapping from
|
||||
addresses using the numeric country codes.
|
||||
|
||||
4 Mapping from RFC 822 to X.400
|
||||
|
||||
There is an analogous structure for mappings in the reverse
|
||||
direction. The domain hierarchy is represented in the DIT according
|
||||
to RFC 1279. The domain:
|
||||
|
||||
ISODE.COM
|
||||
|
||||
Is represented in the DIT as:
|
||||
|
||||
DomainComponent=ISODE, DomainComponent=COM, CN=RFC 822 to X.400,
|
||||
OU=MIXER MCGAMs, O=Zydeco Plc, C=GB
|
||||
|
||||
This has associated with it the attribute associatedORAddress encoded
|
||||
as a distinguished name with a value: PRMD=Isode, ADMD=Mailnet, C=FI
|
||||
|
||||
The X.400 gateway mapping defined in MIXER[4] is provided by the
|
||||
associatedX400Gateway attribute. This value may identify multiple
|
||||
possible associated gateways. This information is looked up at the
|
||||
same time as mapped OR addresses. In effect, this provides a
|
||||
fallback mapping, which is found if there is no equivalence mapping.
|
||||
Because of the nature of the mapping a domain will map to either a
|
||||
gateway or a domain, but not both. Thus, there shall never be both
|
||||
an associatedX400Gateway and associatedORAddress attribute present in
|
||||
the same entry. Functionally, mapping takes place exactly according
|
||||
to MIXER. The longest match is found by the following algorithm.
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 5]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
1. Derive a directory name from the domain part of the RFC 822
|
||||
address.
|
||||
|
||||
2. Look up this name in the RFC 822 to X.400 subtree to find the
|
||||
mapped value (either associatedORAddress or
|
||||
associatedX400Gateway.). If the lookup fails, the error will
|
||||
indicate the longest match, which can then be looked up.
|
||||
|
||||
If associatedORAddress is found, this will define the mapped OR
|
||||
Address. The mapping can always be achieved with two lookups. If an
|
||||
associatedX400Gateway is present, the address in question will be
|
||||
encoded as a domain defined attribute, relative to the OR Address
|
||||
defined by this attribute. If multiple associatedX400Gateway
|
||||
attributes are found, the MTA may select the one it chooses to use.
|
||||
|
||||
Because of the availability of aliases, some of the table mappings
|
||||
may be simplified. In addition, the directory can support mapping
|
||||
from addresses using the numeric country codes.
|
||||
|
||||
5 Gateway Selection of MCGAMs
|
||||
|
||||
The directory information to support identification of MCGAMs is
|
||||
given in Figure 3. A MIXER gateway simply identifies the an ordered
|
||||
lists of MCGAM collections that it will use for lookup. These are
|
||||
referenced by name. A gateway is not required to use any MCGAMs.
|
||||
Where MCGAMs are accessed from multiple sources, it is recommended
|
||||
that all of the sources be accessed in order to determine the MCGAM
|
||||
which gives the
|
||||
|
||||
|
||||
mixerGateway OBJECT-CLASS ::=
|
||||
KIND auxiliary
|
||||
SUBCLASS OF {mhs-message-transfer-agent}
|
||||
MUST Contain {
|
||||
mcgamTables
|
||||
}
|
||||
ID oc-mixer-gateway}
|
||||
|
||||
|
||||
mcgamTables ATTRIBUTE ::= { 10
|
||||
WITH SYNTAX SEQUENCE OF DistinguishedName
|
||||
SINGLE VALUE
|
||||
ID at-mcgam-tables}
|
||||
|
||||
Figure 3: Object Classes for MCGAM selection
|
||||
|
||||
|
||||
best match.
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 6]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
6 Acknowledgements
|
||||
|
||||
Acknowledgements for work on this document are given in [3].
|
||||
|
||||
References
|
||||
|
||||
[1] Kille, S., "Representing tables and subtrees in the X.500
|
||||
directory", RFC 1837, August 1995.
|
||||
|
||||
[2] Kille, S., "Representing the O/R Address hierarchy in the X.500
|
||||
directory information tree," RFC 1836, August 1995.
|
||||
|
||||
[3] Kille, S., " X.400-MHS use of the X.500 directory to support
|
||||
X.400-MHS routing," RFC 1801, June 1995.
|
||||
|
||||
[4] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
|
||||
Mapping between X.400 and RFC 822/MIME," RFC 2156, January 1998.
|
||||
|
||||
[5] Kille, S., Wahl, M., Grimsatd, A., Huber, R., and S. Sataluri,
|
||||
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
|
||||
January 1998.
|
||||
|
||||
7 Security Considerations
|
||||
|
||||
This document specifies a means by which the X.500/LDAP directory
|
||||
service can direct the translation between X.400 and Internet mail
|
||||
addresses. This can indirectly affect the routing of messages across
|
||||
a gateway between X.400 and Internet Mail. A succesful attack on
|
||||
this service could cause incorrect translation of an originator
|
||||
address (thus "forging" the originator address), or incorrect
|
||||
translation of a recipient address (thus directing the mail to an
|
||||
unauthorized recipient, or making it appear to an authorized
|
||||
recipient, that the message was intended for recipients other than
|
||||
those chosen by the originator). When cryptographic authentication
|
||||
is available for directory responses, clients shall employ those
|
||||
mechanisms to verify the authenticity and integrity of those
|
||||
responses.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 7]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
8 Author's Address
|
||||
|
||||
Steve Kille
|
||||
Isode Ltd.
|
||||
The Dome
|
||||
The Square
|
||||
Richmond
|
||||
TW9 1DT
|
||||
England
|
||||
|
||||
Phone: +44-181-332-9091
|
||||
Internet EMail: S.Kille@ISODE.COM
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 8]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
A Object Identifier Assignment
|
||||
|
||||
|
||||
mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
|
||||
enterprises(1) isode-consortium (453) mhs-ds (7)}
|
||||
|
||||
mapping OBJECT IDENTIFIER ::= {mhs-ds 4}
|
||||
|
||||
oc OBJECT IDENTIFIER ::= {mapping 1}
|
||||
at OBJECT IDENTIFIER ::= {mapping 2}
|
||||
|
||||
|
||||
oc-rfc822-to-x400-mapping OBJECT IDENTIFIER ::= {oc 1} 10
|
||||
oc-x400-to-rfc822-mapping OBJECT IDENTIFIER ::= {oc 2}
|
||||
oc-omitted-or-address-component OBJECT IDENTIFIER ::= {oc 3}
|
||||
oc-mixer-gateway ::= {oc 4}
|
||||
|
||||
at-associated-or-address OBJECT IDENTIFIER ::= {at 6}
|
||||
at-associated-x400-gateway OBJECT IDENTIFIER ::= {at 3}
|
||||
at-associated-domain OBJECT IDENTIFIER ::= {at 4}
|
||||
at-or-address-component-type OBJECT IDENTIFIER ::= {at 7}
|
||||
at-associated-internet-gateway OBJECT IDENTIFIER ::= {at 8}
|
||||
at-mcgam-tables ::= {at 9} 20
|
||||
|
||||
|
||||
Figure 4: Object Identifier Assignment
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 9]
|
||||
|
||||
RFC 2164 X.500/LDAP Directory to Support MIXER January 1998
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 10]
|
||||
|
||||
451
doc/rfc/rfc2218.txt
Normal file
451
doc/rfc/rfc2218.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group T. Genovese
|
||||
Request for Comments: 2218 Microsoft
|
||||
Category: Standards Track B. Jennings
|
||||
Sandia National Laboratory
|
||||
October 1997
|
||||
|
||||
|
||||
A Common Schema for the Internet White Pages Service
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This work is the result of the IETF Integrated Directory Services
|
||||
(IDS) Working Group. The IDS Working Group proposes a standard
|
||||
specification for a simple Internet White Pages service by defining a
|
||||
common schema for use by the various White Pages servers. This
|
||||
schema is independent of specific implementations of the White Pages
|
||||
service.
|
||||
|
||||
This document specifies the minimum set of core attributes of a White
|
||||
Pages entry for an individual and describes how new objects with
|
||||
those attributes can be defined and published. It does not describe
|
||||
how to represent other objects in the White Pages service. Further,
|
||||
it does not address the search sort expectations within a particular
|
||||
service.
|
||||
|
||||
1.0 Introduction to IWPS
|
||||
|
||||
The Internet community has stated a need for the development and
|
||||
deployment of a White Pages service for use in locating information
|
||||
about people in the Internet [PA94]. To facilitate interoperability
|
||||
and to provide a common user experience, the Internet White Pages
|
||||
Service (IWPS) must have a common set of information about each
|
||||
person.
|
||||
|
||||
A common user object would allow a user to go between implementations
|
||||
of the service and to expect consistency in the types of information
|
||||
provided. A common user object would also provide developers with an
|
||||
unambigious method of representing the information managed by the
|
||||
service.
|
||||
|
||||
|
||||
|
||||
Genovese & Jennings Standards Track [Page 1]
|
||||
|
||||
RFC 2218 Common Schema for IWPS October 1997
|
||||
|
||||
|
||||
This document will focus only on common information modeling issues
|
||||
to which all IWPS providers must conform.
|
||||
|
||||
2.0 Scope
|
||||
|
||||
This document establishes the set of attributes that specify the
|
||||
Common User Information Object for the IWPS. It does not attempt to
|
||||
be an exhaustive specification of all objects that may be stored in
|
||||
the IWPS. The process used by this document to define the user object
|
||||
is recommended to be used to define other information objects used in
|
||||
the IWPS.
|
||||
|
||||
All conforming implementations must support at the minimum, the core
|
||||
attributes listed in Section 5.0. Implementations may include local
|
||||
attributes in addition to the core set and still be considered "in
|
||||
conformance".
|
||||
|
||||
This document will not specify rules with respect to information
|
||||
privacy. Each country has its own set of laws and practices.
|
||||
Previous work covering this area has been done by the North American
|
||||
Directory Forum (NADF), whose publication [NADF92] contain
|
||||
recommendations for registrants' rights in both the USA and Canada.
|
||||
|
||||
This document does not specify a Directory access protocol (i.e.
|
||||
whois++, LDAP, DAP, etc.).
|
||||
|
||||
3.0 IWPS Schema Considerations
|
||||
|
||||
The description of the IWPS information object consists of the
|
||||
following requirements:
|
||||
|
||||
1. Syntax for definition/representation of information
|
||||
object templates.
|
||||
2. Publication of information object templates, etc.
|
||||
3. Database structure or schema.
|
||||
|
||||
Items 1 and 2 will be covered in this document. Because database
|
||||
structure can potentially restrict implementations (i.e. X.500 schema
|
||||
based versus DNS schema based) it will be treated as a separate
|
||||
research topic and will not be defined in this paper.
|
||||
|
||||
4.0 Syntax for Definition/Representation of Information Object
|
||||
Templates
|
||||
|
||||
A clear, precise, and consistent method must be used when discussing
|
||||
information object templates and their associated attributes.
|
||||
Therefore, this document makes uses of the previously defined syntax
|
||||
used by LDAP. To avoid restrictions on implementations of the IWPS,
|
||||
|
||||
|
||||
|
||||
Genovese & Jennings Standards Track [Page 2]
|
||||
|
||||
RFC 2218 Common Schema for IWPS October 1997
|
||||
|
||||
|
||||
some syntax are listed as requirements vs specific encodings. The
|
||||
general IWPS syntax is included in section 6.0 for reference.
|
||||
|
||||
The IWPS Person Object specifies a limited set of recommended
|
||||
attributes that a White Pages Service must include. Storage of user
|
||||
attributes are a local issue, therefore, this memo suggests storage
|
||||
sizes but not storage types.
|
||||
|
||||
This document lists the syntax with the attributes for developers of
|
||||
user interface (UIs) to use as a reference, but it does not specify
|
||||
how the UI should display these attributes.
|
||||
|
||||
Attributes that contain multiple-line text (i.e. Address) must use
|
||||
the procedure defined in RFC 822 in section 3.1.1 on "folding" long
|
||||
header lines [RFC-822].
|
||||
|
||||
5.0 Information Object Template Definitions
|
||||
|
||||
This section describes the IWPS Person Information Object Template
|
||||
and its associated attributes. The Person Object is a simple list of
|
||||
attributes, no structure nor object inheritance is implied.
|
||||
|
||||
IWPS client applications should use the following size
|
||||
recommendations as the maximum sizes of the attributes. However,
|
||||
applications should be able to handle attributes of arbitrary size,
|
||||
returned by a server which may not comply with these recommendation.
|
||||
All size recommendations are in characters.
|
||||
|
||||
Note: Because many characters in many encodings require more than one
|
||||
byte, the size recommendations cannot be interpreted as sizes in
|
||||
bytes.
|
||||
|
||||
This set of attributes describes information types, and are not
|
||||
defined attributes in a particular schema. Any technology deploying
|
||||
a White Page service (WHOIS ++, LDAP, vCard, etc.) will need to
|
||||
publish as a companion document, their specific schema detailing how
|
||||
the general attributes of the White Pages schema are expressed.
|
||||
|
||||
SPECIAL CONSIDERATIONS
|
||||
|
||||
Phone number: The full international form is recommended;
|
||||
i.e. +1 206 703 0852. The field may contain
|
||||
additional information following the phone
|
||||
number. For example:
|
||||
|
||||
+1 800 759 7243 #123456
|
||||
+1 505 882 8080 ext. 30852
|
||||
|
||||
|
||||
|
||||
|
||||
Genovese & Jennings Standards Track [Page 3]
|
||||
|
||||
RFC 2218 Common Schema for IWPS October 1997
|
||||
|
||||
|
||||
Email address: Is multivalued.
|
||||
|
||||
Certificate: Is multivalued.
|
||||
|
||||
Common Name: Is multivalued.
|
||||
|
||||
Language Spoken: Is multivalued.
|
||||
|
||||
THE INFORMATION OBJECT TEMPLATE FOR THE IWPS PERSON
|
||||
|
||||
--General Attributes --
|
||||
|
||||
Field Name Size Syntax
|
||||
|
||||
Email 360 Mailbox
|
||||
Cert 4000 Certificate
|
||||
Home Page 128 URI
|
||||
Common Name 64 WhitepageString
|
||||
Given Name 48 WhitepageString
|
||||
Surname 48 WhitepageString
|
||||
Organization 64 WhitepageString
|
||||
Locality 20 WhitepageString
|
||||
Country 2 WhitepageString (ISO 3166)
|
||||
Language Spoken 128 WhitepageString (RFC 1766)
|
||||
|
||||
--Personal Attributes
|
||||
|
||||
Personal Phone 30 PrintableString
|
||||
Personal Fax 30 PrintableString
|
||||
Personal Mobile Phone 30 PrintableString
|
||||
Personal Pager Number 30 PrintableString
|
||||
Personal Postal Address 255 Address
|
||||
Description 255 WhitepageString
|
||||
|
||||
--Organizational Attributes
|
||||
|
||||
Title 64 WhitepageString
|
||||
Office Phone 30 PrintableString
|
||||
Office Fax 30 PrintableString
|
||||
Office Mobile Phone 30 PrintableString
|
||||
Office Pager 30 PrintableString
|
||||
Office Postal Address 255 Address
|
||||
|
||||
--Ancillary
|
||||
|
||||
Creation Date 24 GeneralizedTime
|
||||
Creator Name 255 URI
|
||||
Modified Date 24 GeneralizedTime
|
||||
|
||||
|
||||
|
||||
Genovese & Jennings Standards Track [Page 4]
|
||||
|
||||
RFC 2218 Common Schema for IWPS October 1997
|
||||
|
||||
|
||||
Modifier Name 255 URI
|
||||
|
||||
6.0 IWPS Person Information Object Template Syntax
|
||||
|
||||
This section defines the syntax used by the IWPS person information
|
||||
object template. It is copied in whole from the LDAP attribute
|
||||
working document with some modification for completeness.
|
||||
|
||||
Certificate:
|
||||
|
||||
The certificate field is intended to hold any kind of certificate;
|
||||
X.509 certificates are one example. A specific implementation will
|
||||
specify how to indicate the type of certificate when describing
|
||||
the mapping of the IWPS schema onto the implementation schema.
|
||||
|
||||
WhitepageString:
|
||||
|
||||
This syntax must be able to encode arbitrary ISO 10646 characters.
|
||||
One such encoding is the UTF-8 encoding [UTF-8].
|
||||
|
||||
GeneralizedTime:
|
||||
|
||||
Values of this syntax are encoded as printable strings,
|
||||
represented as specified in X.208. Note that the time zone must
|
||||
be specified. It is strongly recommended that Zulu time zone be
|
||||
used. For example:
|
||||
|
||||
199412161032Z
|
||||
|
||||
Mailbox:
|
||||
|
||||
here are many kinds of mailbox addresses, including X.400 and
|
||||
Internet mailbox addresses. The implementation must clearly
|
||||
distinguish between different types of mailbox address, for
|
||||
instance by using a textual refix or a set of attribute types.
|
||||
There must be a way to represent any mailbox type.
|
||||
|
||||
Address:
|
||||
|
||||
According to Universal Postal Union standards, this field must be
|
||||
able to represent at least 6 lines of 40 characters.
|
||||
|
||||
PrintableString:
|
||||
|
||||
The encoding of a value with PrintableString syntax is the string
|
||||
value itself. PrintableString is limited to the characters in
|
||||
production <p>. Where production <p> is described by the
|
||||
following:
|
||||
|
||||
|
||||
|
||||
Genovese & Jennings Standards Track [Page 5]
|
||||
|
||||
RFC 2218 Common Schema for IWPS October 1997
|
||||
|
||||
|
||||
<a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
|
||||
'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
|
||||
's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
|
||||
'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
|
||||
'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
|
||||
'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
|
||||
|
||||
<d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
|
||||
|
||||
|
||||
<p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
|
||||
'/' | ':' | '?' | ' '
|
||||
|
||||
7.0 Publication of IWPS Information Object Templates.
|
||||
|
||||
The Working Group recommends that all information object templates
|
||||
used for the IWPS be published.
|
||||
|
||||
Individual organizations may define information object templates that
|
||||
are local in scope as required to meet local organizational needs.
|
||||
All information that the organization wishes to be part of the IWPS
|
||||
must use a published IWPS information object template.
|
||||
|
||||
8.0 Data Privacy
|
||||
|
||||
Each country, and each state within the US, has legislation defining
|
||||
information privacy. The suggested attributes in Section 5.0 may be
|
||||
considered private and the directory administrator is strongly
|
||||
advised to verify the privacy legislation for his domain.
|
||||
|
||||
As suggested in "Privacy and Accuracy in NIC Databases" [RFC-1355],
|
||||
each directory provider should provide a clear statement of the
|
||||
purpose of the directory, the information that should be contained in
|
||||
it, and a privacy policy associated with that information. This
|
||||
policy should include restrictions for data dissemination.
|
||||
|
||||
This policy is strongly recommended for the US and Canada and
|
||||
required by many countries in the European Community for data
|
||||
sharing.
|
||||
|
||||
9.0 Data Integrity
|
||||
|
||||
Data Integrity was first addressed in RFC 1107 [KS89], which states
|
||||
"a White Pages service will not be used, if the information it
|
||||
provides is out of date or incorrect." Therefore, any production
|
||||
IWPS provider must insure that all data is reasonably correct and
|
||||
up-to-date.
|
||||
|
||||
|
||||
|
||||
|
||||
Genovese & Jennings Standards Track [Page 6]
|
||||
|
||||
RFC 2218 Common Schema for IWPS October 1997
|
||||
|
||||
|
||||
The Ancillary Attributes of the IWPS person template denote the
|
||||
information's source and date of origin, and the source and date of
|
||||
its latest modification. They provide the user with some measurement
|
||||
of the quality of data making it easy to determine the owner and
|
||||
freshness of the data retrieved.
|
||||
|
||||
The IWPS User Agent must be able to retrieve and display Ancillary
|
||||
Attributes. Retrieval and display may be done as separate
|
||||
operations.
|
||||
|
||||
The Ancillary Attributes are recommended as the minimum set of
|
||||
attributes for any new information object template. Each IWPS server
|
||||
may individually decide whether to support the storage and retrieval
|
||||
of this data.
|
||||
|
||||
The Ancillary Attributes (also defined in Section 5.0) provide the
|
||||
following information about its associated information object:
|
||||
|
||||
1. The date and time the entry was created; Creation Date.
|
||||
|
||||
2. Owner or individual responsible for the data creation;
|
||||
Creator Name.
|
||||
|
||||
3. The date and time of the last modification;
|
||||
Modified Date.
|
||||
|
||||
4. Individual responsible for the last modification;
|
||||
Modifier Name.
|
||||
|
||||
10.0 Security Considerations
|
||||
|
||||
Security is implementation and deployment specific and as such is not
|
||||
addressed in this memo. Security must ensure that the constraints
|
||||
mentioned in the Data Privacy Section 8.0 are complied with.
|
||||
|
||||
11.0 References
|
||||
|
||||
[KS89] Sollins, K., "A Plan for Internet Directory Services", RFC
|
||||
1107, Laboratory for Computer Science, MIT, July 1989.
|
||||
|
||||
[NADF92] North American Directory Forum, "User Bill of Rights for
|
||||
entries and listings in the Public Directory', RFC 1295,
|
||||
North American Directory Forum, January 1992.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Genovese & Jennings Standards Track [Page 7]
|
||||
|
||||
RFC 2218 Common Schema for IWPS October 1997
|
||||
|
||||
|
||||
[PA94] Postel, J., and C. Anderson, "WHITE PAGES MEETING REPORT",
|
||||
RFC 1588, University of Southern California, February 1994.
|
||||
|
||||
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
|
||||
Text Messages", STD 11, RFC 822, August 1982.
|
||||
|
||||
[RFC-1355] Curran, J., and A. Marine, "Privacy and Accuracy Issues
|
||||
in Network Information Center Databases", FYI 15, RFC 1355, August
|
||||
1992.
|
||||
|
||||
[UCS] Universal Multiple-Octet Coded Character Set (UCS) -
|
||||
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.
|
||||
|
||||
[RFC-1766] Alvestrand, H., "Tags for the Identification of
|
||||
Languages", RFC 1766, March 1995.
|
||||
|
||||
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
|
||||
Work in Progress.
|
||||
|
||||
11.0 Authors' Addresses
|
||||
|
||||
Tony Genovese
|
||||
The Microsoft Corporation
|
||||
One Microsoft Way
|
||||
Redmond, Washington 98007
|
||||
USA
|
||||
|
||||
Phone: (206) 703-0852
|
||||
EMail: TonyG@Microsoft.com
|
||||
|
||||
|
||||
Barbara Jennings
|
||||
Sandia National Laboratories
|
||||
Albuquerque, New Mexico 87106
|
||||
USA
|
||||
|
||||
Phone: (505) 845-8554
|
||||
EMail: jennings@sandia.gov
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Genovese & Jennings Standards Track [Page 8]
|
||||
|
||||
395
doc/rfc/rfc2247.txt
Normal file
395
doc/rfc/rfc2247.txt
Normal file
@ -0,0 +1,395 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Kille
|
||||
Request for Comments: 2247 Isode Ltd.
|
||||
Category: Standards Track M. Wahl
|
||||
Critical Angle Inc.
|
||||
A. Grimstad
|
||||
AT&T
|
||||
R. Huber
|
||||
AT&T
|
||||
S. Sataluri
|
||||
AT&T
|
||||
January 1998
|
||||
|
||||
|
||||
|
||||
Using Domains in LDAP/X.500 Distinguished Names
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
1. Abstract
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) uses X.500-
|
||||
compatible distinguished names [3] for providing unique
|
||||
identification of entries.
|
||||
|
||||
This document defines an algorithm by which a name registered with
|
||||
the Internet Domain Name Service [2] can be represented as an LDAP
|
||||
distinguished name.
|
||||
|
||||
2. Background
|
||||
|
||||
The Domain (Nameserver) System (DNS) provides a hierarchical resource
|
||||
labeling system. A name is made up of an ordered set of components,
|
||||
each of which are short strings. An example domain name with two
|
||||
components would be "CRITICAL-ANGLE.COM".
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille, et. al. Standards Track [Page 1]
|
||||
|
||||
RFC 2247 Using Domains in LDAP/X.500 January 1998
|
||||
|
||||
|
||||
LDAP-based directories provide a more general hierarchical naming
|
||||
framework. A primary difference in specification of distinguished
|
||||
names from domain names is that each component of an distinguished
|
||||
name has an explicit attribute type indication.
|
||||
|
||||
X.500 does not mandate any particular naming structure. It does
|
||||
contain suggested naming structures which are based on geographic and
|
||||
national regions, however there is not currently an established
|
||||
registration infrastructure in many regions which would be able to
|
||||
assign or ensure uniqueness of names.
|
||||
|
||||
The mechanism described in this document automatically provides an
|
||||
enterprise a distinguished name for each domain name it has obtained
|
||||
for use in the Internet. These distinguished names may be used to
|
||||
identify objects in an LDAP directory.
|
||||
|
||||
An example distinguished name represented in the LDAP string format
|
||||
[3] is "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most
|
||||
significant component, closest to the root of the namespace, is
|
||||
written last.
|
||||
|
||||
This document does not define how to represent objects which do not
|
||||
have domain names. Nor does this document define the procedure to
|
||||
locate an enterprise's LDAP directory server, given their domain
|
||||
name. Such procedures may be defined in future RFCs.
|
||||
|
||||
3. Mapping Domain Names into Distinguished Names
|
||||
|
||||
This section defines a subset of the possible distinguished name
|
||||
structures for use in representing names allocated in the Internet
|
||||
Domain Name System. It is possible to algorithmically transform any
|
||||
Internet domain name into a distinguished name, and to convert these
|
||||
distinguished names back into the original domain names.
|
||||
|
||||
The algorithm for transforming a domain name is to begin with an
|
||||
empty distinguished name (DN) and then attach Relative Distinguished
|
||||
Names (RDNs) for each component of the domain, most significant (e.g.
|
||||
rightmost) first. Each of these RDNs is a single
|
||||
AttributeTypeAndValue, where the type is the attribute "DC" and the
|
||||
value is an IA5 string containing the domain name component.
|
||||
|
||||
Thus the domain name "CS.UCL.AC.UK" can be transformed into
|
||||
|
||||
DC=CS,DC=UCL,DC=AC,DC=UK
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille, et. al. Standards Track [Page 2]
|
||||
|
||||
RFC 2247 Using Domains in LDAP/X.500 January 1998
|
||||
|
||||
|
||||
Distinguished names in which there are one or more RDNs, all
|
||||
containing only the attribute type DC, can be mapped back into domain
|
||||
names. Note that this document does not define a domain name
|
||||
equivalence for any other distinguished names.
|
||||
|
||||
4. Attribute Type Definition
|
||||
|
||||
The DC (short for domainComponent) attribute type is defined as
|
||||
follows:
|
||||
|
||||
( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
|
||||
SUBSTR caseIgnoreIA5SubstringsMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
|
||||
|
||||
The value of this attribute is a string holding one component of a
|
||||
domain name. The encoding of IA5String for use in LDAP is simply the
|
||||
characters of the string itself. The equality matching rule is case
|
||||
insensitive, as is today's DNS.
|
||||
|
||||
5. Object Class Definitions
|
||||
|
||||
An object with a name derived from its domain name using the
|
||||
algorithm of section 3 is represented as an entry in the directory.
|
||||
The "DC" attribute is present in the entry and used as the RDN.
|
||||
|
||||
An attribute can only be present in an entry held by an LDAP server
|
||||
when that attribute is permitted by the entry's object class.
|
||||
|
||||
This section defines two object classes. The first, dcObject, is
|
||||
intended to be used in entries for which there is an appropriate
|
||||
structural object class. For example, if the domain represents a
|
||||
particular organization, the entry would have as its structural
|
||||
object class 'organization', and the 'dcObject' class would be an
|
||||
auxiliary class. The second, domain, is a structural object class
|
||||
used for entries in which no other information is being stored. The
|
||||
domain object class is typically used for entries that are
|
||||
placeholders or whose domains do not correspond to real-world
|
||||
entities.
|
||||
|
||||
5.1. The dcObject object class
|
||||
|
||||
The dcObject object class permits the dc attribute to be present in
|
||||
an entry. This object class is defined as auxiliary, as it would
|
||||
typically be used in conjunction with an existing structural object
|
||||
class, such as organization, organizationalUnit or locality.
|
||||
|
||||
The following object class, along with the dc attribute, can be added
|
||||
to any entry.
|
||||
|
||||
|
||||
|
||||
Kille, et. al. Standards Track [Page 3]
|
||||
|
||||
RFC 2247 Using Domains in LDAP/X.500 January 1998
|
||||
|
||||
|
||||
( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )
|
||||
|
||||
An example entry would be:
|
||||
|
||||
dn: dc=critical-angle,dc=com
|
||||
objectClass: top
|
||||
objectClass: organization
|
||||
objectClass: dcObject
|
||||
dc: critical-angle
|
||||
o: Critical Angle Inc.
|
||||
|
||||
5.2. The domain object class
|
||||
|
||||
If the entry does not correspond to an organization, organizational
|
||||
unit or other type of object for which an object class has been
|
||||
defined, then the "domain" object class can be used. The "domain"
|
||||
object class requires that the "DC" attribute be present, and permits
|
||||
several other attributes to be present in the entry.
|
||||
|
||||
The entry will have as its structural object class the "domain"
|
||||
object class.
|
||||
|
||||
( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL
|
||||
MUST dc
|
||||
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
|
||||
x121Address $ registeredAddress $ destinationIndicator $
|
||||
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
|
||||
telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
|
||||
street $ postOfficeBox $ postalCode $ postalAddress $
|
||||
physicalDeliveryOfficeName $ st $ l $ description $ o $
|
||||
associatedName ) )
|
||||
|
||||
The optional attributes of the domain class are used for describing
|
||||
the object represented by this domain, and may also be useful when
|
||||
searching. These attributes are already defined for use with LDAP
|
||||
[4].
|
||||
|
||||
An example entry would be:
|
||||
|
||||
dn: dc=tcp,dc=critical-angle,dc=com
|
||||
objectClass: top
|
||||
objectClass: domain
|
||||
dc: tcp
|
||||
description: a placeholder entry used with SRV records
|
||||
|
||||
The DC attribute is used for naming entries of the domain class, and
|
||||
this can be represented in X.500 servers by the following name form
|
||||
rule.
|
||||
|
||||
|
||||
|
||||
Kille, et. al. Standards Track [Page 4]
|
||||
|
||||
RFC 2247 Using Domains in LDAP/X.500 January 1998
|
||||
|
||||
|
||||
( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )
|
||||
|
||||
6. References
|
||||
|
||||
[1] The Directory: Selected Attribute Types. ITU-T Recommendation
|
||||
X.520, 1993.
|
||||
|
||||
[2] Mockapetris, P., " Domain Names - Concepts and Facilities,"
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
[3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol
|
||||
(v3): UTF-8 String Representation of Distinguished Names", RFC
|
||||
2253, December 1997.
|
||||
|
||||
[4] Wahl, M., "A Summary of the X.500(96) User Schema for use with
|
||||
LDAP", RFC 2256, December 1997.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
This memo describes how attributes of objects may be discovered and
|
||||
retrieved. Servers should ensure that an appropriate security policy
|
||||
is maintained.
|
||||
|
||||
An enterprise is not restricted in the information which it may store
|
||||
in DNS or LDAP servers. A client which contacts an untrusted server
|
||||
may have incorrect or misleading information returned (e.g. an
|
||||
organization's server may claim to hold naming contexts representing
|
||||
domain names which have not been delegated to that organization).
|
||||
|
||||
8. Authors' Addresses
|
||||
|
||||
Steve Kille
|
||||
Isode Ltd.
|
||||
The Dome
|
||||
The Square
|
||||
Richmond, Surrey
|
||||
TW9 1DT
|
||||
England
|
||||
|
||||
Phone: +44-181-332-9091
|
||||
EMail: S.Kille@ISODE.COM
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille, et. al. Standards Track [Page 5]
|
||||
|
||||
RFC 2247 Using Domains in LDAP/X.500 January 1998
|
||||
|
||||
|
||||
Mark Wahl
|
||||
Critical Angle Inc.
|
||||
4815 W. Braker Lane #502-385
|
||||
Austin, TX 78759
|
||||
USA
|
||||
|
||||
Phone: (1) 512 372 3160
|
||||
EMail: M.Wahl@critical-angle.com
|
||||
|
||||
|
||||
Al Grimstad
|
||||
AT&T
|
||||
Room 1C-429, 101 Crawfords Corner Road
|
||||
Holmdel, NJ 07733-3030
|
||||
USA
|
||||
|
||||
EMail: alg@att.com
|
||||
|
||||
|
||||
Rick Huber
|
||||
AT&T
|
||||
Room 1B-433, 101 Crawfords Corner Road
|
||||
Holmdel, NJ 07733-3030
|
||||
USA
|
||||
|
||||
EMail: rvh@att.com
|
||||
|
||||
|
||||
Sri Sataluri
|
||||
AT&T
|
||||
Room 4G-202, 101 Crawfords Corner Road
|
||||
Holmdel, NJ 07733-3030
|
||||
USA
|
||||
|
||||
EMail: sri@att.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille, et. al. Standards Track [Page 6]
|
||||
|
||||
RFC 2247 Using Domains in LDAP/X.500 January 1998
|
||||
|
||||
|
||||
9. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille, et. al. Standards Track [Page 7]
|
||||
|
||||
2803
doc/rfc/rfc2251.txt
Normal file
2803
doc/rfc/rfc2251.txt
Normal file
File diff suppressed because it is too large
Load Diff
1795
doc/rfc/rfc2252.txt
Normal file
1795
doc/rfc/rfc2252.txt
Normal file
File diff suppressed because it is too large
Load Diff
563
doc/rfc/rfc2253.txt
Normal file
563
doc/rfc/rfc2253.txt
Normal file
@ -0,0 +1,563 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Wahl
|
||||
Request for Comments: 2253 Critical Angle Inc.
|
||||
Obsoletes: 1779 S. Kille
|
||||
Category: Standards Track Isode Ltd.
|
||||
T. Howes
|
||||
Netscape Communications Corp.
|
||||
December 1997
|
||||
|
||||
|
||||
Lightweight Directory Access Protocol (v3):
|
||||
UTF-8 String Representation of Distinguished Names
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1997). All Rights Reserved.
|
||||
|
||||
IESG Note
|
||||
|
||||
This document describes a directory access protocol that provides
|
||||
both read and update access. Update access requires secure
|
||||
authentication, but this document does not mandate implementation of
|
||||
any satisfactory authentication mechanisms.
|
||||
|
||||
In accordance with RFC 2026, section 4.4.1, this specification is
|
||||
being approved by IESG as a Proposed Standard despite this
|
||||
limitation, for the following reasons:
|
||||
|
||||
a. to encourage implementation and interoperability testing of
|
||||
these protocols (with or without update access) before they
|
||||
are deployed, and
|
||||
|
||||
b. to encourage deployment and use of these protocols in read-only
|
||||
applications. (e.g. applications where LDAPv3 is used as
|
||||
a query language for directories which are updated by some
|
||||
secure mechanism other than LDAP), and
|
||||
|
||||
c. to avoid delaying the advancement and deployment of other Internet
|
||||
standards-track protocols which require the ability to query, but
|
||||
not update, LDAPv3 directory servers.
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 1]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
Readers are hereby warned that until mandatory authentication
|
||||
mechanisms are standardized, clients and servers written according to
|
||||
this specification which make use of update functionality are
|
||||
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
|
||||
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
|
||||
|
||||
Implementors are hereby discouraged from deploying LDAPv3 clients or
|
||||
servers which implement the update functionality, until a Proposed
|
||||
Standard for mandatory authentication in LDAPv3 has been approved and
|
||||
published as an RFC.
|
||||
|
||||
Abstract
|
||||
|
||||
The X.500 Directory uses distinguished names as the primary keys to
|
||||
entries in the directory. Distinguished Names are encoded in ASN.1
|
||||
in the X.500 Directory protocols. In the Lightweight Directory
|
||||
Access Protocol, a string representation of distinguished names is
|
||||
transferred. This specification defines the string format for
|
||||
representing names, which is designed to give a clean representation
|
||||
of commonly used distinguished names, while being able to represent
|
||||
any distinguished name.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119 [6].
|
||||
|
||||
1. Background
|
||||
|
||||
This specification assumes familiarity with X.500 [1], and the
|
||||
concept of Distinguished Name. It is important to have a common
|
||||
format to be able to unambiguously represent a distinguished name.
|
||||
The primary goal of this specification is ease of encoding and
|
||||
decoding. A secondary goal is to have names that are human readable.
|
||||
It is not expected that LDAP clients with a human user interface
|
||||
would display these strings directly to the user, but would most
|
||||
likely be performing translations (such as expressing attribute type
|
||||
names in one of the local national languages).
|
||||
|
||||
2. Converting DistinguishedName from ASN.1 to a String
|
||||
|
||||
In X.501 [2] the ASN.1 structure of distinguished name is defined as:
|
||||
|
||||
DistinguishedName ::= RDNSequence
|
||||
|
||||
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 2]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
|
||||
AttributeTypeAndValue
|
||||
|
||||
AttributeTypeAndValue ::= SEQUENCE {
|
||||
type AttributeType,
|
||||
value AttributeValue }
|
||||
|
||||
The following sections define the algorithm for converting from an
|
||||
ASN.1 structured representation to a UTF-8 string representation.
|
||||
|
||||
2.1. Converting the RDNSequence
|
||||
|
||||
If the RDNSequence is an empty sequence, the result is the empty or
|
||||
zero length string.
|
||||
|
||||
Otherwise, the output consists of the string encodings of each
|
||||
RelativeDistinguishedName in the RDNSequence (according to 2.2),
|
||||
starting with the last element of the sequence and moving backwards
|
||||
toward the first.
|
||||
|
||||
The encodings of adjoining RelativeDistinguishedNames are separated
|
||||
by a comma character (',' ASCII 44).
|
||||
|
||||
2.2. Converting RelativeDistinguishedName
|
||||
|
||||
When converting from an ASN.1 RelativeDistinguishedName to a string,
|
||||
the output consists of the string encodings of each
|
||||
AttributeTypeAndValue (according to 2.3), in any order.
|
||||
|
||||
Where there is a multi-valued RDN, the outputs from adjoining
|
||||
AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
|
||||
character.
|
||||
|
||||
2.3. Converting AttributeTypeAndValue
|
||||
|
||||
The AttributeTypeAndValue is encoded as the string representation of
|
||||
the AttributeType, followed by an equals character ('=' ASCII 61),
|
||||
followed by the string representation of the AttributeValue. The
|
||||
encoding of the AttributeValue is given in section 2.4.
|
||||
|
||||
If the AttributeType is in a published table of attribute types
|
||||
associated with LDAP [4], then the type name string from that table
|
||||
is used, otherwise it is encoded as the dotted-decimal encoding of
|
||||
the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
|
||||
described in [3]. As an example, strings for a few of the attribute
|
||||
types frequently seen in RDNs include:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 3]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
String X.500 AttributeType
|
||||
------------------------------
|
||||
CN commonName
|
||||
L localityName
|
||||
ST stateOrProvinceName
|
||||
O organizationName
|
||||
OU organizationalUnitName
|
||||
C countryName
|
||||
STREET streetAddress
|
||||
DC domainComponent
|
||||
UID userid
|
||||
|
||||
2.4. Converting an AttributeValue from ASN.1 to a String
|
||||
|
||||
If the AttributeValue is of a type which does not have a string
|
||||
representation defined for it, then it is simply encoded as an
|
||||
octothorpe character ('#' ASCII 35) followed by the hexadecimal
|
||||
representation of each of the bytes of the BER encoding of the X.500
|
||||
AttributeValue. This form SHOULD be used if the AttributeType is of
|
||||
the dotted-decimal form.
|
||||
|
||||
Otherwise, if the AttributeValue is of a type which has a string
|
||||
representation, the value is converted first to a UTF-8 string
|
||||
according to its syntax specification (see for example section 6 of
|
||||
[4]).
|
||||
|
||||
If the UTF-8 string does not have any of the following characters
|
||||
which need escaping, then that string can be used as the string
|
||||
representation of the value.
|
||||
|
||||
o a space or "#" character occurring at the beginning of the
|
||||
string
|
||||
|
||||
o a space character occurring at the end of the string
|
||||
|
||||
o one of the characters ",", "+", """, "\", "<", ">" or ";"
|
||||
|
||||
Implementations MAY escape other characters.
|
||||
|
||||
If a character to be escaped is one of the list shown above, then it
|
||||
is prefixed by a backslash ('\' ASCII 92).
|
||||
|
||||
Otherwise the character to be escaped is replaced by a backslash and
|
||||
two hex digits, which form a single byte in the code of the
|
||||
character.
|
||||
|
||||
Examples of the escaping mechanism are shown in section 5.
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 4]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
3. Parsing a String back to a Distinguished Name
|
||||
|
||||
The structure of the string is specified in a BNF grammar, based on
|
||||
the grammar defined in RFC 822 [5]. Server implementations parsing a
|
||||
DN string generated by an LDAPv2 client MUST also accept (and ignore)
|
||||
the variants given in section 4 of this document.
|
||||
|
||||
distinguishedName = [name] ; may be empty string
|
||||
|
||||
name = name-component *("," name-component)
|
||||
|
||||
name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
|
||||
|
||||
attributeTypeAndValue = attributeType "=" attributeValue
|
||||
|
||||
attributeType = (ALPHA 1*keychar) / oid
|
||||
keychar = ALPHA / DIGIT / "-"
|
||||
|
||||
oid = 1*DIGIT *("." 1*DIGIT)
|
||||
|
||||
attributeValue = string
|
||||
|
||||
string = *( stringchar / pair )
|
||||
/ "#" hexstring
|
||||
/ QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
|
||||
|
||||
quotechar = <any character except "\" or QUOTATION >
|
||||
|
||||
special = "," / "=" / "+" / "<" / ">" / "#" / ";"
|
||||
|
||||
pair = "\" ( special / "\" / QUOTATION / hexpair )
|
||||
stringchar = <any character except one of special, "\" or QUOTATION >
|
||||
|
||||
hexstring = 1*hexpair
|
||||
hexpair = hexchar hexchar
|
||||
|
||||
hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
|
||||
/ "a" / "b" / "c" / "d" / "e" / "f"
|
||||
|
||||
ALPHA = <any ASCII alphabetic character>
|
||||
; (decimal 65-90 and 97-122)
|
||||
DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
|
||||
QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 5]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
4. Relationship with RFC 1779 and LDAPv2
|
||||
|
||||
The syntax given in this document is more restrictive than the syntax
|
||||
in RFC 1779. Implementations parsing a string generated by an LDAPv2
|
||||
client MUST accept the syntax of RFC 1779. Implementations MUST NOT,
|
||||
however, generate any of the RFC 1779 encodings which are not
|
||||
described above in section 2.
|
||||
|
||||
Implementations MUST allow a semicolon character to be used instead
|
||||
of a comma to separate RDNs in a distinguished name, and MUST also
|
||||
allow whitespace characters to be present on either side of the comma
|
||||
or semicolon. The whitespace characters are ignored, and the
|
||||
semicolon replaced with a comma.
|
||||
|
||||
Implementations MUST allow an oid in the attribute type to be
|
||||
prefixed by one of the character strings "oid." or "OID.".
|
||||
|
||||
Implementations MUST allow for space (' ' ASCII 32) characters to be
|
||||
present between name-component and ',', between attributeTypeAndValue
|
||||
and '+', between attributeType and '=', and between '=' and
|
||||
attributeValue. These space characters are ignored when parsing.
|
||||
|
||||
Implementations MUST allow a value to be surrounded by quote ('"'
|
||||
ASCII 34) characters, which are not part of the value. Inside the
|
||||
quoted value, the following characters can occur without any
|
||||
escaping:
|
||||
|
||||
",", "=", "+", "<", ">", "#" and ";"
|
||||
|
||||
5. Examples
|
||||
|
||||
This notation is designed to be convenient for common forms of name.
|
||||
This section gives a few examples of distinguished names written
|
||||
using this notation. First is a name containing three relative
|
||||
distinguished names (RDNs):
|
||||
|
||||
CN=Steve Kille,O=Isode Limited,C=GB
|
||||
|
||||
Here is an example name containing three RDNs, in which the first RDN
|
||||
is multi-valued:
|
||||
|
||||
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
|
||||
|
||||
This example shows the method of quoting of a comma in an
|
||||
organization name:
|
||||
|
||||
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 6]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
An example name in which a value contains a carriage return
|
||||
character:
|
||||
|
||||
CN=Before\0DAfter,O=Test,C=GB
|
||||
|
||||
An example name in which an RDN was of an unrecognized type. The
|
||||
value is the BER encoding of an OCTET STRING containing two bytes
|
||||
0x48 and 0x69.
|
||||
|
||||
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
|
||||
|
||||
Finally, an example of an RDN surname value consisting of 5 letters:
|
||||
|
||||
Unicode Letter Description 10646 code UTF-8 Quoted
|
||||
=============================== ========== ====== =======
|
||||
LATIN CAPITAL LETTER L U0000004C 0x4C L
|
||||
LATIN SMALL LETTER U U00000075 0x75 u
|
||||
LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
|
||||
LATIN SMALL LETTER I U00000069 0x69 i
|
||||
LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
|
||||
|
||||
Could be written in printable ASCII (useful for debugging purposes):
|
||||
|
||||
SN=Lu\C4\8Di\C4\87
|
||||
|
||||
6. References
|
||||
|
||||
[1] The Directory -- overview of concepts, models and services.
|
||||
ITU-T Rec. X.500(1993).
|
||||
|
||||
[2] The Directory -- Models. ITU-T Rec. X.501(1993).
|
||||
|
||||
[3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
|
||||
Access Protocol (v3)", RFC 2251, December 1997.
|
||||
|
||||
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
|
||||
Directory Access Protocol (v3): Attribute Syntax Definitions",
|
||||
RFC 2252, December 1997.
|
||||
|
||||
[5] Crocker, D., "Standard of the Format of ARPA-Internet Text
|
||||
Messages", STD 11, RFC 822, August 1982.
|
||||
|
||||
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", RFC 2119.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 7]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
7.1. Disclosure
|
||||
|
||||
Distinguished Names typically consist of descriptive information
|
||||
about the entries they name, which can be people, organizations,
|
||||
devices or other real-world objects. This frequently includes some
|
||||
of the following kinds of information:
|
||||
|
||||
- the common name of the object (i.e. a person's full name)
|
||||
- an email or TCP/IP address
|
||||
- its physical location (country, locality, city, street address)
|
||||
- organizational attributes (such as department name or affiliation)
|
||||
|
||||
Most countries have privacy laws regarding the publication of
|
||||
information about people.
|
||||
|
||||
7.2. Use of Distinguished Names in Security Applications
|
||||
|
||||
The transformations of an AttributeValue value from its X.501 form to
|
||||
an LDAP string representation are not always reversible back to the
|
||||
same BER or DER form. An example of a situation which requires the
|
||||
DER form of a distinguished name is the verification of an X.509
|
||||
certificate.
|
||||
|
||||
For example, a distinguished name consisting of one RDN with one AVA,
|
||||
in which the type is commonName and the value is of the TeletexString
|
||||
choice with the letters 'Sam' would be represented in LDAP as the
|
||||
string CN=Sam. Another distinguished name in which the value is
|
||||
still 'Sam' but of the PrintableString choice would have the same
|
||||
representation CN=Sam.
|
||||
|
||||
Applications which require the reconstruction of the DER form of the
|
||||
value SHOULD NOT use the string representation of attribute syntaxes
|
||||
when converting a distinguished name to the LDAP format. Instead,
|
||||
they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
|
||||
as described in the first paragraph of section 2.4.
|
||||
|
||||
8. Authors' Addresses
|
||||
|
||||
Mark Wahl
|
||||
Critical Angle Inc.
|
||||
4815 W. Braker Lane #502-385
|
||||
Austin, TX 78759
|
||||
USA
|
||||
|
||||
EMail: M.Wahl@critical-angle.com
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 8]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
Steve Kille
|
||||
Isode Ltd.
|
||||
The Dome
|
||||
The Square
|
||||
Richmond, Surrey
|
||||
TW9 1DT
|
||||
England
|
||||
|
||||
Phone: +44-181-332-9091
|
||||
EMail: S.Kille@ISODE.COM
|
||||
|
||||
|
||||
Tim Howes
|
||||
Netscape Communications Corp.
|
||||
501 E. Middlefield Rd, MS MV068
|
||||
Mountain View, CA 94043
|
||||
USA
|
||||
|
||||
Phone: +1 650 937-3419
|
||||
EMail: howes@netscape.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 9]
|
||||
|
||||
RFC 2253 LADPv3 Distinguished Names December 1997
|
||||
|
||||
|
||||
9. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1997). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Wahl, et. al. Proposed Standard [Page 10]
|
||||
|
||||
451
doc/rfc/rfc2254.txt
Normal file
451
doc/rfc/rfc2254.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group T. Howes
|
||||
Request for Comments: 2254 Netscape Communications Corp.
|
||||
Category: Standards Track December 1997
|
||||
|
||||
|
||||
The String Representation of LDAP Search Filters
|
||||
|
||||
1. Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1997). All Rights Reserved.
|
||||
|
||||
IESG Note
|
||||
|
||||
This document describes a directory access protocol that provides
|
||||
both read and update access. Update access requires secure
|
||||
authentication, but this document does not mandate implementation of
|
||||
any satisfactory authentication mechanisms.
|
||||
|
||||
In accordance with RFC 2026, section 4.4.1, this specification is
|
||||
being approved by IESG as a Proposed Standard despite this
|
||||
limitation, for the following reasons:
|
||||
|
||||
a. to encourage implementation and interoperability testing of
|
||||
these protocols (with or without update access) before they
|
||||
are deployed, and
|
||||
|
||||
b. to encourage deployment and use of these protocols in read-only
|
||||
applications. (e.g. applications where LDAPv3 is used as
|
||||
a query language for directories which are updated by some
|
||||
secure mechanism other than LDAP), and
|
||||
|
||||
c. to avoid delaying the advancement and deployment of other Internet
|
||||
standards-track protocols which require the ability to query, but
|
||||
not update, LDAPv3 directory servers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 1]
|
||||
|
||||
RFC 2254 String Representation of LDAP December 1997
|
||||
|
||||
|
||||
Readers are hereby warned that until mandatory authentication
|
||||
mechanisms are standardized, clients and servers written according to
|
||||
this specification which make use of update functionality are
|
||||
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
|
||||
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
|
||||
|
||||
Implementors are hereby discouraged from deploying LDAPv3 clients or
|
||||
servers which implement the update functionality, until a Proposed
|
||||
Standard for mandatory authentication in LDAPv3 has been approved and
|
||||
published as an RFC.
|
||||
|
||||
2. Abstract
|
||||
|
||||
The Lightweight Directory Access Protocol (LDAP) [1] defines a
|
||||
network representation of a search filter transmitted to an LDAP
|
||||
server. Some applications may find it useful to have a common way of
|
||||
representing these search filters in a human-readable form. This
|
||||
document defines a human-readable string format for representing LDAP
|
||||
search filters.
|
||||
|
||||
This document replaces RFC 1960, extending the string LDAP filter
|
||||
definition to include support for LDAP version 3 extended match
|
||||
filters, and including support for representing the full range of
|
||||
possible LDAP search filters.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 2]
|
||||
|
||||
RFC 2254 String Representation of LDAP December 1997
|
||||
|
||||
|
||||
3. LDAP Search Filter Definition
|
||||
|
||||
An LDAPv3 search filter is defined in Section 4.5.1 of [1] as
|
||||
follows:
|
||||
|
||||
Filter ::= CHOICE {
|
||||
and [0] SET OF Filter,
|
||||
or [1] SET OF Filter,
|
||||
not [2] Filter,
|
||||
equalityMatch [3] AttributeValueAssertion,
|
||||
substrings [4] SubstringFilter,
|
||||
greaterOrEqual [5] AttributeValueAssertion,
|
||||
lessOrEqual [6] AttributeValueAssertion,
|
||||
present [7] AttributeDescription,
|
||||
approxMatch [8] AttributeValueAssertion,
|
||||
extensibleMatch [9] MatchingRuleAssertion
|
||||
}
|
||||
|
||||
SubstringFilter ::= SEQUENCE {
|
||||
type AttributeDescription,
|
||||
SEQUENCE OF CHOICE {
|
||||
initial [0] LDAPString,
|
||||
any [1] LDAPString,
|
||||
final [2] LDAPString
|
||||
}
|
||||
}
|
||||
|
||||
AttributeValueAssertion ::= SEQUENCE {
|
||||
attributeDesc AttributeDescription,
|
||||
attributeValue AttributeValue
|
||||
}
|
||||
|
||||
MatchingRuleAssertion ::= SEQUENCE {
|
||||
matchingRule [1] MatchingRuleID OPTIONAL,
|
||||
type [2] AttributeDescription OPTIONAL,
|
||||
matchValue [3] AssertionValue,
|
||||
dnAttributes [4] BOOLEAN DEFAULT FALSE
|
||||
}
|
||||
|
||||
AttributeDescription ::= LDAPString
|
||||
|
||||
AttributeValue ::= OCTET STRING
|
||||
|
||||
MatchingRuleID ::= LDAPString
|
||||
|
||||
AssertionValue ::= OCTET STRING
|
||||
|
||||
LDAPString ::= OCTET STRING
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 3]
|
||||
|
||||
RFC 2254 String Representation of LDAP December 1997
|
||||
|
||||
|
||||
where the LDAPString above is limited to the UTF-8 encoding of the
|
||||
ISO 10646 character set [4]. The AttributeDescription is a string
|
||||
representation of the attribute description and is defined in [1].
|
||||
The AttributeValue and AssertionValue OCTET STRING have the form
|
||||
defined in [2]. The Filter is encoded for transmission over a
|
||||
network using the Basic Encoding Rules defined in [3], with
|
||||
simplifications described in [1].
|
||||
|
||||
4. String Search Filter Definition
|
||||
|
||||
The string representation of an LDAP search filter is defined by the
|
||||
following grammar, following the ABNF notation defined in [5]. The
|
||||
filter format uses a prefix notation.
|
||||
|
||||
filter = "(" filtercomp ")"
|
||||
filtercomp = and / or / not / item
|
||||
and = "&" filterlist
|
||||
or = "|" filterlist
|
||||
not = "!" filter
|
||||
filterlist = 1*filter
|
||||
item = simple / present / substring / extensible
|
||||
simple = attr filtertype value
|
||||
filtertype = equal / approx / greater / less
|
||||
equal = "="
|
||||
approx = "~="
|
||||
greater = ">="
|
||||
less = "<="
|
||||
extensible = attr [":dn"] [":" matchingrule] ":=" value
|
||||
/ [":dn"] ":" matchingrule ":=" value
|
||||
present = attr "=*"
|
||||
substring = attr "=" [initial] any [final]
|
||||
initial = value
|
||||
any = "*" *(value "*")
|
||||
final = value
|
||||
attr = AttributeDescription from Section 4.1.5 of [1]
|
||||
matchingrule = MatchingRuleId from Section 4.1.9 of [1]
|
||||
value = AttributeValue from Section 4.1.6 of [1]
|
||||
|
||||
The attr, matchingrule, and value constructs are as described in the
|
||||
corresponding section of [1] given above.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 4]
|
||||
|
||||
RFC 2254 String Representation of LDAP December 1997
|
||||
|
||||
|
||||
If a value should contain any of the following characters
|
||||
|
||||
Character ASCII value
|
||||
---------------------------
|
||||
* 0x2a
|
||||
( 0x28
|
||||
) 0x29
|
||||
\ 0x5c
|
||||
NUL 0x00
|
||||
|
||||
the character must be encoded as the backslash '\' character (ASCII
|
||||
0x5c) followed by the two hexadecimal digits representing the ASCII
|
||||
value of the encoded character. The case of the two hexadecimal
|
||||
digits is not significant.
|
||||
|
||||
This simple escaping mechanism eliminates filter-parsing ambiguities
|
||||
and allows any filter that can be represented in LDAP to be
|
||||
represented as a NUL-terminated string. Other characters besides the
|
||||
ones listed above may be escaped using this mechanism, for example,
|
||||
non-printing characters.
|
||||
|
||||
For example, the filter checking whether the "cn" attribute contained
|
||||
a value with the character "*" anywhere in it would be represented as
|
||||
"(cn=*\2a*)".
|
||||
|
||||
Note that although both the substring and present productions in the
|
||||
grammar above can produce the "attr=*" construct, this construct is
|
||||
used only to denote a presence filter.
|
||||
|
||||
5. Examples
|
||||
|
||||
This section gives a few examples of search filters written using
|
||||
this notation.
|
||||
|
||||
(cn=Babs Jensen)
|
||||
(!(cn=Tim Howes))
|
||||
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
|
||||
(o=univ*of*mich*)
|
||||
|
||||
The following examples illustrate the use of extensible matching.
|
||||
|
||||
(cn:1.2.3.4.5:=Fred Flintstone)
|
||||
(sn:dn:2.4.6.8.10:=Barney Rubble)
|
||||
(o:dn:=Ace Industry)
|
||||
(:dn:2.4.6.8.10:=Dino)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 5]
|
||||
|
||||
RFC 2254 String Representation of LDAP December 1997
|
||||
|
||||
|
||||
The second example illustrates the use of the ":dn" notation to
|
||||
indicate that matching rule "2.4.6.8.10" should be used when making
|
||||
comparisons, and that the attributes of an entry's distinguished name
|
||||
should be considered part of the entry when evaluating the match.
|
||||
|
||||
The third example denotes an equality match, except that DN
|
||||
components should be considered part of the entry when doing the
|
||||
match.
|
||||
|
||||
The fourth example is a filter that should be applied to any
|
||||
attribute supporting the matching rule given (since the attr has been
|
||||
left off). Attributes supporting the matching rule contained in the
|
||||
DN should also be considered.
|
||||
|
||||
The following examples illustrate the use of the escaping mechanism.
|
||||
|
||||
(o=Parens R Us \28for all your parenthetical needs\29)
|
||||
(cn=*\2A*)
|
||||
(filename=C:\5cMyFile)
|
||||
(bin=\00\00\00\04)
|
||||
(sn=Lu\c4\8di\c4\87)
|
||||
|
||||
The first example shows the use of the escaping mechanism to
|
||||
represent parenthesis characters. The second shows how to represent a
|
||||
"*" in a value, preventing it from being interpreted as a substring
|
||||
indicator. The third illustrates the escaping of the backslash
|
||||
character.
|
||||
|
||||
The fourth example shows a filter searching for the four-byte value
|
||||
0x00000004, illustrating the use of the escaping mechanism to
|
||||
represent arbitrary data, including NUL characters.
|
||||
|
||||
The final example illustrates the use of the escaping mechanism to
|
||||
represent various non-ASCII UTF-8 characters.
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
This memo describes a string representation of LDAP search filters.
|
||||
While the representation itself has no known security implications,
|
||||
LDAP search filters do. They are interpreted by LDAP servers to
|
||||
select entries from which data is retrieved. LDAP servers should
|
||||
take care to protect the data they maintain from unauthorized access.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 6]
|
||||
|
||||
RFC 2254 String Representation of LDAP December 1997
|
||||
|
||||
|
||||
7. References
|
||||
|
||||
[1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
|
||||
Protocol (v3)", RFC 2251, December 1997.
|
||||
|
||||
[2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
|
||||
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
|
||||
2252, December 1997.
|
||||
|
||||
[3] Specification of ASN.1 encoding rules: Basic, Canonical, and
|
||||
Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
|
||||
|
||||
[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
|
||||
10646", RFC 2044, October 1996.
|
||||
|
||||
[5] Crocker, D., "Standard for the Format of ARPA Internet Text
|
||||
Messages", STD 11, RFC 822, August 1982.
|
||||
|
||||
8. Author's Address
|
||||
|
||||
Tim Howes
|
||||
Netscape Communications Corp.
|
||||
501 E. Middlefield Road
|
||||
Mountain View, CA 94043
|
||||
USA
|
||||
|
||||
Phone: +1 415 937-3419
|
||||
EMail: howes@netscape.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 7]
|
||||
|
||||
RFC 2254 String Representation of LDAP December 1997
|
||||
|
||||
|
||||
9. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1997). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes Standards Track [Page 8]
|
||||
|
||||
563
doc/rfc/rfc2255.txt
Normal file
563
doc/rfc/rfc2255.txt
Normal file
@ -0,0 +1,563 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group T. Howes
|
||||
Request for Comments: 2255 M. Smith
|
||||
Category: Standards Track Netscape Communications Corp.
|
||||
December 1997
|
||||
|
||||
|
||||
The LDAP URL Format
|
||||
|
||||
1. Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1997). All Rights Reserved.
|
||||
|
||||
IESG NOTE
|
||||
|
||||
This document describes a directory access protocol that provides
|
||||
both read and update access. Update access requires secure
|
||||
authentication, but this document does not mandate implementation of
|
||||
any satisfactory authentication mechanisms.
|
||||
|
||||
In accordance with RFC 2026, section 4.4.1, this specification is
|
||||
being approved by IESG as a Proposed Standard despite this
|
||||
limitation, for the following reasons:
|
||||
|
||||
a. to encourage implementation and interoperability testing of
|
||||
these protocols (with or without update access) before they
|
||||
are deployed, and
|
||||
|
||||
b. to encourage deployment and use of these protocols in read-only
|
||||
applications. (e.g. applications where LDAPv3 is used as
|
||||
a query language for directories which are updated by some
|
||||
secure mechanism other than LDAP), and
|
||||
|
||||
c. to avoid delaying the advancement and deployment of other Internet
|
||||
standards-track protocols which require the ability to query, but
|
||||
not update, LDAPv3 directory servers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 1]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
Readers are hereby warned that until mandatory authentication
|
||||
mechanisms are standardized, clients and servers written according to
|
||||
this specification which make use of update functionality are
|
||||
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
|
||||
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
|
||||
|
||||
Implementors are hereby discouraged from deploying LDAPv3 clients or
|
||||
servers which implement the update functionality, until a Proposed
|
||||
Standard for mandatory authentication in LDAPv3 has been approved and
|
||||
published as an RFC.
|
||||
|
||||
2. Abstract
|
||||
|
||||
LDAP is the Lightweight Directory Access Protocol, defined in [1],
|
||||
[2] and [3]. This document describes a format for an LDAP Uniform
|
||||
Resource Locator. The format describes an LDAP search operation to
|
||||
perform to retrieve information from an LDAP directory. This document
|
||||
replaces RFC 1959. It updates the LDAP URL format for version 3 of
|
||||
LDAP and clarifies how LDAP URLs are resolved. This document also
|
||||
defines an extension mechanism for LDAP URLs, so that future
|
||||
documents can extend their functionality, for example, to provide
|
||||
access to new LDAPv3 extensions as they are defined.
|
||||
|
||||
The key words "MUST", "MAY", and "SHOULD" used in this document are
|
||||
to be interpreted as described in [6].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 2]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
3. URL Definition
|
||||
|
||||
An LDAP URL begins with the protocol prefix "ldap" and is defined by
|
||||
the following grammar.
|
||||
|
||||
ldapurl = scheme "://" [hostport] ["/"
|
||||
[dn ["?" [attributes] ["?" [scope]
|
||||
["?" [filter] ["?" extensions]]]]]]
|
||||
scheme = "ldap"
|
||||
attributes = attrdesc *("," attrdesc)
|
||||
scope = "base" / "one" / "sub"
|
||||
dn = distinguishedName from Section 3 of [1]
|
||||
hostport = hostport from Section 5 of RFC 1738 [5]
|
||||
attrdesc = AttributeDescription from Section 4.1.5 of [2]
|
||||
filter = filter from Section 4 of [4]
|
||||
extensions = extension *("," extension)
|
||||
extension = ["!"] extype ["=" exvalue]
|
||||
extype = token / xtoken
|
||||
exvalue = LDAPString from section 4.1.2 of [2]
|
||||
token = oid from section 4.1 of [3]
|
||||
xtoken = ("X-" / "x-") token
|
||||
|
||||
The "ldap" prefix indicates an entry or entries residing in the LDAP
|
||||
server running on the given hostname at the given portnumber. The
|
||||
default LDAP port is TCP port 389. If no hostport is given, the
|
||||
client must have some apriori knowledge of an appropriate LDAP server
|
||||
to contact.
|
||||
|
||||
The dn is an LDAP Distinguished Name using the string format
|
||||
described in [1]. It identifies the base object of the LDAP search.
|
||||
|
||||
ldapurl = scheme "://" [hostport] ["/"
|
||||
[dn ["?" [attributes] ["?" [scope]
|
||||
["?" [filter] ["?" extensions]]]]]]
|
||||
scheme = "ldap"
|
||||
attributes = attrdesc *("," attrdesc)
|
||||
scope = "base" / "one" / "sub"
|
||||
dn = distinguishedName from Section 3 of [1]
|
||||
hostport = hostport from Section 5 of RFC 1738 [5]
|
||||
attrdesc = AttributeDescription from Section 4.1.5 of [2]
|
||||
filter = filter from Section 4 of [4]
|
||||
extensions = extension *("," extension)
|
||||
extension = ["!"] extype ["=" exvalue]
|
||||
extype = token / xtoken
|
||||
exvalue = LDAPString from section 4.1.2 of [2]
|
||||
token = oid from section 4.1 of [3]
|
||||
xtoken = ("X-" / "x-") token
|
||||
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 3]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
The "ldap" prefix indicates an entry or entries residing in the LDAP
|
||||
server running on the given hostname at the given portnumber. The
|
||||
default LDAP port is TCP port 389. If no hostport is given, the
|
||||
client must have some apriori knowledge of an appropriate LDAP server
|
||||
to contact.
|
||||
|
||||
The dn is an LDAP Distinguished Name using the string format
|
||||
described in [1]. It identifies the base object of the LDAP search.
|
||||
|
||||
The attributes construct is used to indicate which attributes should
|
||||
be returned from the entry or entries. Individual attrdesc names are
|
||||
as defined for AttributeDescription in [2]. If the attributes part
|
||||
is omitted, all user attributes of the entry or entries should be
|
||||
requested (e.g., by setting the attributes field
|
||||
AttributeDescriptionList in the LDAP search request to a NULL list,
|
||||
or (in LDAPv3) by requesting the special attribute name "*").
|
||||
|
||||
The scope construct is used to specify the scope of the search to
|
||||
perform in the given LDAP server. The allowable scopes are "base"
|
||||
for a base object search, "one" for a one-level search, or "sub" for
|
||||
a subtree search. If scope is omitted, a scope of "base" is assumed.
|
||||
|
||||
The filter is used to specify the search filter to apply to entries
|
||||
within the specified scope during the search. It has the format
|
||||
specified in [4]. If filter is omitted, a filter of
|
||||
"(objectClass=*)" is assumed.
|
||||
|
||||
The extensions construct provides the LDAP URL with an extensibility
|
||||
mechanism, allowing the capabilities of the URL to be extended in the
|
||||
future. Extensions are a simple comma-separated list of type=value
|
||||
pairs, where the =value portion MAY be omitted for options not
|
||||
requiring it. Each type=value pair is a separate extension. These
|
||||
LDAP URL extensions are not necessarily related to any of the LDAPv3
|
||||
extension mechanisms. Extensions may be supported or unsupported by
|
||||
the client resolving the URL. An extension prefixed with a '!'
|
||||
character (ASCII 33) is critical. An extension not prefixed with a '
|
||||
!' character is non-critical.
|
||||
|
||||
If an extension is supported by the client, the client MUST obey the
|
||||
extension if the extension is critical. The client SHOULD obey
|
||||
supported extensions that are non-critical.
|
||||
|
||||
If an extension is unsupported by the client, the client MUST NOT
|
||||
process the URL if the extension is critical. If an unsupported
|
||||
extension is non-critical, the client MUST ignore the extension.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 4]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
If a critical extension cannot be processed successfully by the
|
||||
client, the client MUST NOT process the URL. If a non-critical
|
||||
extension cannot be processed successfully by the client, the client
|
||||
SHOULD ignore the extension.
|
||||
|
||||
Extension types prefixed by "X-" or "x-" are reserved for use in
|
||||
bilateral agreements between communicating parties. Other extension
|
||||
types MUST be defined in this document, or in other standards-track
|
||||
documents.
|
||||
|
||||
One LDAP URL extension is defined in this document in the next
|
||||
section. Other documents or a future version of this document MAY
|
||||
define other extensions.
|
||||
|
||||
Note that any URL-illegal characters (e.g., spaces), URL special
|
||||
characters (as defined in section 2.2 of RFC 1738) and the reserved
|
||||
character '?' (ASCII 63) occurring inside a dn, filter, or other
|
||||
element of an LDAP URL MUST be escaped using the % method described
|
||||
in RFC 1738 [5]. If a comma character ',' occurs inside an extension
|
||||
value, the character MUST also be escaped using the % method.
|
||||
|
||||
4. The Bindname Extension
|
||||
|
||||
This section defines an LDAP URL extension for representing the
|
||||
distinguished name for a client to use when authenticating to an LDAP
|
||||
directory during resolution of an LDAP URL. Clients MAY implement
|
||||
this extension.
|
||||
|
||||
The extension type is "bindname". The extension value is the
|
||||
distinguished name of the directory entry to authenticate as, in the
|
||||
same form as described for dn in the grammar above. The dn may be the
|
||||
NULL string to specify unauthenticated access. The extension may be
|
||||
either critical (prefixed with a '!' character) or non-critical (not
|
||||
prefixed with a '!' character).
|
||||
|
||||
If the bindname extension is critical, the client resolving the URL
|
||||
MUST authenticate to the directory using the given distinguished name
|
||||
and an appropriate authentication method. Note that for a NULL
|
||||
distinguished name, no bind MAY be required to obtain anonymous
|
||||
access to the directory. If the extension is non-critical, the client
|
||||
MAY bind to the directory using the given distinguished name.
|
||||
|
||||
5. URL Processing
|
||||
|
||||
This section describes how an LDAP URL SHOULD be resolved by a
|
||||
client.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 5]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
First, the client obtains a connection to the LDAP server referenced
|
||||
in the URL, or an LDAP server of the client's choice if no LDAP
|
||||
server is explicitly referenced. This connection MAY be opened
|
||||
specifically for the purpose of resolving the URL or the client MAY
|
||||
reuse an already open connection. The connection MAY provide
|
||||
confidentiality, integrity, or other services, e.g., using TLS. Use
|
||||
of security services is at the client's discretion if not specified
|
||||
in the URL.
|
||||
|
||||
Next, the client authenticates itself to the LDAP server. This step
|
||||
is optional, unless the URL contains a critical bindname extension
|
||||
with a non-NULL value. If a bindname extension is given, the client
|
||||
proceeds according to the section above.
|
||||
|
||||
If a bindname extension is not specified, the client MAY bind to the
|
||||
directory using a appropriate dn and authentication method of its own
|
||||
choosing (including NULL authentication).
|
||||
|
||||
Next, the client performs the LDAP search operation specified in the
|
||||
URL. Additional fields in the LDAP protocol search request, such as
|
||||
sizelimit, timelimit, deref, and anything else not specified or
|
||||
defaulted in the URL specification, MAY be set at the client's
|
||||
discretion.
|
||||
|
||||
Once the search has completed, the client MAY close the connection to
|
||||
the LDAP server, or the client MAY keep the connection open for
|
||||
future use.
|
||||
|
||||
6. Examples
|
||||
|
||||
The following are some example LDAP URLs using the format defined
|
||||
above. The first example is an LDAP URL referring to the University
|
||||
of Michigan entry, available from an LDAP server of the client's
|
||||
choosing:
|
||||
|
||||
ldap:///o=University%20of%20Michigan,c=US
|
||||
|
||||
The next example is an LDAP URL referring to the University of
|
||||
Michigan entry in a particular ldap server:
|
||||
|
||||
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
|
||||
|
||||
Both of these URLs correspond to a base object search of the
|
||||
"o=University of Michigan, c=US" entry using a filter of
|
||||
"(objectclass=*)", requesting all attributes.
|
||||
|
||||
The next example is an LDAP URL referring to only the postalAddress
|
||||
attribute of the University of Michigan entry:
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 6]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,
|
||||
c=US?postalAddress
|
||||
|
||||
The corresponding LDAP search operation is the same as in the
|
||||
previous example, except that only the postalAddress attribute is
|
||||
requested.
|
||||
|
||||
The next example is an LDAP URL referring to the set of entries found
|
||||
by querying the given LDAP server on port 6666 and doing a subtree
|
||||
search of the University of Michigan for any entry with a common name
|
||||
of "Babs Jensen", retrieving all attributes:
|
||||
|
||||
ldap://host.com:6666/o=University%20of%20Michigan,
|
||||
c=US??sub?(cn=Babs%20Jensen)
|
||||
|
||||
The next example is an LDAP URL referring to all children of the c=GB
|
||||
entry:
|
||||
|
||||
ldap://ldap.itd.umich.edu/c=GB?objectClass?one
|
||||
|
||||
The objectClass attribute is requested to be returned along with the
|
||||
entries, and the default filter of "(objectclass=*)" is used.
|
||||
|
||||
The next example is an LDAP URL to retrieve the mail attribute for
|
||||
the LDAP entry named "o=Question?,c=US" is given below, illustrating
|
||||
the use of the escaping mechanism on the reserved character '?'.
|
||||
|
||||
ldap://ldap.question.com/o=Question%3f,c=US?mail
|
||||
|
||||
The next example illustrates the interaction between LDAP and URL
|
||||
quoting mechanisms.
|
||||
|
||||
ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)
|
||||
|
||||
The filter in this example uses the LDAP escaping mechanism of \ to
|
||||
encode three zero or null bytes in the value. In LDAP, the filter
|
||||
would be written as (int=\00\00\00\04). Because the \ character must
|
||||
be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
|
||||
|
||||
The final example shows the use of the bindname extension to specify
|
||||
the dn a client should use for authentication when resolving the URL.
|
||||
|
||||
ldap:///??sub??bindname=cn=Manager%2co=Foo
|
||||
ldap:///??sub??!bindname=cn=Manager%2co=Foo
|
||||
|
||||
The two URLs are the same, except that the second one marks the
|
||||
bindname extension as critical. Notice the use of the % encoding
|
||||
method to encode the comma in the distinguished name value in the
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 7]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
bindname extension.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
General URL security considerations discussed in [5] are relevant for
|
||||
LDAP URLs.
|
||||
|
||||
The use of security mechanisms when processing LDAP URLs requires
|
||||
particular care, since clients may encounter many different servers
|
||||
via URLs, and since URLs are likely to be processed automatically,
|
||||
without user intervention. A client SHOULD have a user-configurable
|
||||
policy about which servers to connect to using which security
|
||||
mechanisms, and SHOULD NOT make connections that are inconsistent
|
||||
with this policy.
|
||||
|
||||
Sending authentication information, no matter the mechanism, may
|
||||
violate a user's privacy requirements. In the absence of specific
|
||||
policy permitting authentication information to be sent to a server,
|
||||
a client should use an anonymous connection. (Note that clients
|
||||
conforming to previous LDAP URL specifications, where all connections
|
||||
are anonymous and unprotected, are consistent with this
|
||||
specification; they simply have the default security policy.)
|
||||
|
||||
Some authentication methods, in particular reusable passwords sent to
|
||||
the server, may reveal easily-abused information to the remote server
|
||||
or to eavesdroppers in transit, and should not be used in URL
|
||||
processing unless explicitly permitted by policy. Confirmation by
|
||||
the human user of the use of authentication information is
|
||||
appropriate in many circumstances. Use of strong authentication
|
||||
methods that do not reveal sensitive information is much preferred.
|
||||
|
||||
The LDAP URL format allows the specification of an arbitrary LDAP
|
||||
search operation to be performed when evaluating the LDAP URL.
|
||||
Following an LDAP URL may cause unexpected results, for example, the
|
||||
retrieval of large amounts of data, the initiation of a long-lived
|
||||
search, etc. The security implications of resolving an LDAP URL are
|
||||
the same as those of resolving an LDAP search query.
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
The LDAP URL format was originally defined at the University of
|
||||
Michigan. This material is based upon work supported by the National
|
||||
Science Foundation under Grant No. NCR-9416667. The support of both
|
||||
the University of Michigan and the National Science Foundation is
|
||||
gratefully acknowledged.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 8]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
Several people have made valuable comments on this document. In
|
||||
particular RL "Bob" Morgan and Mark Wahl deserve special thanks for
|
||||
their contributions.
|
||||
|
||||
9. References
|
||||
|
||||
[1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
|
||||
Protocol (v3): UTF-8 String Representation of Distinguished Names",
|
||||
RFC 2253, December 1997.
|
||||
|
||||
[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
|
||||
Protocol (v3)", RFC 2251, December 1997.
|
||||
|
||||
[3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
|
||||
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
|
||||
2252, December 1997.
|
||||
|
||||
[4] Howes, T., "A String Representation of LDAP Search Filters", RFC
|
||||
2254, December 1997.
|
||||
|
||||
[5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
|
||||
Locators (URL)," RFC 1738, December 1994.
|
||||
|
||||
[6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
|
||||
Levels," RFC 2119, March 1997.
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Tim Howes
|
||||
Netscape Communications Corp.
|
||||
501 E. Middlefield Rd.
|
||||
Mountain View, CA 94043
|
||||
USA
|
||||
|
||||
Phone: +1 415 937-3419
|
||||
EMail: howes@netscape.com
|
||||
|
||||
|
||||
Mark Smith
|
||||
Netscape Communications Corp.
|
||||
501 E. Middlefield Rd.
|
||||
Mountain View, CA 94043
|
||||
USA
|
||||
|
||||
Phone: +1 415 937-3477
|
||||
EMail: mcs@netscape.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 9]
|
||||
|
||||
RFC 2255 LDAP URL Format December 1997
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1997). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Howes & Smith Standards Track [Page 10]
|
||||
|
||||
1123
doc/rfc/rfc2256.txt
Normal file
1123
doc/rfc/rfc2256.txt
Normal file
File diff suppressed because it is too large
Load Diff
451
doc/rfc/rfc2293.txt
Normal file
451
doc/rfc/rfc2293.txt
Normal file
@ -0,0 +1,451 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Kille
|
||||
Request for Comments: 2293 Isode Ltd.
|
||||
Obsoletes: 1837 March 1998
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Representing Tables and Subtrees in the X.500 Directory
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines techniques for representing two types of
|
||||
information mapping in the OSI Directory [1].
|
||||
|
||||
1. Mapping from a key to a value (or set of values), as might
|
||||
be done in a table lookup.
|
||||
|
||||
2. Mapping from a distinguished name to an associated
|
||||
value (or values), where the values are not defined by the owner
|
||||
of the entry. This is achieved by use of a directory subtree.
|
||||
|
||||
These techniques were developed for supporting MHS use of Directory
|
||||
[2], but are specified separately as they have more general
|
||||
applicability.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 1]
|
||||
|
||||
RFC 2293 Table and Subtrees in the X.500 March 1998
|
||||
|
||||
|
||||
1 Representing Flat Tables
|
||||
|
||||
Before considering specific function, a general purpose technique for
|
||||
representing tables in the directory is introduced. The schema for
|
||||
this is given in Figure 1. A table can be considered as an unordered
|
||||
set of key to (single or multiple) value mappings, where the key
|
||||
cannot be represented as a global name. There are four reasons why
|
||||
this may occur:
|
||||
|
||||
1. The object does not have a natural global name.
|
||||
|
||||
2. The object can only be named effectively in the context of
|
||||
being a key to a binding. In this case, the object will be given
|
||||
a natural global name by the table.
|
||||
|
||||
3. The object has a global name, and the table is being used
|
||||
to associate parameters with this object, in cases where they
|
||||
cannot be placed in the objects global entry. Reasons why they
|
||||
might not be so placed include:
|
||||
|
||||
o The object does not have a directory entry
|
||||
|
||||
o There is no authority to place the parameters in the
|
||||
global entry
|
||||
|
||||
o The parameters are not global --- they only make sense
|
||||
in the context of the table.
|
||||
|
||||
4. It is desirable to group information together as a
|
||||
performance optimization, so that the block of information may be
|
||||
widely replicated.
|
||||
|
||||
A table is represented as a single level subtree. The root of the
|
||||
subtree is an entry of object class Table. This is named with a
|
||||
common name descriptive of the table. The table will be located
|
||||
somewhere appropriate to its function. If a table is private to an
|
||||
MTA, it will be below the MTA's entry. If it is shared by MTA's in
|
||||
an organization, it will be located under the organization.
|
||||
|
||||
The generic table entry contains only a description. All instances
|
||||
will be subclassed, and the subclass will define the naming
|
||||
attribute. Two subclasses are defined:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 2]
|
||||
|
||||
RFC 2293 Table and Subtrees in the X.500 March 1998
|
||||
|
||||
|
||||
table OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {commonName}
|
||||
MAY CONTAIN {manager}
|
||||
ID oc-table}
|
||||
|
||||
|
||||
tableEntry OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MAY CONTAIN {description} 10
|
||||
ID oc-table-entry}
|
||||
|
||||
textTableEntry OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {tableEntry}
|
||||
MUST CONTAIN {textTableKey}
|
||||
MAY CONTAIN {textTableValue}
|
||||
ID oc-text-table-entry}
|
||||
|
||||
textTableKey ATTRIBUTE ::= {
|
||||
SUBTYPE OF name 20
|
||||
WITH SYNTAX DirectoryString {ub-name}
|
||||
ID at-text-table-key}
|
||||
|
||||
textTableValue ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX DirectoryString {ub-description}
|
||||
ID at-text-table-value}
|
||||
|
||||
distinguishedNameTableEntry OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {tableEntry} 30
|
||||
MUST CONTAIN {distinguishedNameTableKey}
|
||||
ID oc-distinguished-name-table-entry}
|
||||
|
||||
distinguishedNameTableKey ATTRIBUTE ::= {
|
||||
SUBTYPE OF distinguishedName
|
||||
ID at-distinguished-name-table-key}
|
||||
|
||||
Figure 1: Representing Tables
|
||||
|
||||
|
||||
1. TextEntry, which define table entries with text keys,
|
||||
which may have single or multiple values of any type. An
|
||||
attribute is defined to allow a text value, to support the
|
||||
frequent text key to text value mapping. Additional values may
|
||||
be defined.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 3]
|
||||
|
||||
RFC 2293 Table and Subtrees in the X.500 March 1998
|
||||
|
||||
|
||||
2. DistinguishedNameEntry. This is used for associating
|
||||
information with globally defined objects. This approach should
|
||||
be used where the number of objects in the table is small or very
|
||||
sparsely spread over the DIT. In other cases where there are many
|
||||
objects or the objects are tightly clustered in the DIT, the
|
||||
subtree approach defined in Section 2 will be preferable. No
|
||||
value attributes are defined for this type of entry. An
|
||||
application of this will make appropriate subtyping to define the
|
||||
needed values.
|
||||
|
||||
This is best illustrated by example. Consider the MTA:
|
||||
|
||||
CN=Bells, OU=Computer Science,
|
||||
O=University College London, C=GB
|
||||
|
||||
Suppose that the MTA needs a table mapping from private keys to fully
|
||||
qualified domain names (this example is fictitious). The table might
|
||||
be named as:
|
||||
|
||||
CN=domain-nicknames,
|
||||
CN=Bells, OU=Computer Science,
|
||||
O=University College London, C=GB
|
||||
|
||||
To represent a mapping in this table from "euclid" to
|
||||
"bloomsbury.ac.uk", the entry:
|
||||
|
||||
TextTableKey=euclid, CN=domain-nicknames,
|
||||
CN=Bells, OU=Computer Science,
|
||||
O=University College London, C=GB
|
||||
|
||||
will contain the attribute:
|
||||
|
||||
TextTableValue=bloomsbury.ac.uk
|
||||
|
||||
A second example, showing the use of DistinguishedNameEntry is now
|
||||
given. Consider again the MTA:
|
||||
|
||||
CN=Bells, OU=Computer Science,
|
||||
O=University College London, C=GB
|
||||
|
||||
Suppose that the MTA needs a table mapping from MTA Name to bilateral
|
||||
agreement information of that MTA. The table might be named as:
|
||||
|
||||
CN=MTA Bilateral Agreements,
|
||||
CN=Bells, OU=Computer Science,
|
||||
O=University College London, C=GB
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 4]
|
||||
|
||||
RFC 2293 Table and Subtrees in the X.500 March 1998
|
||||
|
||||
|
||||
To represent information on the MTA which has the Distinguished Name:
|
||||
|
||||
CN=Q3T21, ADMD=Gold 400, C=GB
|
||||
|
||||
There would be an entry in this table with the Relative Distinguished
|
||||
Name of the table entry being the Distinguished Name of the MTA being
|
||||
referred to. The MTA Bilateral information would be an attribute in
|
||||
this entry. Using a non-standard notation, the Distinguished Name of
|
||||
the table entry is:
|
||||
|
||||
DistinguishedNameTableKey=<CN=Q3T21, ADMD=Gold 400, C=GB>,
|
||||
CN=MTA Bilateral Agreements,
|
||||
CN=Bells, OU=Computer Science,
|
||||
O=University College London, C=GB
|
||||
|
||||
2 Representing Subtrees
|
||||
|
||||
A subtree is similar to a table, except that the keys are constructed
|
||||
as a distinguished name hierarchy relative to the location of the
|
||||
subtree in the DIT. The subtree effectively starts a private "root",
|
||||
and has distinguished names relative to this root. Typically, this
|
||||
approach is used to associate local information with global objects.
|
||||
The schema used is defined in Figure 2. Functionally, this is
|
||||
equivalent to a table with distinguished name keys. The table
|
||||
approach is best when the tree is very sparse. This approach is
|
||||
better for subtrees which are more populated.
|
||||
|
||||
The subtree object class defines the root for a subtree in an
|
||||
analogous means to the table. Information within the subtree will
|
||||
generally be defined in the same way as for the global object, and so
|
||||
|
||||
subtree OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {commonName}
|
||||
MAY CONTAIN {manager}
|
||||
ID oc-subtree}
|
||||
|
||||
Figure 2: Representing Subtrees
|
||||
|
||||
|
||||
no specific object classes for subtree entries are needed.
|
||||
|
||||
For example consider University College London.
|
||||
|
||||
O=University College London, C=GB
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 5]
|
||||
|
||||
RFC 2293 Table and Subtrees in the X.500 March 1998
|
||||
|
||||
|
||||
Suppose that the UCL needs a private subtree, with interesting
|
||||
information about directory objects. The table might be named as:
|
||||
|
||||
CN=private subtree,
|
||||
O=University College London, C=GB
|
||||
|
||||
UCL specific information on Inria might be stored in the entry:
|
||||
|
||||
O=Inria, C=FR,
|
||||
CN=private subtree,
|
||||
O=University College London, C=GB
|
||||
|
||||
Practical examples of this mapping are given in [2].
|
||||
|
||||
3 Acknowledgments
|
||||
|
||||
Acknowledgments for work on this document are given in [2].
|
||||
|
||||
References
|
||||
|
||||
[1] The Directory --- overview of concepts, models and services,
|
||||
1993. CCITT X.500 Series Recommendations.
|
||||
|
||||
[2] Kille, S.E., "X.400-MHS use of the X.500 directory to support
|
||||
X.400-MHS routing," RFC 1801, June 1995.
|
||||
|
||||
4 Security Considerations
|
||||
|
||||
Security considerations are not discussed in this memo.
|
||||
|
||||
5 Author's Address
|
||||
|
||||
Steve Kille
|
||||
Isode Ltd
|
||||
The Dome
|
||||
The Square
|
||||
Richmond
|
||||
TW9 1DT
|
||||
England
|
||||
|
||||
Phone: +44-181-332-9091
|
||||
EMail: S.Kille@ISODE.COM
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 6]
|
||||
|
||||
RFC 2293 Table and Subtrees in the X.500 March 1998
|
||||
|
||||
|
||||
A Object Identifier Assignment
|
||||
|
||||
|
||||
mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
|
||||
private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}
|
||||
|
||||
tables OBJECT IDENTIFIER ::= {mhs-ds 1}
|
||||
|
||||
oc OBJECT IDENTIFIER ::= {tables 1}
|
||||
at OBJECT IDENTIFIER ::= {tables 2}
|
||||
|
||||
oc-subtree OBJECT IDENTIFIER ::= {oc 1}
|
||||
oc-table OBJECT IDENTIFIER ::= {oc 2} 10
|
||||
oc-table-entry OBJECT IDENTIFIER ::= {oc 3}
|
||||
oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4}
|
||||
oc-distinguished-name-table-entry OBJECT IDENTIFIER ::= {oc 5}
|
||||
|
||||
at-text-table-key OBJECT IDENTIFIER ::= {at 1}
|
||||
at-text-table-value OBJECT IDENTIFIER ::= {at 2}
|
||||
at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3}
|
||||
|
||||
Figure 3: Object Identifier Assignment
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 7]
|
||||
|
||||
RFC 2293 Table and Subtrees in the X.500 March 1998
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 8]
|
||||
|
||||
731
doc/rfc/rfc2294.txt
Normal file
731
doc/rfc/rfc2294.txt
Normal file
@ -0,0 +1,731 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Kille
|
||||
Request for Comments: 2294 Isode Ltd.
|
||||
Obsoletes: 1836 March 1998
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Representing the O/R Address hierarchy in the
|
||||
X.500 Directory Information Tree
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines a representation of the O/R Address hierarchy
|
||||
in the Directory Information Tree [6, 1]. This is useful for a range
|
||||
of purposes, including:
|
||||
|
||||
o Support for MHS Routing [4].
|
||||
|
||||
o Support for X.400/RFC 822 address mappings [2, 5].
|
||||
|
||||
Please send comments to the author or to the discussion group <mhs-
|
||||
ds@mercury.udev.cdc.com>.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 1]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
Object Class Mandatory
|
||||
------------ ---------
|
||||
mHSCountry M
|
||||
aDMD M
|
||||
pRMD O
|
||||
mHSX121 O
|
||||
mHSNumericUserIdentifier O
|
||||
mHSOrganization O
|
||||
mHSOrganizationalUnit O
|
||||
mHSPerson O
|
||||
mHSNamedObject O
|
||||
mHSTerminalID O
|
||||
mHSDomainDefinedAttribute O
|
||||
|
||||
Table 1: Order of O/R Address Directory Components
|
||||
|
||||
1 The O/R Address Hierarchy
|
||||
|
||||
An O/R Address hierarchy is represented in the X.500 directory by
|
||||
associating directory name components with O/R Address components.
|
||||
An example of this is given in Figure 1. The object classes and
|
||||
attributes required to support this representation are defined in
|
||||
Figure 2. The schema, which defines the hierarchy in which these
|
||||
objects are represented in the directory information tree is
|
||||
specified in Table 1. A given object class defined in the table will
|
||||
always be higher in the DIT than an object class defined lower down
|
||||
the table. Valid combinations of O/R Address components are defined
|
||||
in X.400.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 2]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
/\
|
||||
/ \
|
||||
C=GB / \ Numeric-C=234
|
||||
/ \
|
||||
/ \
|
||||
/ \
|
||||
+------------+<----------------+----+
|
||||
| Country | | |
|
||||
+------------+ +----+
|
||||
/\
|
||||
/ \
|
||||
/ \
|
||||
/ \
|
||||
ADMD=" " / \ ADMD=Gold 400
|
||||
+-------------+ +------------+
|
||||
| ADMD | | ADMD |
|
||||
+-------------+ +------------+
|
||||
\ \
|
||||
\ \
|
||||
\ PRMD=UK.AC \ PRMD=UK.AC
|
||||
\ \
|
||||
+----------+ +----+
|
||||
| PRMD |< -----------| |
|
||||
+----------+ +----+
|
||||
/
|
||||
/
|
||||
O=UCL
|
||||
/
|
||||
/
|
||||
+------------+
|
||||
| MHS-Org |
|
||||
+------------+
|
||||
\
|
||||
\ OU=CS
|
||||
\
|
||||
\
|
||||
+-----------+
|
||||
| MHS-OU |
|
||||
+-----------+
|
||||
|
||||
|
||||
Figure 1: Example O/R Address Tree
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 3]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
IMPORTS
|
||||
ub-domain-name-length, ub-organization-name-length,
|
||||
ub-organizational-unit-name-length, ub-common-name-length,
|
||||
ub-x121-address-length, ub-domain-defined-attribute-type-length,
|
||||
ub-domain-defined-attribute-value-length, ub-terminal-id-length,
|
||||
ub-numeric-user-id-length, ub-country-name-numeric-length,
|
||||
ub-surname-length, ub-given-name-length, ub-initials-length,
|
||||
ub-generation-qualifier-length
|
||||
|
||||
FROM MTSUpperBounds {joint-iso-ccitt mhs-motis(6) mts(3) 10
|
||||
modules(0) upper-bounds(3) };
|
||||
|
||||
mHSCountry OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {country}
|
||||
MAY CONTAIN {mHSNumericCountryName}
|
||||
ID oc-mhs-country}
|
||||
|
||||
mHSNumericCountryName ATTRIBUTE ::= {
|
||||
WITH SYNTAX NumericString (SIZE (1..ub-country-name-numeric-length))
|
||||
SINGLE VALUE 20
|
||||
ID at-mhs-numeric-country-name}
|
||||
|
||||
aDMD OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {aDMDName}
|
||||
ID oc-admd}
|
||||
|
||||
aDMDName ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX DirectoryString {ub-domain-name-length} 30
|
||||
ID at-admd-name}
|
||||
|
||||
pRMD OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {pRMDName}
|
||||
ID oc-prmd}
|
||||
|
||||
pRMDName ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX DirectoryString {ub-domain-name-length} 40
|
||||
ID at-prmd-name}
|
||||
|
||||
mHSOrganization OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {mHSOrganizationName }
|
||||
ID oc-mhs-organization}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 4]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
mHSOrganizationName ATTRIBUTE ::= {
|
||||
SUBTYPE OF organizationName
|
||||
WITH SYNTAX DirectoryString {ub-organization-name-length} 50
|
||||
ID at-mhs-organization-name}
|
||||
|
||||
mHSOrganizationalUnit OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {mHSOrganizationalUnitName}
|
||||
ID oc-mhs-organizational-unit}
|
||||
|
||||
mHSOrganizationalUnitName ATTRIBUTE ::= {
|
||||
SUBTYPE OF organizationalUnitName 60
|
||||
WITH SYNTAX DirectoryString {ub-organizational-unit-name-length}
|
||||
ID at-mhs-organizational-unit-name}
|
||||
|
||||
mHSPerson OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {mHSSurname}
|
||||
MAY CONTAIN {mHSGivenName|
|
||||
mHSInitials|
|
||||
mHSGenerationalQualifier}
|
||||
ID oc-mhs-person} 70
|
||||
|
||||
mHSSurname ATTRIBUTE ::= {
|
||||
SUBTYPE OF surname
|
||||
WITH SYNTAX DirectoryString {ub-surname-length}
|
||||
ID at-mhs-surname}
|
||||
|
||||
mHSGivenName ATTRIBUTE ::= {
|
||||
SUBTYPE OF givenName
|
||||
WITH SYNTAX DirectoryString {ub-given-name-length}
|
||||
ID at-mhs-given-name} 80
|
||||
|
||||
mHSInitials ATTRIBUTE ::= {
|
||||
SUBTYPE OF initials
|
||||
WITH SYNTAX DirectoryString {ub-initials-length}
|
||||
ID at-mhs-initials}
|
||||
|
||||
mHSGenerationQualifier ATTRIBUTE ::= {
|
||||
SUBTYPE OF generationQualifier
|
||||
WITH SYNTAX DirectoryString {ub-generation-qualifier-length}
|
||||
ID at-mhs-generation-qualifier} 90
|
||||
|
||||
mHSNamedObject OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {mHSCommonName}
|
||||
ID oc-mhs-named-object}
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 5]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
mHSCommonName ATTRIBUTE ::= {
|
||||
SUBTYPE OF commonName
|
||||
WITH SYNTAX DirectoryString {ub-common-name-length}
|
||||
ID at-mhs-common-name} 100
|
||||
|
||||
mHSX121 OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {mHSX121Address}
|
||||
ID oc-mhs-x121}
|
||||
|
||||
mHSX121Address ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX DirectoryString {ub-x121-address-length}
|
||||
ID at-x121-address} 110
|
||||
|
||||
mHSDomainDefinedAttribute OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {
|
||||
mHSDomainDefinedAttributeType|
|
||||
mHSDomainDefinedAttributeValue}
|
||||
ID oc-mhs-domain-defined-attribute}
|
||||
|
||||
mHSDomainDefinedAttributeType ATTRIBUTE ::= {
|
||||
SUBTYPE OF name 120
|
||||
WITH SYNTAX DirectoryString {ub-domain-defined-attribute-type-length}
|
||||
SINGLE VALUE
|
||||
ID at-mhs-domain-defined-attribute-type}
|
||||
|
||||
mHSDomainDefinedAttributeValue ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX DirectoryString {ub-domain-defined-attribute-value-length}
|
||||
SINGLE VALUE
|
||||
ID at-mhs-domain-defined-attribute-value}
|
||||
130
|
||||
|
||||
mHSTerminalID OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {mHSTerminalIDName}
|
||||
ID oc-mhs-terminal-id}
|
||||
|
||||
mHSTerminalIDName ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX DirectoryString {ub-terminal-id-length}
|
||||
ID at-mhs-terminal-id-name} 140
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 6]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
mHSNumericUserIdentifier OBJECT-CLASS ::= {
|
||||
SUBCLASS OF {top}
|
||||
MUST CONTAIN {mHSNumericUserIdentifierName}
|
||||
ID oc-mhs-numeric-user-id}
|
||||
|
||||
mHSNumericeUserIdentifierName ATTRIBUTE ::= {
|
||||
SUBTYPE OF name
|
||||
WITH SYNTAX DirectoryString {ub-numeric-user-id-length} 150
|
||||
ID at-mhs-numeric-user-id-name}
|
||||
|
||||
Figure 2: O/R Address Hierarchy
|
||||
|
||||
The hierarchy is defined so that:
|
||||
|
||||
1. The representation is defined so that it is straightforward to
|
||||
make a mechanical transformation in either direction. This
|
||||
requires that each node is named by an attribute whose type can
|
||||
determine the mapping.
|
||||
|
||||
2. Where there are multiple domain defined attributes, the first
|
||||
in the sequence is the most significant.
|
||||
|
||||
3. Physical Delivery (postal) addresses are not represented in
|
||||
this hierarchy. This is primarily because physical delivery can
|
||||
be handled by the Access Unit routing mechanisms defined in [4],
|
||||
and there is no need for this representation.
|
||||
|
||||
4. Terminal and network forms of address are not handled, except
|
||||
for X.121 form, which is useful for addressing faxes.
|
||||
|
||||
5. MHSCountry is defined as a subclass of Country, and so the
|
||||
same entry will be used for MHS Routing as for the rest of the
|
||||
DIT.
|
||||
|
||||
6. The numeric country code will be an alias.
|
||||
|
||||
7. ADMD will always be present in the hierarchy. This is true
|
||||
in the case of " " and of "0". This facilitates an easy
|
||||
mechanical transformation between the two forms of address.
|
||||
|
||||
8. Each node is named by the relevant part of the O/R Address.
|
||||
|
||||
9. Aliases may be used in other parts of the tree, in order to
|
||||
normalize alternate values. Where an alias is used, the value of
|
||||
the alias should be present as an alternate value in the node
|
||||
aliased to. Aliases may not be used for domain defined
|
||||
attributes.
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 7]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
10. Domain Defined Attributes are named by a multi-valued RDN
|
||||
(Relative Distinguished Name), consisting of the type and value.
|
||||
This is done so that standard attribute syntaxes can be used.
|
||||
|
||||
11. Where an O/R Address has a valid Printable String and T.61 form,
|
||||
both must be present, with one as an alias for the other. This
|
||||
is so that direct lookup of the name will work, independent of
|
||||
the variant used. When both are present in an O/R Address being
|
||||
looked up, either may be used to construct the distinguished
|
||||
name.
|
||||
|
||||
12. Personal name is handled by use of the mHSPerson object class.
|
||||
Each of the components of the personal name will be present in
|
||||
the relative distinguished name, which will usually be multi-
|
||||
valued.
|
||||
|
||||
The relationship between X.400 O/R Addresses and the X.400 Entries
|
||||
(Attribute Type and Object Class) are given in Table 2. Where there
|
||||
are multiple Organizational Units or Domain Defined Attributes, each
|
||||
component is mapped onto a single X.500 entry.
|
||||
|
||||
Note: When an X.121 address is used for addressing fax transmission,
|
||||
this may only be done relative to the PRMD or ADMD. This is in
|
||||
line with the current X.400 standards position. This means that
|
||||
it is not possible to use this form of addressing for an
|
||||
organizational or departmental fax gateway service.
|
||||
|
||||
O/R Address Object Class Naming Attribute
|
||||
----------- ------------ ----------------
|
||||
C mHSCountry countryName
|
||||
or
|
||||
mHSNumericCountryName
|
||||
A aDMD aDMDName
|
||||
P pRMD pRMDName
|
||||
O mHSOrganization mHSOrganizationName
|
||||
OU/OU1/OU2 mHSOrganizationalUnit mHSOrganizationalUnitName
|
||||
OU3/OU4
|
||||
PN mHSPerson personName
|
||||
CN mHSNamedObject mHSCommonName
|
||||
X121 mHSX121 mHSX121Address
|
||||
T-ID mHSTerminalID mHSTerminalIDName
|
||||
UA-ID mHSNumericUserIdentifier mHSNumericUserIdentifierName
|
||||
DDA mHSDomainDefinedAttribute mHSDomainDefinedAttributeType
|
||||
and
|
||||
mHSDomainDefinedAttributeValue
|
||||
|
||||
|
||||
Table 2: O/R Address relationship to Directory Name
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 8]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
2 Notation
|
||||
|
||||
O/R Addresses are written in the standard X.400 Notation.
|
||||
Distinguished Names use the string representation of distinguished
|
||||
names defined in [3]. The keywords used for the attributes defined
|
||||
in this specification are given in Table 3.
|
||||
|
||||
3 Example Representation
|
||||
|
||||
The O/R Address:
|
||||
|
||||
I=S; S=Kille; OU1=CS; O=UCL,
|
||||
P=UK.AC; A=Gold 400; C=GB;
|
||||
|
||||
|
||||
would be represented in the directory as:
|
||||
|
||||
MHS-I=S + MHS-S=Kille, MHS-OU=CS, MHS-O=UCL,
|
||||
|
||||
|
||||
Attribute Keyword
|
||||
--------- -------
|
||||
mHSNumericCountryName MHS-Numeric-Country
|
||||
aDMDName ADMD
|
||||
pRMDName PRMD
|
||||
mHSOrganizationName MHS-O
|
||||
mHSOrganizationalUnitName MHS-OU
|
||||
mHSSurname MHS-S
|
||||
mHSGivenName MHS-G
|
||||
mHSInitials MHS-I
|
||||
mHSGenerationalQualifier MHS-GQ
|
||||
mHSCommonName MHS-CN
|
||||
mHSX121Address MHS-X121
|
||||
mHSDomainDefinedAttributeType MHS-DDA-Type
|
||||
mHSDomainDefinedAttributeValue MHS-DDA-Value
|
||||
mHSTerminalIDName MHS-T-ID
|
||||
mHSNumericeUserIdentifierName MHS-UA-ID
|
||||
|
||||
Table 3: Keywords for String DN Representation
|
||||
|
||||
|
||||
PRMD=UK.AC, ADMD=Gold 400, C=GB
|
||||
|
||||
4 Mapping from O/R Address to Directory Name
|
||||
|
||||
The primary application of this mapping is to take an X.400 encoded
|
||||
O/R Address and to generate an equivalent directory name. This
|
||||
mapping is only used for selected types of O/R Address:
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 9]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
o Mnemonic form
|
||||
|
||||
o Numeric form
|
||||
|
||||
o Terminal form, where country is present and X121 addressing
|
||||
is used
|
||||
|
||||
Other forms of O/R address are handled by Access Unit mechanisms.
|
||||
The O/R Address is treated as an ordered list, with the order as
|
||||
defined in Table 1. For each O/R Address attribute, generate the
|
||||
equivalent directory naming attribute. In most cases, the mapping is
|
||||
mechanical. Printable String or Teletex encodings are chosen as
|
||||
appropriate. Where both forms are present in the O/R Address, either
|
||||
form may be used to generate the distinguished name. Both will be
|
||||
represented in the DIT. There are two special cases:
|
||||
|
||||
1. A DDA generates a multi-valued RDN
|
||||
|
||||
2. The Personal Name is mapped to a multi-valued RDN
|
||||
|
||||
In many cases, an O/R Address will be provided, and only the higher
|
||||
components of the address will be represented in the DIT. In this
|
||||
case, the "longest possible match" should be returned.
|
||||
|
||||
5 Mapping from Directory Name to O/R Address
|
||||
|
||||
The reverse mapping is also needed in some cases. All of the naming
|
||||
attributes are unique, so the mapping is mechanically reversible.
|
||||
|
||||
6 Acknowledgments
|
||||
|
||||
Acknowledgments for work on this document are given in [4].
|
||||
|
||||
References
|
||||
|
||||
[1] The Directory --- overview of concepts, models and services,
|
||||
1993. CCITT X.500 Series Recommendations.
|
||||
|
||||
[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
|
||||
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
|
||||
|
||||
[3] Kille, S., "A String Representation of Distinguished Names",
|
||||
RFC 1779, March 1995.
|
||||
|
||||
[4] Kille, S., "Use of an X.500/LDAP directory to support MIXER address
|
||||
mapping", RFC 2164, January 1998.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 10]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
[5] Kille, S., "X.400-MHS use of the X.500 directory to support
|
||||
X.400-MHS routing", RFC 1801, June 1995.
|
||||
|
||||
[6] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
|
||||
SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service
|
||||
Overview.
|
||||
|
||||
7 Security Considerations
|
||||
|
||||
This protocol introduces no known security risks.
|
||||
|
||||
8 Author's Address
|
||||
|
||||
Steve Kille
|
||||
Isode Ltd.
|
||||
The Dome
|
||||
The Square
|
||||
Richmond
|
||||
TW9 1DT
|
||||
England
|
||||
|
||||
Phone: +44-181-332-9091
|
||||
EMail: S.Kille@ISODE.COM
|
||||
|
||||
X.400: I=S; S=Kille; P=ISODE; A=Mailnet; C=FI;
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 11]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
A Object Identifier Assignment
|
||||
|
||||
mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
|
||||
enterprises(1) isode-consortium (453) mhs-ds (7)}
|
||||
|
||||
|
||||
tree OBJECT IDENTIFIER ::= {mhs-ds 2}
|
||||
|
||||
oc OBJECT IDENTIFIER ::= {tree 1}
|
||||
at OBJECT IDENTIFIER ::= {tree 2}
|
||||
|
||||
oc-admd OBJECT IDENTIFIER ::= {oc 1} 10
|
||||
oc-mhs-country OBJECT IDENTIFIER ::= {oc 2}
|
||||
oc-mhs-domain-defined-attribute OBJECT IDENTIFIER ::= {oc 3}
|
||||
oc-mhs-named-object OBJECT IDENTIFIER ::= {oc 4}
|
||||
oc-mhs-organization OBJECT IDENTIFIER ::= {oc 5}
|
||||
oc-mhs-organizational-unit OBJECT IDENTIFIER ::= {oc 6}
|
||||
oc-mhs-person OBJECT IDENTIFIER ::= {oc 7}
|
||||
oc-mhs-x121 OBJECT IDENTIFIER ::= {oc 8}
|
||||
oc-prmd OBJECT IDENTIFIER ::= {oc 9}
|
||||
oc-mhs-terminal-id OBJECT IDENTIFIER ::= {oc 10}
|
||||
oc-mhs-numeric-user-id OBJECT IDENTIFIER ::= {oc 11} 20
|
||||
|
||||
at-admd-name OBJECT IDENTIFIER ::= {at 1}
|
||||
at-mhs-common-name OBJECT IDENTIFIER ::= {at 2}
|
||||
at-mhs-domain-defined-attribute-type OBJECT IDENTIFIER ::= {at 3}
|
||||
at-mhs-domain-defined-attribute-value OBJECT IDENTIFIER ::= {at 4}
|
||||
at-mhs-numeric-country-name OBJECT IDENTIFIER ::= {at 5}
|
||||
at-mhs-organization-name OBJECT IDENTIFIER ::= {at 6}
|
||||
at-mhs-organizational-unit-name OBJECT IDENTIFIER ::= {at 7}
|
||||
at-prmd-name OBJECT IDENTIFIER ::= {at 10}
|
||||
at-x121-address OBJECT IDENTIFIER ::= {at 12} 30
|
||||
at-mhs-terminal-id-name OBJECT IDENTIFIER ::= {at 13}
|
||||
at-mhs-numeric-user-id-name OBJECT IDENTIFIER ::= {at 14}
|
||||
at-mhs-surname OBJECT IDENTIFIER ::= {at 15}
|
||||
at-mhs-given-name OBJECT IDENTIFIER ::= {at 16}
|
||||
at-mhs-initials OBJECT IDENTIFIER ::= {at 17}
|
||||
at-mhs-generation-qualifier OBJECT IDENTIFIER ::= {at 18}
|
||||
|
||||
Figure 3: Object Identifier Assignment
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 12]
|
||||
|
||||
RFC 2294 Directory Information Tree March 1998
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kille Standards Track [Page 13]
|
||||
|
||||
1179
doc/rfc/rfc2307.txt
Normal file
1179
doc/rfc/rfc2307.txt
Normal file
File diff suppressed because it is too large
Load Diff
1011
doc/rfc/rfc2377.txt
Normal file
1011
doc/rfc/rfc2377.txt
Normal file
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user