upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-12-24 00:29:35 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Trim some old/experimental RFCs

Browse source
This commit is contained in:
Kurt Zeilenga 2002-01-05 02:40:10 +00:00
parent e5aafcdab1
commit 879733f9f7
9 changed files with 0 additions and 7924 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/rfc/INDEX
View file

@ -1,13 +1,7 @@
This is an index of RFC contained in this directory:
rfc1274.txt COSINE and Internet X.500 Schema (PS)
rfc1279.txt X.500 and Domains (E)
rfc1430.txt Plan for Deploying an Internet X.500 Directory Service (I)
rfc1617.txt Naming and Structuring Guidelines for X.500 Directory Pilots (I)
rfc1798.txt Connection-less LDAP (PS)
rfc1823.txt LDAP C API (I)
rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
rfc2218.txt Common Schema for the Internet White Pages Service (PS)
rfc2247.txt Using Domains in LDAP DNs (PS)
rfc2251.txt LDAPv3 Protocol (PS)
rfc2252.txt LDAPv3 Attribute Types (PS)
@ -23,14 +17,12 @@ rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
rfc2596.txt Use of Language Codes in LDAP (PS)
rfc2649.txt LDAPv3 Operational Signatures (E)
rfc2657.txt LDAPv2 Client vs. the Index Mesh (E)
rfc2696.txt LDAP Simple Paged Result Control (I)
rfc2713.txt LDAP Java schema (I)
rfc2714.txt LDAP CORBA schema (I)
rfc2798.txt LDAP inetOrgPerson schema (I)
rfc2829.txt LDAPv3: Authentication Method (PS)
rfc2830.txt LDAPv3: StartTLS (PS)
rfc2831.txt SASL/DIGEST-MD5 (PS)
rfc2849.txt LDIFv1 (PS)
rfc2891.txt LDAPv3: Server Side Sorting of Search Results (PS)
rfc3045.txt Storing Vendor Information in the LDAP root DSE (I)

839
doc/rfc/rfc1279.txt
View file

@ -1,839 +0,0 @@
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

1123
doc/rfc/rfc1430.txt
View file

File diff suppressed because it is too large Load diff

1571
doc/rfc/rfc1617.txt
View file

File diff suppressed because it is too large Load diff

507
doc/rfc/rfc1798.txt
View file

@ -1,507 +0,0 @@
Network Working Group A. Young
Request for Comments: 1798 ISODE Consortium
Category: Standards Track June 1995
Connection-less Lightweight Directory Access Protocol
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.
X.500
The protocol described in this document is designed to provide access
to the Directory while not incurring the resource requirements of the
Directory Access Protocol (DAP) [3]. In particular, it is aimed at
avoiding the elapsed time that is associated with connection-oriented
communication and it facilitates use of the Directory in a manner
analagous to the DNS [5,6]. It is specifically targeted at simple
lookup applications that require to read a small number of attribute
values from a single entry. It is intended to be a complement to DAP
and LDAP [4]. The protocol specification draws heavily on that of
LDAP.
1. Background
The Directory can be used as a repository for many kinds of
information. The full power of DAP is unnecessary for applications
that require simple read access to a few attribute values.
Applications addressing is a good example of this type of use where
an application entity needs to determine the Presentation Address
(PA) of a peer entity given that peer's Application Entity Title
(AET). If the AET is a Directory Name (DN) then the required result
can be obtained from the PA attribute of the Directory entry
identified by the AET. This is very similar to DNS.
Young Standards Track [Page 1]
RFC 1798 CLDAP June 1995
Use of DAP to achieve this functionality involves a significant
number of network exchanges:
___________________________________________________________
|_#_|______Client_(DUA)________DAP________Server_(DSA)_____|
| 1| N-Connect.request -> |
| 2| <- N-Connect.response |
| 3| T-Connect.request -> |
| 4| <- T-Connect.response |
| | S-Connect.request, |
| | P-Connect.request, |
| | A-Associate.request, |
| 5| DAP-Bind.request -> |
| | S-Connect.response, |
| | P-Connect.response, |
| | A-Associate.response, |
| 6| <- DAP-Bind.response |
| 7| DAP-Read.request -> |
| 8| <- DAP-Read.response |
| | S-Release.request, |
| | P-Release.request, |
| | A-Release.request, |
| 9| DAP-Unbind.request -> |
| | S-Release.response, |
| | P-Release.response, |
| | A-Release.response, |
| 10| <- DAP-Unbind.response |
| | T-Disconnect.request, |
| 11| N-Disconnect.request -> |
| | T-Disconnect.response,|
| 12| <- N-Disconnect.response |
|___|______________________________________________________|
Young Standards Track [Page 2]
RFC 1798 CLDAP June 1995
This is 10 packets before the application can continue, given that it
can probably do so after issuing the T-Disconnect.request. (Some
minor variations arise depending upon the class of Network and
Transport service that is being used; for example use of TP4 over
CLNS reduces the packet count by two.) LDAP is no better in the case
where the LDAP server uses full DAP to communicate with the
Directory:
____________________________________________________________________
|__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______|
| 1 | TCP SYN -> |
| 2 | <- TCP SYN ACK |
| 3 | BindReq -> |
| 4 | N-Connect.req -> |
| 5 | <- N-Connect.res |
| 6 | T-Connect.req -> |
| 7 | <- T-Connect.res |
| 8 | DAP-Bind.req -> |
| 9 | <- DAP-Bind.res |
| 10 | <- BindRes |
| 11 | SearchReq -> |
| 12 | DAP-Search.req -> |
| 13 | <- DAP-Search.res |
| 14 | <- SearchRes |
| 15 | TCP FIN -> |
| 16 | DAP-Unbind.req -> |
| 17 | <- DAP-Unbind.res |
| 18 | N-Disconnect.req -> |
| 19 | <- N-Disconnect.res|
|____|______________________________________________________________|
Young Standards Track [Page 3]
RFC 1798 CLDAP June 1995
Here there are 14 packets before the application can continue. Even
if the LDAP server is on the same host as the DSA (so packet delay is
negligible), or if the DSA supports LDAP directly, then there are
still 6 packets.
____________________________________
| #| Client LDAP LDAP server|
|__|________________________________|
| 1| TCP SYN -> |
| 2| <- TCP SYN ACK|
| 3| BindReq -> |
| 4| <- BindRes |
| 5| SearchReq -> |
|_6|_______________<-____SearchRes__|
This protocol provides for simple access to the Directory where the
delays inherent in the above exchanges are unacceptable and where the
additional functionality provided by connection-mode operation is not
required.
2. Protocol Model
CLDAP is based directly on LDAP [4] and inherits many of the key
aspects of the LDAP protocol:
- - Many protocol data elements are encoding as ordinary strings
(e.g., Distinguished Names).
- - A lightweight BER encoding is used to encode all protocol
elements.
It is different to LDAP in that:
- - Protocol elements are carried directly over UDP or other
connection-less transport, bypassing much of the
session/presentation overhead and that of connections (LDAP uses
a connection-mode transport service).
- - A restricted set of operations is available.
The definitions of most protocol elements are inherited from LDAP.
The general model adopted by this protocol is one of clients
performing protocol operations against servers. In this model, this
is accomplished by a client transmitting a protocol request
describing the operation to be performed to a server, which is then
responsible for performing the necessary operations on the Directory.
Young Standards Track [Page 4]
RFC 1798 CLDAP June 1995
Upon completion of the necessary operations, the server returns a
response containing any results or errors to the requesting client.
Note that, although servers are required to return responses whenever
such responses are defined in the protocol, there is no requirement
for synchronous behaviour on the part of either client or server
implementations: requests and responses for multiple operations may
be exchanged by client and servers in any order, as long as servers
eventually send a response for every request that requires one.
Also, because the protocol is implemented over a connection-less
transport service clients must be prepared for either requests or
responses to be lost. Clients should use a retry mechanism with
timeouts in order to achieve the desired level of reliability. For
example, a client might send off a request and wait for two seconds.
If no reply is forthcoming, the request is sent again and the client
waits four seconds. If there is still no reply, the client sends it
again and waits eight seconds, and so on, until some maximun time.
Such algorithms are widely used in other datagram-based protocol
implementations, such as the DNS. It is not appropriate to mandate a
specific algorithm as this will depend upon the requirments and
operational environment of individual CLDAP client implementations.
It is not required that a client abandon any requests to which no
response has been received and for which a reply is no longer
required (because the request has been timed out), but they may do
so.
Consistent with the model of servers performing protocol operations
on behalf of clients, it is also to be noted that protocol servers
are expected to handle referrals without resorting to the return of
such referrals to the client. This protocol makes no provisions for
the return of referrals to clients, as the model is one of servers
ensuring the performance of all necessary operations in the
Directory, with only final results or errors being returned by
servers to clients.
Note that this protocol can be mapped to a strict subset of the
Directory abstract service, so it can be cleanly provided by the DAP.
3. Mapping Onto Transport Services
This protocol is designed to run over connection-less transports,
with all 8 bits in an octet being significant in the data stream.
Specifications for two underlying services are defined here, though
others are also possible.
Young Standards Track [Page 5]
RFC 1798 CLDAP June 1995
3.1. User Datagram Protocol (UDP)
The CLDAPMessage PDUs are mapped directly onto UDP datagrams. Only
one request may be sent in a single datagram. Only one response may
be sent in a single datagram. Server implementations running over
the UDP should provide a protocol listener on port 389.
3.2. Connection-less Transport Service (CLTS)
Each LDAPMessage PDU is mapped directly onto T-Unit-Data.
4. Elements of Protocol
CLDAP messages are defined by the following ASN.1:
CLDAPMessage ::= SEQUENCE {
messageID MessageID,
user LDAPDN, -- on request only --
protocolOp CHOICE {
searchRequest SearchRequest,
searchResponse SEQUENCE OF
SearchResponse,
abandonRequest AbandonRequest
}
}
where MessageID, LDAPDN, SearchRequest, SearchResponse and
AbandonRequest are defined in the LDAP protocol.
The 'user' element is supplied only on requests (it should be zero
length and is ignored in responses). It may be used for logging
purposes but it is not required that a CLDAP server implementation
apply any particular semantics to this field.
Editorial note:
There has been some discussion about the desirability of
authentication with CLDAP requests and the addition of the fields
necessary to support this. This might take the form of a clear
text password (which would go against the current IAB drive to
remove such things from protocols) or some arbitrary credentials.
Such a field is not included. It is felt that, in general,
authentication would incur sufficient overhead to negate the
advantages of the connectionless basis of CLDAP. If an
application requires authenticated access to the Directory then
CLDAP is not an appropriate protocol.
Young Standards Track [Page 6]
RFC 1798 CLDAP June 1995
Within a searchResponse all but the last SearchResponse has choice
'entry' and the last SearchResponse has choice 'resultCode'. Within
a searchResponse, as an encoding optimisation, the value of the
objectName LDAP DN may use a trailing '*' character to refer to the
baseObject of the corresponding searchRequest. For example, if the
baseObject is specified as "o=UofM, c=US", then the following
objectName LDAPDNs in a response would have the indicated meanings
objectName returned actual LDAPDN denoted
____________________________________________________
"*" "o=UofM, c=US"
"cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US"
4.1. Errors
The following error code is added to the LDAPResult.resultCode
enumeration of [4]:
resultsTooLarge (70),
This error is returned when the LDAPMessage PDU containing the
results of an operation are too large to be sent in a single
datagram.
4.2. Example
A simple lookup can be performed in 4 packets. This is reduced to 2
if either the DSA implements the CLDAP protocol, the CLDAP server has
a cache of the desired results, or the CLDAP server and DSA are co-
located such that there is insignificant delay between them.
_______________________________________________________________
|_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______|
| 1| SearchReq -> |
| 2| DAP-Search.req -> |
| 3| <- DAP-Search.res|
| 4| <- SearchRes |
|__|___________________________________________________________|
5. Implementation Considerations
The following subsections provide guidance on the implementation of
clients and servers using the CLDAP protocol.
Young Standards Track [Page 7]
RFC 1798 CLDAP June 1995
5.1. Server Implementations
Given that the goal of this protocol is to minimise the elapsed time
between making a Directory request and receiving the response, a
server which uses DAP to access the directory should use techniques
that assist in this.
- - A server should remain bound to the Directory during reasonably
long idle periods or should remain bound permanently.
- - Cacheing of results is highly desirable but this must be
tempered by the need to provide up-to-date results given the
lack of a cache invalidation protocol in DAP (either implicit
via timers or explicit) and the lack of a dontUseCopy service
control in the protocol.
Of course these issues are irrelevant if the CLDAP protocol is
directly supported by a DSA.
5.2. Client Implementations
For simple lookup applications, use of a retry algorithm with
multiple servers similar to that commonly used in DNS stub resolver
implementations is recommended. The location of a CLDAP server or
servers may be better specified using IP addresses (simple or
broadcast) rather than names that must first be looked up in another
directory such as DNS.
6. Security Considerations
This protocol provides no facilities for authentication. It is
expected that servers will bind to the Directory either anonymously
or using simple authentication without a password.
7. Bibliography
[1] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[2] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
1/SC21; International Standard 9594-2, 1988.
[3] The Directory: Abstract Service Definition. CCITT Recommendation
X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
[4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory
Access Protocol", RFC 1487, Performance Systems International,
University of Michigan, ISODE Consortium, July 1993.
Young Standards Track [Page 8]
RFC 1798 CLDAP June 1995
[5] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
8. Acknowledgements
Many thanks to Tim Howes and Steve Kille for their detailed comments
and to other members of the working group.
This work was initiated by the Union Bank of Switzerland.
9. Author's Address
Alan Young
ISODE Consortium
The Dome, The Square
RICHMOND
GB - TW9 1DT
Phone: +44 81 332 9091
EMail: A.Young@isode.com
X.400: i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI
Young Standards Track [Page 9]

1235
doc/rfc/rfc1823.txt
View file

File diff suppressed because it is too large Load diff

451
doc/rfc/rfc2218.txt
View file

@ -1,451 +0,0 @@
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]

675
doc/rfc/rfc2657.txt
View file

@ -1,675 +0,0 @@
Network Working Group R. Hedberg
Request for Comment: 2657 Catalogix
Category: Experimental August 1999
LDAPv2 Client vs. the Index Mesh
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
LDAPv2 clients as implemented according to RFC 1777 [1] have no
notion on referral. The integration between such a client and an
Index Mesh, as defined by the Common Indexing Protocol [2], heavily
depends on referrals and therefore needs to be handled in a special
way. This document defines one possible way of doing this.
1. Background
During the development of the Common Indexing Protocol (CIP), one of
the underlying assumptions was that the interaction between clients
and the Index Mesh Servers [1] would heavily depend on the passing of
referrals. Protocols like LDAPv2 [2] that lack this functionality
need to compensate for it by some means. The way chosen in this memo
is to add more intelligence into the client. There are two reasons
behind this decision. First, this is not a major enhancement that is
needed and secondly, that the intelligence when dealing with the
Index Mesh, with or the knowledge about referrals, eventually has to
go into the client.
2. The clients view of the Index Mesh
If a LDAPv2 client is going to be able to interact with the Index
Mesh, the Mesh has to appear as something that is understandable to
the client. Basically, this consists of representing the index
servers and their contained indexes in a defined directory
information tree (DIT) [3,4] structure and a set of object classes
and attribute types that have been proven to be useful in this
context.
Hedberg Experimental [Page 1]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.1 The CIP Object Classes
Object class descriptions are written according to the BNF defined in
[5].
2.1.1 cIPIndex
The cIPIndex objectClass, if present in a entry, allows it to hold
one indexvalue and information connected to this value.
( 1.2.752.17.3.9
NAME 'cIPIndex'
SUP 'top'
STRUCTURAL
MUST ( extendedDSI $ idx )
MAY ( indexOCAT )
)
2.1.2 cIPDataSet
The cIPDataSet objectClass, if present in a entry, allows it to hold
information concerning one DataSet.
( 1.2.752.17.3.10
NAME 'cIPDataSet'
SUP 'top'
STRUCTURAL
MUST ( dSI $ searchBase )
MAY ( indexOCAT $ description $ indexType $
accessPoint $ protocolVersion $ polledBy $
updateIntervall $ securityOption $
supplierURI $ consumerURI $ baseURI $
attributeNamespace $ consistencyBase
)
)
2.2 The CIP attributeTypes
The attributes idx, indexOCAT, extendedDSI, description,
cIPIndexType, baseURI, dSI are used by a client accessing the index
server. The other attributes (accesspoint, protocolVersion,
polledBy, updateIntervall, consumerURI, supplierURI and
securityOption, attributeNamespace, consistencyBase) are all for
usage in server to server interactions.
Hedberg Experimental [Page 2]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.2.1 idx
The index value, normally used as part of the RDN.
( 1.2.752.17.1.20
NAME 'idx'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
SINGLE-VALUE
)
2.2.2 dSI
DataSet Identifier, a unique identifier for one particular set of
information. This should be an OID, but stored in a stringformat.
( 1.2.752.17.1.21
NAME 'dSI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
2.2.3 indexOCAT
Describes the type of data that is stored in this entry, by using
objectcClasses and attributeTypes. The information is stored as a
objectClass name followed by a space and then an attributeType name.
A typical example when dealing with whitepages information would be
"person cn".
( 1.2.752.17.1.28
NAME 'indexOCAT'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
2.2.5 supplierURI
A URI describing which protocols, hostnames and ports should be used
by an indexserver to interact with servers carrying indexinformation
representing this dataSet.
( 1.2.752.17.1.22
NAME 'supplierURI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
Hedberg Experimental [Page 3]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.2.6 baseURI
The attribute value for this attribute is a LDAP URI. One can
envisage other URI syntaxes, if the client knows about more access
protocols besides LDAP, and the interaction between the client and
the server can not use referrals for some reason.
( 1.2.752.17.1.26
NAME 'baseURI'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
2.2.7 protocolVersion
At present, the Common Indexing Protocol version should be 3.
( 1.2.752.17.1.27
NAME 'protocolVersion'
EQUALITY numericStringMatch
SYNTAX numericString
)
2.2.8 cIPIndexType
The type of index Object that is used to pass around index
information.
( 1.2.752.17.1.29
NAME 'cIPIndexType'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
2.2.10 polledBy
The Distinguished Name of Index servers that polls data from this
indexserver.
( 1.2.752.17.1.30
NAME 'polledBy'
EQUALITY distinguishedNameMatch
SYNTAX DN
)
Hedberg Experimental [Page 4]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.2.11 updateIntervall
The maximum duration in seconds between the generation of two updates
by the supplier server.
( 1.2.752.17.1.31
Name 'updateIntervall'
EQUALITY numericStringMatch
SYNTAX numericString
SINGLE-VALUE
)
2.2.12 securityOption
Whether and how the supplier server should sign and encrypt the
update before sending it to the consumer server.
( 1.2.752.17.1.32
NAME 'securityOption'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
SINGLE-VALUE
)
2.2.13 extendedDSI
DataSet Identifier possibly followed by a space and a taglist, the
later as specified by [6].
( 1.2.752.17.1.33
NAME 'extendedDSI'
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
)
2.2.14 consumerURI
A URI describing which means a server can accept indexinformation.
An example being a mailto URI for MIME email based index transport.
( 1.2.752.17.1.34
NAME 'consumerURI'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
Hedberg Experimental [Page 5]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
2.2.15 attributeNamespace
Any consumer supplier pair has to agree on what attribute that should
be used and also possibly the meaning of the attributenames. The
value of this attribute should, for example, be a URI pointing to a
document wherein the agreement is described.
( 1.2.752.17.1.35 NAME 'attributeNamespace' EQUALITY
caseExactIA5Match SYNTAX IA5String
)
2.2.16 consistencyBase
This attribute is specifically used by consumer supplier pairs that
use the tagged index object [6].
( 1.2.752.17.1.36
NAME 'consistencyBase'
EQUALITY caseExactIA5Match
SYNTAX IA5String
)
3. The interaction between a client and the Index Mesh
A client interaction with the Index Mesh consists of a couple of
rather well defined actions. The first being to find a suitable index
to start with, then to transverse the Index Mesh and finally to query
the servers holding the original data. Note when reading this text
that what is discussed here is the client's perception of the DIT,
how it is in fact implemented is not discussed.
3.1 Finding a Index Mesh
This approach depends on the fact that every index server partaking
in an Index Mesh is represented in the DIT by a entry of the type
cIPDataSet, and has a distinguished name (DN) which most significant
relative distinguished name (RDN) has the attributetype dSI.
Therefore, finding a suitable indexserver to start the search from is
a matter of searching the DIT at a suitable place for objects with
the objectClass cIPIndexObject. Every found entry can then be
evaluated by looking at the description value as well as the
indexOCAT value. The description string should be a human readable
and understandable text that describes what the index server is
indexing. An example of such a string could be, "This index covers
all employees at Swedish Universities and University Colleges that
has an email account". The indexOCAT attribute supplies information
about which kind of entries and which attributes within these entries
that the index information has emanated from. For example, if the
Hedberg Experimental [Page 6]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
indexOCAT attribute value is "person cn", one can deduce that this is
an index over persons and not over roles, and that it is the
attribute commonName that is indexed.
3.2 Searching the mesh
Each index server has its information represented in the DIT as a
very flat tree. In fact, it is only one level deep.
0 Indexservers cIPDataSet
/|\
/ | \
/ | \
0 0
cIPDataSet entries cIPIndex entries
one for each DataSet one for each index value
that this server has that this indexserver
gathered indexes from. has.
A search then consists of a set of searches. The first being the
search for the index entries that contains an indexvalue that matches
what the user is looking for, and the second a search based on the
DSI information in the extendedDSI attribute values returned from the
first search. In the case of the the cIPIndexType being tagged-
index, the taglists should be compared to find which DSI it might be
useful to pose further queries to.
When doing these types of searches, the client should be aware of the
fact that the index values disregarding their origin (attributeTypes)
always are stored in the index server as values of the idx attribute.
The object of the second search is to get information on the
different DataSet involved, and should normally be performed as a
read. Since the DataSet information probably will remain quite stable
over time, this information lends itself very well to caching. If at
this stage there is more than one DataSet involved, the User
interface might use the description value to aid the user in choosing
which one to proceed with. The content of the searchBase value of
the DataSet tells the client whether it represents another index
server (the most significant part of the dn is a dSI attribute) or if
it is a end server.
Hedberg Experimental [Page 7]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
3.3 Querying the end server
When finally reaching the end server/servers that probably has the
sought for information, the information in the indexOCAT attribute
can be used to produce an appropriate filter. If a search for "Rol*"
in an index having an indexOCAT attribute value of "person cn"
returns an idx entry with the idx value of "Roland", then an
appropriate filter to use might be "&(|(cn=* roland *)(cn=roland
*)(cn=* roland))(objectclass=person)". A complete example of a
search process is given in Appendix A.
4. Security Considerations
Since this memo deals with client behavior, it does not add anything
that either enhances or diminishes the security features that exists
in LDAPv2.
5. Internationalization
As with security, this memo neither enhances or diminishes the
handling of internationalization in LDAPv2.
6. References
[1] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[2] Allen, J. and M. Mealling "The Architecture of the Common
Indexing Protocol (CIP)", RFC 2651, August 1999.
[3] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[4] Information Processing Systems -- Open Systems Interconnection --
The Directory: Overview of Concepts, Models and Service. ISO/IEC
JTC 1/SC21; International Standard 9594-1, 1988.
[5] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[6] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged
Index Object for use in the Common Indexing Protocol", RFC 2654,
August 1999.
Hedberg Experimental [Page 8]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
7. Author's Address
Roland Hedberg
Catalogix
Dalsveien 53
0387 Oslo, Norway
Phone: +47 23 08 29 96
EMail: roland@catalogix.ac.se
Hedberg Experimental [Page 9]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
Appendix A - Sample Session
Below is a sample of a session between a LDAPv2 client and an index
server mesh as specified in this memo.
The original question of the session is to find the email address of
a person by the name, "Roland Hedberg", who is working at "Umea
University" in Sweden.
Step 1.
A singlelevel search with the baseaddress "c=SE" and the filter
"(objectclass=cipDataset)" was issued.
The following results were received:
DN: dSI=1.2.752.17.5.0,c=SE
dsi= 1.2.752.17.5.0
description= "index over employees with emailaddresses within Swedish
higher education"
indexOCAT= "cn person"
cIPIndexType= "x-tagged-index-1" ;
searchBase= "dsi=1.2.752.17.5.0,c=SE"
protocolVersion = 3
DN: dSI=1.2.752.23.1.3,c=SE
dsi= 1.2.752.23.1.3
description= "index over Swedish lawyers"
indexOCAT= "cn person"
cIPIndexType= "x-tagged-index-1" ;
searchBase= "dsi=1.2.752.23.1.3,c=SE"
protocolVersion = 3
Step 2.
Since the first index seemed to cover the interesting population, a
single level search with the baseaddress "dsi=1.2.752.17.5.0,c=SE"
and the filter "(|(idx=roland)(idx=hedberg))" was issued.
The following results were received:
DN: idx=Roland,dSI=1.2.752.17.5.0,c=SE
idx= Roland
extendedDSI= 1.2.752.17.5.10 1,473,612,879,1024
extendedDSI= 1.2.752.17.5.14 35,78,150,200
extendedDSI= 1.2.752.17.5.16 187,2031,3167,5284,6034-6040
extendedDSI= 1.2.752.17.5.17 17
Hedberg Experimental [Page 10]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
DN: idx=Hedberg,dSI=1.2.752.17.5.0,c=SE
idx= Hedberg
extendedDSI= 1.2.752.17.5.8 24,548-552,1066
extendedDSI= 1.2.752.17.5.10 473,512,636,777,1350
extendedDSI= 1.2.752.17.5.14 84,112,143,200
extendedDSI= 1.2.752.17.5.15 1890-1912
extendedDSI= 1.2.752.17.5.17 44
A comparison between the two sets of extendedDSIs shows that two
datasets 1.2.752.17.5.10 and 1.2.752.17.5.14 contains persons named
"Roland" and "Hedberg". Therefore, the next step would be to see what
the datasets represent. A comparison like this should normally not
be left to the user.
Step. 3
Two baselevel searches, one for
"dsi=1.2.752.17.5.10,dsi=1.2.752.17.5.0,c=SE" and the other for
"dsi=1.2.752.17.5.14,dsi=1.2.752.17.5.0,c=SE" with the filter
"(objectclass=cipdataset)" were issued.
The following results were received:
DN: dSI=1.2.752.17.5.10,dSI=1.2.752.17.5.0,c=SE
dsi= 1.2.752.17.5.10
description= "Employees at Umea University,Sweden"
indexOCAT= "person cn"
searchBase= "o=Umea Universitet,c=SE"
respectively
DN: dSI=1.2.752.17.5.14,dSI=1.2.752.17.5.0,c=SE
dsi= 1.2.752.17.5.14
description= "Employees at Lund University,Sweden"
indexOCAT= "person cn"
searchBase= "o=Lunds Universitet,c=SE"
Step 4
Based on the descriptions for the two datasets, "1.2.752.17.5.10" was
chosen as the best to proceed with. From the searchbase attribute
value, it was clear that this was a base server. The query now has
to be somewhat modified. One possibility would be to issue a query
with the baseobject "o=Umea Universitet,c=SE" and the filter
"(&(cn=Roland Hedberg)(objectclass=person))"
Hedberg Experimental [Page 11]
RFC 2657 LDAPv2 vs. Index Mesh August 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hedberg Experimental [Page 12]

1515
doc/rfc/rfc2831.txt
View file

File diff suppressed because it is too large Load diff