7 Network Working Group A. Grimstad
8 Request for Comments: 2377 R. Huber
9 Category: Informational AT&T
17 Naming Plan for Internet Directory-Enabled Applications
21 This memo provides information for the Internet community. It does
22 not specify an Internet standard of any kind. Distribution of this
27 Copyright (C) The Internet Society (1998). All Rights Reserved.
31 Application of the conventional X.500 approach to naming has
32 heretofore, in the experience of the authors, proven to be an
33 obstacle to the wide deployment of directory-enabled applications on
34 the Internet. We propose a new directory naming plan that leverages
35 the strengths of the most popular and successful Internet naming
36 schemes for naming objects in a hierarchical directory. This plan
37 can, we believe, by extending the X.500 approach to naming,
38 facilitate the creation of an Internet White Pages Service (IWPS) and
39 other directory-enabled applications by overcoming the problems
40 encountered by those using the conventional X.500 approach.
44 Application of the conventional X.500 approach to naming has
45 heretofore, in the experience of the authors, proven to be an
46 obstacle to the wide deployment of directory-enabled applications on
47 the Internet. The required registration infrastructure is either
48 non-existent or largely ignored. The infrastructure that does exist
49 is cumbersome to use and tends to produce counterproductive results.
50 The attributes used for naming have been confusing for users and
51 inflexible to managers and operators of directory servers.
58 Grimstad, et. al. Informational [Page 1]
60 RFC 2377 A Directory Naming Plan September 1998
63 This paper describes a directory naming plan for the construction of
64 an Internet directory infrastructure to support directory-enabled
65 applications that can serve as an alternative (or extension) to the
66 conventional X.500 approach.
68 The plan has the following two main features. First, it bases the
69 root and upper portions of the name hierarchy on the existing
70 infrastructure of names from the Domain Name System (DNS). This
71 component of the plan makes use of the ideas described in the
72 companion paper to this plan, "Using Domains in LDAP Distinguished
73 Names" [1]. And second, it provides a number of options for the
74 assignment of names to directory leaf objects such as person objects,
75 including an option that allows the reuse of existing Internet
76 identifiers for people.
78 Just as the conventional X.500 style of naming is not a formal
79 standard, use of the naming plan described here is not obligatory for
80 directory-enabled applications on the Internet. Other approaches are
81 permissible. However, we believe widespread use of this plan will
82 largely eliminate naming as a typically thorny issue when
83 administrators set up an LDAP-based directory service. Further, we
84 strongly encourage developers of directory-enabled products,
85 especially LDAP clients and user interfaces, to assume that this
86 naming plan will see widespread use and design their products
89 Here, in summary, is our proposal.
91 The upper portions of the hierarchical directory tree should be
92 constructed using the components of registered DNS names using the
93 domain component attribute "dc". The directory name for the
94 organization having the domain name "acme.com" will then be, e.g.,
98 Organizations can add additional directory structure, for example to
99 support implementation of access control lists or partitioning of
100 their directory information, by using registered subdomains of DNS
101 names, e.g., the subdomain "corporate.acme.com" can be used as the
102 basis for the directory name
104 dc=corporate, dc=acme, dc=com
106 For naming directory leaf objects such as persons, groups, server
107 applications and certification authorities in a hierarchical
108 directory, we propose the use of either the "uid" (user identifier)
109 or the "cn" (common name) attribute for the relative distinguished
110 name. This plan does not constrain how these two attributes are used.
114 Grimstad, et. al. Informational [Page 2]
116 RFC 2377 A Directory Naming Plan September 1998
119 One approach to their use, for example, is to employ the uid
120 attribute as the RDN when reusing an existing store of identifiers
121 and the cn attribute as the RDN when creating new identifiers
122 specifically for the directory. A convenient existing identification
123 scheme for person objects is the RFC822 mailbox identifier. So an RDN
124 for person employing this store of identifiers would be, e.g.,
126 uid=John.Smith@acme.com
128 For leaf objects not conveniently identified with such a scheme, the
129 "cn" attribute is used, e.g.,
133 Directory distinguished names will thus have the following structure,
136 uid=John.Smith@acme.com, dc=acme, dc=com
137 uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
138 uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com
139 cn=Reading Room, dc=physics, dc=national-lab, dc=edu
143 The X.500 Directory model [2] can be used to create a world-wide
144 distributed directory. The Internet X.500 Directory Pilot has been
145 operational for several years and has grown to a size of about 1.5
146 million entries of varying quality. The rate of growth of the pilot
147 is far lower than the rate of growth of the Internet during the pilot
150 There are a substantial number of contributing factors that have
151 inhibited the growth of this pilot. The common X.500 approach to
152 naming, while not the preponderant problem, has contributed in
153 several ways to limit the growth of an Internet White Pages Service
156 The conventional way to construct names in the X.500 community is
157 documented as an informative (i.e., not officially standardized)
158 Annex B to X.521. The relative distinguished name (RDN) of a user
159 consists of a common name (cn) attribute. This is meant to be what --
160 in the user's particular society -- is customarily understood to be
161 the name of that user. The distinguished name of a user is the
162 combination of the name of some general object, such as an
163 organization or a geographical unit, with the common name. There are
164 two main problems with this style of name construction.
170 Grimstad, et. al. Informational [Page 3]
172 RFC 2377 A Directory Naming Plan September 1998
175 First, the common name attribute, while seeming to be user-friendly,
176 cannot be used generally as an RDN in practice. In any significant
177 set of users to be named under the same Directory Information Tree
178 (DIT) node there will be collisions on common name. There is no way
179 to overcome this other than either by forcing uniqueness on common
180 names, something they do not possess, or by using an additional
181 attribute to prevent collisions. This additional attribute normally
182 needs to be unique in a much larger context to have any practical
183 value. The end result is a RDN that is very long and unpopular with
186 Second, and more serious, X.500 has not been able to use any
187 significant number of pre-existing names. Since X.500 naming models
188 typically use organization names as part of the hierarchy [2, 3],
189 organization names must be registered. As organization names are
190 frequently tied to trademarks and are used in sales and promotions,
191 registration can be a difficult and acrimonious process.
193 The North American Directory Forum (NADF, now the North Atlantic
194 Directory Forum but still the NADF) proposed to avoid the problem of
195 registration by using names that were already registered in the
196 "civil naming infrastructure" [4][5]. Directory distinguished names
197 would be based on an organization's legal name as recognized by some
198 governmental agency (county clerk, state secretary of state, etc.) or
199 other registering entity such as ANSI.
201 This scheme has the significant advantage of keeping directory
202 service providers out of disputes about the right to use a particular
203 name, but it leads to rather obscure names. Among these obscurities,
204 the legal name almost invariably takes a form that is less familiar
205 and longer than what users typically associate with the organization.
206 For example, in the US a large proportion of legal organization names
207 end with the text ", Inc." as in "Acme, Inc." Moreover, in the case
208 of the US, the civil naming infrastructure does not operate
209 nationally, so the organization names it provides must be located
210 under state and regional DIT nodes, making them difficult to find
211 while browsing the directory. NADF proposes a way to algorithmically
212 derive multi-attribute RDNs which would allow placement of entries or
213 aliases in more convenient places in the DIT, but these derived names
214 are cumbersome and unpopular. For example, suppose Nadir is an
215 organization that is registered in New Jersey civil naming
216 infrastructure under the name "Nadir Networks, Inc." Its civil
217 distinguished name (DN) would then be
219 o="Nadir Networks, Inc.", st=New Jersey, c=US
226 Grimstad, et. al. Informational [Page 4]
228 RFC 2377 A Directory Naming Plan September 1998
231 while its derived name which is unambiguous under c=US directly is
233 o="Nadir Networks, Inc." + st=New Jersey, c=US
235 More generally, the requirement for registration of organizations in
236 X.500 naming has led to the establishment of national registration
237 authorities whose function is mainly limited to assignment of X.500
238 organization names. Because of the very limited attraction of X.500,
239 interest in registering an organization with one of these national
240 authorities has been minimal. Finally, multi-national organizations
241 are frustrated by a lack of an international registration authority.
245 A directory naming plan must provide a guide for the construction of
246 names (identifiers, labels) for directory objects that are
247 unambiguous (identify only one directory object) within some context
248 (namespace), at a minimum within one isolated directory server.
250 A directory object is simply a set of attribute values. The
251 association between a real-world object and a directory object is
252 made by directory-enabled applications and is, in the general case,
255 The following additional naming characteristics are requirements that
256 this naming plan seeks to satisfy:
260 The Internet, consisting of a very large number of objects and
261 management domains, requires hierarchical names. Such names permit
262 delegation in the name assignment process and partitioning of
263 directory information among directory servers.
265 b) friendly to loose coupling of directory servers
267 One purpose of this naming plan is to define a naming pattern that
268 will facilitate one form or another of loose coupling of potentially
269 autonomous directory servers into a larger system.
271 A name in such a loosely-coupled system should unambiguously identify
272 one real-world object. The real-world object may, however, be
273 represented differently (i.e. by different directory objects having
274 different attributes but the same DN) in different (e.g.
275 independently managed) servers in the loosely-coupled system. The
276 plan does not attempt to produce names to overcome this likely
277 scenario. That is, it does not attempt to produce a single namespace
278 for all directory objects. (This issue is considered in more detail
282 Grimstad, et. al. Informational [Page 5]
284 RFC 2377 A Directory Naming Plan September 1998
289 c) readily usable by LDAP clients and servers
291 As of this writing, a substantial number of the Lightweight Directory
292 Access Protocol (LDAP) [6][7] implementations are currently available
293 or soon will be. The names specified by this naming plan should be
294 readily usable by these implementations and applications based on
297 d) friendly to re-use of existing Internet name registries
299 As described in Section 2 above, creation of new global name
300 registries has been highly problematic. Therefore, a fundamental
301 requirement this plan addresses is to enable the reuse of existing
302 Internet name registries such as DNS names and RFC822 mailbox
303 identifiers when constructing directory names.
305 e) minimally user-friendly
307 Although we expect that user interfaces of directory-enabled
308 applications will avoid exposing users to DNs, it is unlikely that
309 users can be totally insulated from them. For this reason, the
310 naming plan should permit use of familiar information in name
311 construction. Minimally, a user should be capable of recognizing the
312 information encoded in his/her own DN. Names that are totally opaque
313 to users cannot meet this requirement.
315 4.0 Name Construction
317 The paper assumes familiarity with the terminology and concepts
318 behind the terms distinguished name (DN) and relative distinguished
319 name (RDN) [2][8][9].
321 We describe how DNs can be constructed using three attribute types,
322 domainComponent (dc), userID (uid) and commonName (cn). They are
323 each described in turn.
325 4.1 Domain Component (dc)
327 The domain component attribute is defined and registered in RFC1274
328 [3][10]. It is used in the construction of a DN from a domain name.
329 Details of the construction algorithm is described in "Using Domains
330 in LDAP Distinguished Names" [1].
332 An organization wishing to deploy a directory following this naming
333 plan would proceed as follows. Consider an organization, for example
334 "Acme, Inc.", having the registered domain name "acme.com". It would
338 Grimstad, et. al. Informational [Page 6]
340 RFC 2377 A Directory Naming Plan September 1998
347 from its domain name. It would then use this DN as the root of its
348 subtree of directory information.
350 The DN itself can be used to identify a directory organization object
351 that represents information about the organization. The directory
352 schema required to enable this is described below in section 5.2.
354 The subordinates of the DN will be directory objects related to the
355 organization. The domain component attribute can be used to name
356 subdivisions of the organization such as organizational units and
357 localities. Acme, for example, might use the domain names
358 "corporate.acme.com" and "richmond.acme.com" to construct the names
360 dc=corporate, dc=acme, dc=com
361 dc=richmond, dc=acme, dc=com
363 under which to place its directory objects. The directory schema
364 required to name organizationalUnit and locality objects in this way
365 is described below in section 5.2.
367 Note that subdivisions of the organization such as organizational
368 units and localities could also be assigned RDNs using the
369 conventional X.500 naming attributes, e.g.
371 ou=corporate, dc=acme, dc=com
372 l=richmond, dc=acme, dc=com.
374 Use of the dc attribute for the RDN of directory objects of class
375 "domain" is also possible [1].
379 The userid (uid) attribute is defined and registered in RFC1274
382 This attribute may be used to construct the RDN for directory objects
383 subordinate to objects named according to the procedure described in
384 Section 4.1. This plan does not constrain how this attribute is
389 The commonName (cn) attribute is defined and registered in X.500
394 Grimstad, et. al. Informational [Page 7]
396 RFC 2377 A Directory Naming Plan September 1998
399 This attribute may be used to construct the RDN for directory objects
400 subordinate to objects named according to the procedure described in
401 Section 4.1. This plan does not constrain how this attribute is
404 4.4 Examples of uid and cn Usage
406 Although this plan places no constraints on the use of the uid and cn
407 attributes for name construction, we would like to offer some
408 suggestions by way of examples.
410 In practice, we have used uid for the RDN for person objects were we
411 could make use of an existing registry of names and cn for other
414 Examples of existing registries of identifiers for person objects are
415 RFC822 mailbox identifiers, employee numbers and employee "handles".
416 Aside from the convenience to administrators of re-use of an existing
417 store of identifiers, if it is ever necessary to display to a user
418 his/her DN, there is some hope that it will be recognizable when such
419 identifiers are used.
421 We have found RFC822 mailbox identifiers a particularly convenient
422 source for name construction. When a person has several e-mail
423 addresses, one will be selected for the purpose of user
424 identification. We call this the "distinguished" e-mail address or
425 the "distinguished" RFC822 mailbox identifier for the user.
427 For example, if there is a user affiliated with the organization Acme
428 having distinguished e-mail address J.Smith@acme.com, the uid
433 The domain component attributes of a user's DN will normally be
434 constructed from the domain name of his/her distinguished e-mail
435 address. That is, for the user uid=J.Smith@acme.com the domain
436 component attributes would typically be:
440 The full LDAP DN for this user would then be:
442 uid=J.Smith@acme.com, dc=acme, dc=com
444 Directory administrators having several RFC822 identifiers to choose
445 from when constructing a DN for a user should consider the following
450 Grimstad, et. al. Informational [Page 8]
452 RFC 2377 A Directory Naming Plan September 1998
455 o Machine-independent addresses are likely to be more stable,
456 resulting in directory names that change less. Thus an
461 may well be preferable to one such as:
463 js@blaster.third-floor.acme.com.
465 o Use of some form of "handle" for the "local" part that is
466 distinct from a user's real name may result in fewer collisions
467 and thereby lessen user pain and suffering. Thus the
472 may well be preferable to one such as:
476 Practical experience with use of the RFC822 mailbox identifier scheme
477 described here has shown that there are situations where it is
478 convenient to use such identifies for all users in a particular
479 population, although a few users do not, in fact, possess working
480 mailboxes. For example, an organization may have a existing unique
481 identification scheme for all employees that is used as a alias to
482 the employees' real mailboxes -- which may be quite heterogeneous in
483 structure. The identification scheme works for all employees to
484 identify unambiguously each employee; it only works as an e-mail
485 alias for those employees having real mailboxes. For this reason it
486 would be a bad assumption for directory-enabled applications to
487 assume the uid to be a valid mailbox; the value(s) of the mail
488 attribute should always be checked.
490 It is important to emphasize that the elements of the domain name of
491 an RFC822 identifier may, BUT NEED NOT, be the same as the domain
492 components of the DN. This means that the domain components provide
493 a degree of freedom to support access control or other directory
494 structuring requirements that need not be mechanically reflected in
495 the user's e-mail address. We do not want under any condition to
496 force the user's e-mail address to change just to facilitate a new
497 system requirement such as a modification in an access control
498 structure. It should also be noted that while we do not require that
499 the domain components match the RFC822 identifier, we DO require that
500 the concatenated domain components form a registered domain name,
501 that is, one that is represented in the DNS. This automatically
502 avoids name conflicts in the directory hierarchy.
506 Grimstad, et. al. Informational [Page 9]
508 RFC 2377 A Directory Naming Plan September 1998
511 To provide an example of a DN which deviates from what might be
512 considered the default structure, consider the following scenario.
514 Suppose that J.Smith needs to be granted special permissions to
515 information in the dc=acme, dc=com part of the LDAP DIT. Since it
516 will be, in general, easier to organize special users by their name
517 structure than via groups (an arbitrary collection of DNs), we use
518 subdomains for this purpose. Suppose the special permissions were
519 required by users in the MIS organizational unit. A subdomain
520 "mis.acme.com" is established, if it does not already exist,
521 according to normal DNS procedures. The special permissions will be
522 granted to users with the name structure:
524 uid=*, dc=mis, dc=acme, dc=com
526 The DN of J.Smith in this case will be:
528 uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com
530 In principal, there is nothing to prevent the domain name elements of
531 the RFC822 identifier from being completely different from the domain
532 components of the DN. For instance, the DN for a J.Smith could be:
534 uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com
536 While we do not REQUIRE that the domain name part of the uid match
537 the dc components of the directory distinguished name, we suggest
538 that this be done where possible. At a minimum, if the most
539 significant pieces of the DN and the uid are the same (i.e.,
540 "dc=acme, dc=com" and "acme.com") the likelihood, based on a
541 knowledge of a user's e-mail address, of discovering an appropriate
542 directory system to contact to find information about the user is
545 The example above represents a situation where this suggestion isn't
546 possible because some of the users in a population have mailbox
547 identifiers that differ from the pattern of the rest of the users,
548 e.g., most mailboxes are of the form local@acme.com, but a
549 subpopulation have mailboxes from an ISP and therefore mailboxes of
550 the form local@worldnet.att.net.
552 5.0 Naming Plan and Directories
554 5.1 Directory Services Considerations
556 We envision the deployment of LDAP-based directory services on the
557 Internet to take the form of loosely coupled LDAP servers. This
558 coupling will occur at two levels.
562 Grimstad, et. al. Informational [Page 10]
564 RFC 2377 A Directory Naming Plan September 1998
567 Firstly, LDAP servers will be loosely connected into islands (i.e. a
568 set of servers sharing a single DN namespace). The glue connecting
569 the islands will be LDAP referral [12] information configured into
570 the LDAP servers. An LDAP search directed to any server in such an
571 island can be answered, if the information is not available to that
572 server, by an LDAP referral to another, more appropriate server
573 within the same island.
575 Secondly, various techniques will be used span LDAP islands. The
576 concept that enables such techniques is the LDAP URL [13]. By
577 combining a DNS host name and port (corresponding to one or more LDAP
578 servers) with a DN, the LDAP URL provides unified high-level
579 identification scheme (an LDAP URL namespace) for directory objects.
581 Because an LDAP referral is expressed as one or more LDAP URL, these
582 two levels of coupling may not sharply distinguished in practice.
584 We do not envision the X.500 model of a single DIT (i.e. a single DN
585 namespace) to be viable in an environment of competing service
586 providers. This naming plan does not attempt to produce DNs to hide
587 the possibility that a given real-world object may have independently
588 managed directory objects with the same DN associated with it.
590 5.2 Directory Schema Implications of the Naming Plan
592 The traditional directory schema(s) developed for the X.500 standard
593 and its application to the Internet [4] require extension to be used
594 with the naming plan developed here. The extensions described below
595 attempt to reuse existing schema elements as much as possible. The
596 directory objects for which extensions are required are:
597 organization, organizational unit, and various classes of leaf
598 objects. We describe the schema modifications below for organization,
599 organizationalUnit and selected leaf classes.
601 So as to continue to use existing structural object classes to the
602 extent possible, we propose supplementing entries based on these
603 classes with additional information from two new auxiliary object
604 classes, dcObject and uidObject. They are specified using the
605 notation in Section 4 of [14].
607 The auxiliary object class dcObject is defined in "Using Domains in
608 LDAP Distinguished Names" [1].
618 Grimstad, et. al. Informational [Page 11]
620 RFC 2377 A Directory Naming Plan September 1998
623 The auxiliary object class uidObject is defined as:
631 5.2.1 Organization Schema
633 The dc attribute is employed to construct the RDN of an organization
634 object. This is enabled by adding the auxiliary class dcObject to
635 the organization's objectClass attribute.
637 5.2.2 Organizational Unit Schema
639 The dc attribute is employed to construct the RDN of an
640 organizationalUnit object (which is subordinate in the DIT to either
641 an organization or an organizationalUnit object). This is enabled by
642 adding the auxiliary class dcObject to the organizational unit's
643 objectClass attribute.
647 No schema extensions are required for person objects if either the
648 inetOrgPerson [15] (preferred) or the newPilotPerson object classes
649 are used. The attribute uid is permissible in each class. For
650 consistency, the uidObject could be added to person entry objectClass
651 attributes to assist applications filtering on this object class
652 attribute value. Use of other classes for person objects with RDN
653 constructed with the uid attribute such as organizationalPerson
654 requires the use of the uidObject class.
656 It has been traditional in X.500 and LDAP directory services to
657 employ the common name (cn) attribute in naming. While this naming
658 plan doesn't require use of the cn attribute in naming, it should be
659 stressed that it is a required attribute in any class derived from
660 the person class and is still quite important. It will play a
661 significant role in enabling searches to find user entries of
664 5.2.4 Certification Authority Schema
666 The certification authority (CA) object class is an auxiliary class,
667 meaning it is essentially a set of additional attributes for a base
668 class such as organizationalRole, organization, organizationalUnit or
669 person. Except in the case where the base structural class is
670 inetOrgPerson, use of the uid attribute to construct the RDN of a CA
674 Grimstad, et. al. Informational [Page 12]
676 RFC 2377 A Directory Naming Plan September 1998
679 will require the auxiliary class uidObject to permit the uid
680 attribute to be used. In the cases where organizationalUnit or
681 organization is the base class for a CA, use of the auxiliary class
682 dcObject will permit the RDN of the CA to be a domain component.
684 5.2.5 Server and Server Application Schema
686 Servers and server applications are typically represented, for want
687 of anything better, by entries of the object class applicationProcess
688 (or a class derived from it). Sometimes the class applicationEntity
689 is used. In either case, the uid attribute should probably not be
690 employed to construct the RDN of a server or server application
691 object. The standard schema uses the attribute cn for such RDNs.
693 Suppose one wants to use this naming plan both in the construction of
694 DNs for SSL server certificates and for their storage in a directory.
695 It is customary for clients connecting via SSL to compare the
696 server's domain name (e.g. from the URL used to contact the server)
697 with the value of the cn attribute in the subject field (i.e.
698 subject's DN) of the server's certificate. For this reason, it is
699 common practice to set the cn attribute to the server's domain name.
701 The naming and schema to handle this situation is best explained by
702 an example. Consider the server "host.acme.com". Following the
703 algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN
704 dc=host, dc=acme, dc=com is constructed. To conform to the existing
705 practices just described, the server's subject DN for the SSL server
706 certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and
707 the server's certificate should be stored in a directory entry with
708 this name. This entry should use application process or application
709 entity as its structural object class and strong authentication user
710 as is auxiliary class.
714 For X.500 servers or LDAP servers following the X.500 model, our
715 schema requires the definition of new name forms, structure rules,
716 and DIT content rules. Structure rules and DIT content rules are
717 locally defined, and do not involve a globally significant object
720 The following name forms are defined using the syntax of section 6.22
721 of [14] for the convenience of those using such servers.
723 Note that since the structural object classes organization,
724 organizationalUnit, locality and organizationalPerson do not permit
725 inclusion of the dc attribute, an auxiliary object class such as
726 dcObject [1] must be used for instances of these classes.)
730 Grimstad, et. al. Informational [Page 13]
732 RFC 2377 A Directory Naming Plan September 1998
735 5.2.6.1 Name Form for Domain Objects
737 The OIDs in this group are under the
738 iso.org.dod.internet.directory.NameForm branch of the OID tree
746 The domainNameForm name form indicates that objects of structural
747 object class domain have their RDN constructed from a value of the
750 5.2.6.2 Name Form for Organization Objects
753 NAME dcOrganizationNameForm
757 The dcOrganizationNameForm name form indicates that objects of
758 structural object class organization have their RDN constructed from
759 a value of the attribute dc.
761 5.2.6.3 Name Form for Organizational Unit Objects
764 NAME dcOrganizationalUnitNameForm
765 OC organizationalUnit
768 The dcOrganizationalUnitNameForm name form indicates that objects of
769 structural object class organizationalUnit have their RDN constructed
770 from a value of the attribute dc.
772 5.2.6.4 Name Form for Locality Objects
775 NAME dcLocalityNameForm
779 The dcLocalityNameForm name form indicates that objects of structural
780 object class locality have their RDN constructed from a value of the
786 Grimstad, et. al. Informational [Page 14]
788 RFC 2377 A Directory Naming Plan September 1998
791 5.2.6.5 Name Form for Organizational Person Objects
794 NAME uidOrganizationalPersonNameForm
795 OC organizationalPerson
798 The uidOrganizationalPersonNameForm name form indicates that objects
799 of structural object class organizationalPerson have their RDN
800 constructed from a value of the attribute uid.
802 6.0 Security Considerations
804 Although access controls may be placed on portions of the DIT to deny
805 browse access to unauthorized clients, it may be possible to infer
806 directory names and DIT structure in such sensitive portions of the
807 DIT from the results of DNS queries. Providing public visibility to
808 some portions of the DIT may assist those make such inferences.
812 This plan has emerged in the course of a number of fruitful
813 discussions, especially with David Chadwick, John Dale, Joe Gajewski,
814 Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.
818 [1] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
819 Sataluri, "Using Domains in LDAP Distinguished Names", RFC
822 [2] X.500: The Directory -- Overview of Concepts, Models, and
823 Service, CCITT Recommendation X.500, December, 1988.
825 [3] Barker, P., and S. Kille, "The COSINE and Internet X.500
826 Schema", RFC 1274, November 1991.
828 [4] The North American Directory Forum, "A Naming Scheme for
829 c=US", RFC 1255, September 1991.
831 [5] The North American Directory Forum, "NADF Standing Documents:
832 A Brief Overview", RFC 1417, February 1993.
834 [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
835 Access Protocol", RFC 1777, March 1995.
837 [7] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
838 Access Protocol (v3)", RFC 2251, December 1997.
842 Grimstad, et. al. Informational [Page 15]
844 RFC 2377 A Directory Naming Plan September 1998
847 [8] Kille, S., "A String Representation of Distinguished Names",
848 RFC 1779, March 1995.
850 [9] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
851 Access Protocol (v3): UTF-8 String Representation of
852 Distinguished Names", RFC 2253, December 1997.
854 [10] Wahl, M., "A Summary of the Pilot X.500 Schema for use
855 in LDAPv3", Work in Progress.
857 [11] Wahl, M., "A Summary of the X.500 User Schema for use with
858 LDAPv3", RFC 2256, December 1997.
860 [12] Howes, T., and M. Wahl, "Referrals and Knowledge References
861 in LDAP Directories", Work in Progress.
863 [13] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
866 [14] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
867 "Lightweight Directory Access Protocol (v3): Attribute Syntax
868 Definitions", RFC 2252, December 1997.
870 [15] Smith, M., "Definition of the inetOrgPerson Object Class",
898 Grimstad, et. al. Informational [Page 16]
900 RFC 2377 A Directory Naming Plan September 1998
903 12. Authors' Addresses
907 Room 1C-429, 101 Crawfords Corner Road
908 Holmdel, NJ 07733-3030
916 Room 1B-433, 101 Crawfords Corner Road
917 Holmdel, NJ 07733-3030
925 Room 4D-335, 101 Crawfords Corner Road
926 Holmdel, NJ 07733-3030
929 EMail: srs@lucent.com
934 4815 W Braker Lane #502-385
938 EMail: M.Wahl@critical-angle.com
954 Grimstad, et. al. Informational [Page 17]
956 RFC 2377 A Directory Naming Plan September 1998
959 13. Full Copyright Statement
961 Copyright (C) The Internet Society (1998). All Rights Reserved.
963 This document and translations of it may be copied and furnished to
964 others, and derivative works that comment on or otherwise explain it
965 or assist in its implementation may be prepared, copied, published
966 and distributed, in whole or in part, without restriction of any
967 kind, provided that the above copyright notice and this paragraph are
968 included on all such copies and derivative works. However, this
969 document itself may not be modified in any way, such as by removing
970 the copyright notice or references to the Internet Society or other
971 Internet organizations, except as needed for the purpose of
972 developing Internet standards in which case the procedures for
973 copyrights defined in the Internet Standards process must be
974 followed, or as required to translate it into languages other than
977 The limited permissions granted above are perpetual and will not be
978 revoked by the Internet Society or its successors or assigns.
980 This document and the information contained herein is provided on an
981 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
982 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
983 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
984 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
985 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1010 Grimstad, et. al. Informational [Page 18]
projects / openldap / blob