1. adding LDAP relevant RFC's

doc/rfc/rfc1275.txt

@@ -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
+

doc/rfc/rfc1279.txt

@@ -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
+

doc/rfc/rfc1308.txt

@@ -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]
+

doc/rfc/rfc1309.txt

@@ -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]
+

doc/rfc/rfc1960.txt

@@ -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]
+

doc/rfc/rfc2044.txt

@@ -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]
+

doc/rfc/rfc2164.txt

@@ -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]
+

doc/rfc/rfc2218.txt

@@ -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]
+

doc/rfc/rfc2247.txt

@@ -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]
+

doc/rfc/rfc2253.txt

@@ -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]
+

doc/rfc/rfc2254.txt

@@ -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]
+

doc/rfc/rfc2255.txt

@@ -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]
+

doc/rfc/rfc2293.txt

@@ -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]
+

doc/rfc/rfc2294.txt

@@ -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]
+