Training courses

Kernel and Embedded Linux

Bootlin training courses

Embedded Linux, kernel,
Yocto Project, Buildroot, real-time,
graphics, boot time, debugging...

Bootlin logo

Elixir Cross Referencer

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011






Network Working Group                                        A. Grimstad
Request for Comments: 2377                                      R. Huber
Category: Informational                                             AT&T
                                                             S. Sataluri
                                                     Lucent Technologies
                                                                 M. Wahl
                                                     Critical Angle Inc.
                                                          September 1998


        Naming Plan for Internet Directory-Enabled Applications

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   Application of the conventional X.500 approach to naming has
   heretofore, in the experience of the authors, proven to be an
   obstacle to the wide deployment of directory-enabled applications on
   the Internet.  We propose a new directory naming plan that leverages
   the strengths of the most popular and successful Internet naming
   schemes for naming objects in a hierarchical directory.  This plan
   can, we believe, by extending the X.500 approach to naming,
   facilitate the creation of an Internet White Pages Service (IWPS) and
   other directory-enabled applications by overcoming the problems
   encountered by those using the conventional X.500 approach.

1.0 Executive Summary

   Application of the conventional X.500 approach to naming has
   heretofore, in the experience of the authors, proven to be an
   obstacle to the wide deployment of directory-enabled applications on
   the Internet.  The required registration infrastructure is either
   non-existent or largely ignored.  The infrastructure that does exist
   is cumbersome to use and tends to produce counterproductive results.
   The attributes used for naming have been confusing for users and
   inflexible to managers and operators of directory servers.






Grimstad, et. al.            Informational                      [Page 1]

RFC 2377                A Directory Naming Plan           September 1998


   This paper describes a directory naming plan for the construction of
   an Internet directory infrastructure to support directory-enabled
   applications that can serve as an alternative (or extension) to the
   conventional X.500 approach.

   The plan has the following two main features.  First, it bases the
   root and upper portions of the name hierarchy on the existing
   infrastructure of names from the Domain Name System (DNS). This
   component of the plan makes use of the ideas described in the
   companion paper to this plan, "Using Domains in LDAP Distinguished
   Names" [1].  And second, it provides a number of options for the
   assignment of names to directory leaf objects such as person objects,
   including an option that allows the reuse of existing Internet
   identifiers for people.

   Just as the conventional X.500 style of naming is not a formal
   standard, use of the naming plan described here is not obligatory for
   directory-enabled applications on the Internet. Other approaches are
   permissible. However, we believe widespread use of this plan will
   largely eliminate naming as a typically thorny issue when
   administrators set up an LDAP-based directory service.  Further, we
   strongly encourage developers of directory-enabled products,
   especially LDAP clients and user interfaces, to assume that this
   naming plan will see widespread use and design their products
   accordingly.

   Here, in summary, is our proposal.

   The upper portions of the hierarchical directory tree should be
   constructed using the components of registered DNS names using the
   domain component attribute "dc".  The directory name for the
   organization having the domain name "acme.com" will then be, e.g.,

      dc=acme, dc=com

   Organizations can add additional directory structure, for example to
   support implementation of access control lists or partitioning of
   their directory information, by using registered subdomains of DNS
   names, e.g., the subdomain "corporate.acme.com" can be used as the
   basis for the directory name

      dc=corporate, dc=acme, dc=com

   For naming directory leaf objects such as persons, groups, server
   applications and certification authorities in a hierarchical
   directory, we propose the use of either the "uid" (user identifier)
   or the "cn" (common name) attribute for the relative distinguished
   name. This plan does not constrain how these two attributes are used.



Grimstad, et. al.            Informational                      [Page 2]

RFC 2377                A Directory Naming Plan           September 1998


   One approach to their use, for example, is to employ the uid
   attribute as the RDN when reusing an existing store of identifiers
   and the cn attribute as the RDN when creating new identifiers
   specifically for the directory.  A convenient existing identification
   scheme for person objects is the RFC822 mailbox identifier. So an RDN
   for person employing this store of identifiers would be, e.g.,

      uid=John.Smith@acme.com

   For leaf objects not conveniently identified with such a scheme, the
   "cn" attribute is used, e.g.,

      cn=Reading Room

   Directory distinguished names will thus have the following structure,
   e.g.,

      uid=John.Smith@acme.com, dc=acme, dc=com
      uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
      uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com
      cn=Reading Room, dc=physics, dc=national-lab, dc=edu

2.0 The Problem

   The X.500 Directory model [2] can be used to create a world-wide
   distributed directory. The Internet X.500 Directory Pilot has been
   operational for several years and has grown to a size of about 1.5
   million entries of varying quality.  The rate of growth of the pilot
   is far lower than the rate of growth of the Internet during the pilot
   period.

   There are a substantial number of contributing factors that have
   inhibited the growth of this pilot.  The common X.500 approach to
   naming, while not the preponderant problem, has contributed in
   several ways to limit the growth of an Internet White Pages Service
   based on X.500.

   The conventional way to construct names in the X.500 community is
   documented as an informative (i.e., not officially standardized)
   Annex B to X.521. The relative distinguished name (RDN) of a user
   consists of a common name (cn) attribute. This is meant to be what --
   in the user's particular society -- is customarily understood to be
   the name of that user. The distinguished name of a user is the
   combination of the name of some general object, such as an
   organization or a geographical unit, with the common name. There are
   two main problems with this style of name construction.





Grimstad, et. al.            Informational                      [Page 3]

RFC 2377                A Directory Naming Plan           September 1998


   First, the common name attribute, while seeming to be user-friendly,
   cannot be used generally as an RDN in practice.  In any significant
   set of users to be named under the same Directory Information Tree
   (DIT) node there will be collisions on common name.  There is no way
   to overcome this other than either by forcing uniqueness on common
   names, something they do not possess, or by using an additional
   attribute to prevent collisions.  This additional attribute normally
   needs to be unique in a much larger context to have any practical
   value.  The end result is a RDN that is very long and unpopular with
   users.

   Second, and more serious, X.500 has not been able to use any
   significant number of pre-existing names.  Since X.500 naming models
   typically use organization names as part of the hierarchy [2, 3],
   organization names must be registered.  As organization names are
   frequently tied to trademarks and are used in sales and promotions,
   registration can be a difficult and acrimonious process.

   The North American Directory Forum (NADF, now the North Atlantic
   Directory Forum but still the NADF) proposed to avoid the problem of
   registration by using names that were already registered in the
   "civil naming infrastructure" [4][5].  Directory distinguished names
   would be based on an organization's legal name as recognized by some
   governmental agency (county clerk, state secretary of state, etc.) or
   other registering entity such as ANSI.

   This scheme has the significant advantage of keeping directory
   service providers out of disputes about the right to use a particular
   name, but it leads to rather obscure names.  Among these obscurities,
   the legal name almost invariably takes a form that is less familiar
   and longer than what users typically associate with the organization.
   For example, in the US a large proportion of legal organization names
   end with the text ", Inc." as in "Acme, Inc."  Moreover, in the case
   of the US, the civil naming infrastructure does not operate
   nationally, so the organization names it provides must be located
   under state and regional DIT nodes, making them difficult to find
   while browsing the directory.  NADF proposes a way to algorithmically
   derive multi-attribute RDNs which would allow placement of entries or
   aliases in more convenient places in the DIT, but these derived names
   are cumbersome and unpopular.  For example, suppose Nadir is an
   organization that is registered in New Jersey civil naming
   infrastructure under the name "Nadir Networks, Inc."  Its civil
   distinguished name (DN) would then be

      o="Nadir Networks, Inc.", st=New Jersey, c=US






Grimstad, et. al.            Informational                      [Page 4]

RFC 2377                A Directory Naming Plan           September 1998


   while its derived name which is unambiguous under c=US directly is

      o="Nadir Networks, Inc." + st=New Jersey, c=US

   More generally, the requirement for registration of organizations in
   X.500 naming has led to the establishment of national registration
   authorities whose function is mainly limited to assignment of X.500
   organization names.  Because of the very limited attraction of X.500,
   interest in registering an organization with one of these national
   authorities has been minimal.  Finally, multi-national organizations
   are frustrated by a lack of an international registration authority.

3.0 Requirements

   A directory naming plan must provide a guide for the construction of
   names (identifiers, labels) for directory objects that are
   unambiguous (identify only one directory object) within some context
   (namespace), at a minimum within one isolated directory server.

   A directory object is simply a set of attribute values. The
   association between a real-world object and a directory object is
   made by directory-enabled applications and is, in the general case,
   one to many.

   The following additional naming characteristics are requirements that
   this naming plan seeks to satisfy:

   a) hierarchical

   The Internet, consisting of a very large number of objects and
   management domains, requires hierarchical names.  Such names permit
   delegation in the name assignment process and partitioning of
   directory information among directory servers.

   b) friendly to loose coupling of directory servers

   One purpose of this naming plan is to define a naming pattern that
   will facilitate one form or another of loose coupling of potentially
   autonomous directory servers into a larger system.

   A name in such a loosely-coupled system should unambiguously identify
   one real-world object.  The real-world object may, however, be
   represented differently (i.e. by different directory objects having
   different attributes but the same DN) in different (e.g.
   independently managed) servers in the loosely-coupled system.  The
   plan does not attempt to produce names to overcome this likely
   scenario.  That is, it does not attempt to produce a single namespace
   for all directory objects. (This issue is considered in more detail



Grimstad, et. al.            Informational                      [Page 5]

RFC 2377                A Directory Naming Plan           September 1998


   in Section 5.1.)

   c) readily usable by LDAP clients and servers

   As of this writing, a substantial number of the Lightweight Directory
   Access Protocol (LDAP) [6][7] implementations are currently available
   or soon will be.  The names specified by this naming plan should be
   readily usable by these implementations and applications based on
   them.

   d) friendly to re-use of existing Internet name registries

   As described in Section 2 above, creation of new global name
   registries has been highly problematic.  Therefore, a fundamental
   requirement this plan addresses is to enable the reuse of existing
   Internet name registries such as DNS names and RFC822 mailbox
   identifiers when constructing directory names.

   e) minimally user-friendly

   Although we expect that user interfaces of directory-enabled
   applications will avoid exposing users to DNs, it is unlikely that
   users can be totally insulated from them.  For this reason, the
   naming plan should permit use of familiar information in name
   construction.  Minimally, a user should be capable of recognizing the
   information encoded in his/her own DN.  Names that are totally opaque
   to users cannot meet this requirement.

4.0 Name Construction

   The paper assumes familiarity with the terminology and concepts
   behind the terms distinguished name (DN) and relative distinguished
   name (RDN) [2][8][9].

   We describe how DNs can be constructed using three attribute types,
   domainComponent (dc), userID (uid) and commonName (cn).  They are
   each described in turn.

4.1 Domain Component (dc)

   The domain component attribute is defined and registered in RFC1274
   [3][10].  It is used in the construction of a DN from a domain name.
   Details of the construction algorithm is described in "Using Domains
   in LDAP Distinguished Names" [1].

   An organization wishing to deploy a directory following this naming
   plan would proceed as follows.  Consider an organization, for example
   "Acme, Inc.", having the registered domain name "acme.com".  It would



Grimstad, et. al.            Informational                      [Page 6]

RFC 2377                A Directory Naming Plan           September 1998


   construct the DN

      dc=acme, dc=com

   from its domain name.  It would then use this DN as the root of its
   subtree of directory information.

   The DN itself can be used to identify a directory organization object
   that represents information about the organization. The directory
   schema required to enable this is described below in section 5.2.

   The subordinates of the DN will be directory objects related to the
   organization.  The domain component attribute can be used to name
   subdivisions of the organization such as organizational units and
   localities.  Acme, for example, might use the domain names
   "corporate.acme.com" and "richmond.acme.com" to construct the names

      dc=corporate, dc=acme, dc=com
      dc=richmond, dc=acme, dc=com

   under which to place its directory objects.  The directory schema
   required to name organizationalUnit and locality objects in this way
   is described below in section 5.2.

   Note that subdivisions of the organization such as organizational
   units and localities could also be assigned RDNs using the
   conventional X.500 naming attributes, e.g.

      ou=corporate, dc=acme, dc=com
      l=richmond, dc=acme, dc=com.

   Use of the dc attribute for the RDN of directory objects of class
   "domain" is also possible [1].

4.2 User ID (uid)

   The userid (uid) attribute is defined and registered in RFC1274
   [3][10].

   This attribute may be used to construct the RDN for directory objects
   subordinate to objects named according to the procedure described in
   Section 4.1.  This plan does not constrain how this attribute is
   used.

4.3 Common Name (cn)

   The commonName (cn) attribute is defined and registered in X.500
   [3][11].



Grimstad, et. al.            Informational                      [Page 7]

RFC 2377                A Directory Naming Plan           September 1998


   This attribute may be used to construct the RDN for directory objects
   subordinate to objects named according to the procedure described in
   Section 4.1.  This plan does not constrain how this attribute is
   used.

4.4 Examples of uid and cn Usage

   Although this plan places no constraints on the use of the uid and cn
   attributes for name construction, we would like to offer some
   suggestions by way of examples.

   In practice, we have used uid for the RDN for person objects were we
   could make use of an existing registry of names and cn for other
   objects.

   Examples of existing registries of identifiers for person objects are
   RFC822 mailbox identifiers, employee numbers and employee "handles".
   Aside from the convenience to administrators of re-use of an existing
   store of identifiers, if it is ever necessary to display to a user
   his/her DN, there is some hope that it will be recognizable when such
   identifiers are used.

   We have found RFC822 mailbox identifiers a particularly convenient
   source for name construction.  When a person has several e-mail
   addresses, one will be selected for the purpose of user
   identification.  We call this the "distinguished" e-mail address or
   the "distinguished" RFC822 mailbox identifier for the user.

   For example, if there is a user affiliated with the organization Acme
   having distinguished e-mail address J.Smith@acme.com, the uid
   attribute will be:

      uid=J.Smith@acme.com

   The domain component attributes of a user's DN will normally be
   constructed from the domain name of his/her distinguished e-mail
   address.  That is, for the user uid=J.Smith@acme.com the domain
   component attributes would typically be:

      dc=acme, dc=com

   The full LDAP DN for this user would then be:

      uid=J.Smith@acme.com, dc=acme, dc=com

   Directory administrators having several RFC822 identifiers to choose
   from when constructing a DN for a user should consider the following
   factors:



Grimstad, et. al.            Informational                      [Page 8]

RFC 2377                A Directory Naming Plan           September 1998


      o Machine-independent addresses are likely to be more stable,
        resulting in directory names that change less. Thus an
        identifier such as:

            js@acme.com

        may well be preferable to one such as:

            js@blaster.third-floor.acme.com.

      o Use of some form of "handle" for the "local" part that is
        distinct from a user's real name may result in fewer collisions
        and thereby lessen user pain and suffering.  Thus the
        identifier:

            js@acme.com

        may well be preferable to one such as:

            J.Smith@acme.com

   Practical experience with use of the RFC822 mailbox identifier scheme
   described here has shown that there are situations where it is
   convenient to use such identifies for all users in a particular
   population, although a few users do not, in fact, possess working
   mailboxes.  For example, an organization may have a existing unique
   identification scheme for all employees that is used as a alias to
   the employees' real mailboxes -- which may be quite heterogeneous in
   structure.  The identification scheme works for all employees to
   identify unambiguously each employee; it only works as an e-mail
   alias for those employees having real mailboxes.  For this reason it
   would be a bad assumption for directory-enabled applications to
   assume the uid to be a valid mailbox; the value(s) of the mail
   attribute should always be checked.

   It is important to emphasize that the elements of the domain name of
   an RFC822 identifier may, BUT NEED NOT, be the same as the domain
   components of the DN.  This means that the domain components provide
   a degree of freedom to support access control or other directory
   structuring requirements that need not be mechanically reflected in
   the user's e-mail address.  We do not want under any condition to
   force the user's e-mail address to change just to facilitate a new
   system requirement such as a modification in an access control
   structure.  It should also be noted that while we do not require that
   the domain components match the RFC822 identifier, we DO require that
   the concatenated domain components form a registered domain name,
   that is, one that is represented in the DNS. This automatically
   avoids name conflicts in the directory hierarchy.



Grimstad, et. al.            Informational                      [Page 9]

RFC 2377                A Directory Naming Plan           September 1998


   To provide an example of a DN which deviates from what might be
   considered the default structure, consider the following scenario.

   Suppose that J.Smith needs to be granted special permissions to
   information in the dc=acme, dc=com part of the LDAP DIT.  Since it
   will be, in general, easier to organize special users by their name
   structure than via groups (an arbitrary collection of DNs), we use
   subdomains for this purpose.  Suppose the special permissions were
   required by users in the MIS organizational unit.  A subdomain
   "mis.acme.com" is established, if it does not already exist,
   according to normal DNS procedures.  The special permissions will be
   granted to users with the name structure:

      uid=*, dc=mis, dc=acme, dc=com

   The DN of J.Smith in this case will be:

      uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com

   In principal, there is nothing to prevent the domain name elements of
   the RFC822 identifier from being completely different from the domain
   components of the DN.  For instance, the DN for a J.Smith could be:

      uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com

   While we do not REQUIRE that the domain name part of the uid match
   the dc components of the directory distinguished name, we suggest
   that this be done where possible. At a minimum, if the most
   significant pieces of the DN and the uid are the same (i.e.,
   "dc=acme, dc=com" and "acme.com") the likelihood, based on a
   knowledge of a user's e-mail address, of discovering an appropriate
   directory system to contact to find information about the user is
   greatly enhanced.

   The example above represents a situation where this suggestion isn't
   possible because some of the users in a population have mailbox
   identifiers that differ from the pattern of the rest of the users,
   e.g., most mailboxes are of the form local@acme.com, but a
   subpopulation have mailboxes from an ISP and therefore mailboxes of
   the form local@worldnet.att.net.

5.0 Naming Plan and Directories

5.1 Directory Services Considerations

   We envision the deployment of LDAP-based directory services on the
   Internet to take the form of loosely coupled LDAP servers. This
   coupling will occur at two levels.



Grimstad, et. al.            Informational                     [Page 10]

RFC 2377                A Directory Naming Plan           September 1998


   Firstly, LDAP servers will be loosely connected into islands (i.e. a
   set of servers sharing a single DN namespace). The glue connecting
   the islands will be LDAP referral [12] information configured into
   the LDAP servers. An LDAP search directed to any server in such an
   island can be answered, if the information is not available to that
   server, by an LDAP referral to another, more appropriate server
   within the same island.

   Secondly, various techniques will be used span LDAP islands. The
   concept that enables such techniques is the LDAP URL [13]. By
   combining a DNS host name and port (corresponding to one or more LDAP
   servers) with a DN, the LDAP URL provides unified high-level
   identification scheme (an LDAP URL namespace) for directory objects.

   Because an LDAP referral is expressed as one or more LDAP URL, these
   two levels of coupling may not sharply distinguished in practice.

   We do not envision the X.500 model of a single DIT (i.e. a single DN
   namespace) to be viable in an environment of competing service
   providers.  This naming plan does not attempt to produce DNs to hide
   the possibility that a given real-world object may have independently
   managed directory objects with the same DN associated with it.

5.2 Directory Schema Implications of the Naming Plan

   The traditional directory schema(s) developed for the X.500 standard
   and its application to the Internet [4] require extension to be used
   with the naming plan developed here. The extensions described below
   attempt to reuse existing schema elements as much as possible. The
   directory objects for which extensions are required are:
   organization, organizational unit, and various classes of leaf
   objects. We describe the schema modifications below for organization,
   organizationalUnit and selected leaf classes.

   So as to continue to use existing structural object classes to the
   extent possible, we propose supplementing entries based on these
   classes with additional information from two new auxiliary object
   classes, dcObject and uidObject. They are specified using the
   notation in Section 4 of [14].

   The auxiliary object class dcObject is defined in "Using Domains in
   LDAP Distinguished Names" [1].









Grimstad, et. al.            Informational                     [Page 11]

RFC 2377                A Directory Naming Plan           September 1998


   The auxiliary object class uidObject is defined as:

   ( 1.3.6.1.1.3.1
     NAME uidObject
     SUP top
     AUXILIARY
     MUST uid )

5.2.1 Organization Schema

   The dc attribute is employed to construct the RDN of an organization
   object.  This is enabled by adding the auxiliary class dcObject to
   the organization's objectClass attribute.

5.2.2 Organizational Unit Schema

   The dc attribute is employed to construct the RDN of an
   organizationalUnit object (which is subordinate in the DIT to either
   an organization or an organizationalUnit object).  This is enabled by
   adding the auxiliary class dcObject to the organizational unit's
   objectClass attribute.

5.2.3 Person Schema

   No schema extensions are required for person objects if either the
   inetOrgPerson [15] (preferred) or the newPilotPerson object classes
   are used. The attribute uid is permissible in each class. For
   consistency, the uidObject could be added to person entry objectClass
   attributes to assist applications filtering on this object class
   attribute value. Use of other classes for person objects with RDN
   constructed with the uid attribute such as organizationalPerson
   requires the use of the uidObject class.

   It has been traditional in X.500 and LDAP directory services to
   employ the common name (cn) attribute in naming.  While this naming
   plan doesn't require use of the cn attribute in naming, it should be
   stressed that it is a required attribute in any class derived from
   the person class and is still quite important.  It will play a
   significant role in enabling searches to find user entries of
   interest.

5.2.4 Certification Authority Schema

   The certification authority (CA) object class is an auxiliary class,
   meaning it is essentially a set of additional attributes for a base
   class such as organizationalRole, organization, organizationalUnit or
   person.  Except in the case where the base structural class is
   inetOrgPerson, use of the uid attribute to construct the RDN of a CA



Grimstad, et. al.            Informational                     [Page 12]

RFC 2377                A Directory Naming Plan           September 1998


   will require the auxiliary class uidObject to permit the uid
   attribute to be used. In the cases where organizationalUnit or
   organization is the base class for a CA, use of the auxiliary class
   dcObject will permit the RDN of the CA to be a domain component.

5.2.5 Server and Server Application Schema

   Servers and server applications are typically represented, for want
   of anything better, by entries of the object class applicationProcess
   (or a class derived from it).  Sometimes the class applicationEntity
   is used.  In either case, the uid attribute should probably not be
   employed to construct the RDN of a server or server application
   object.  The standard schema uses the attribute cn for such RDNs.

   Suppose one wants to use this naming plan both in the construction of
   DNs for SSL server certificates and for their storage in a directory.
   It is customary for clients connecting via SSL to compare the
   server's domain name (e.g. from the URL used to contact the server)
   with the value of the cn attribute in the subject field (i.e.
   subject's DN) of the server's certificate. For this reason, it is
   common practice to set the cn attribute to the server's domain name.

   The naming and schema to handle this situation is best explained by
   an example. Consider the server "host.acme.com". Following the
   algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN
   dc=host, dc=acme, dc=com is constructed. To conform to the existing
   practices just described, the server's subject DN for the SSL server
   certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and
   the server's certificate should be stored in a directory entry with
   this name. This entry should use application process or application
   entity as its structural object class and strong authentication user
   as is auxiliary class.

5.2.6 Name Forms

   For X.500 servers or LDAP servers following the X.500 model, our
   schema requires the definition of new name forms, structure rules,
   and DIT content rules.  Structure rules and DIT content rules are
   locally defined, and do not involve a globally significant object
   identifier.

   The following name forms are defined using the syntax of section 6.22
   of [14] for the convenience of those using such servers.

   Note that since the structural object classes organization,
   organizationalUnit, locality and organizationalPerson do not permit
   inclusion of the dc attribute, an auxiliary object class such as
   dcObject [1] must be used for instances of these classes.)



Grimstad, et. al.            Informational                     [Page 13]

RFC 2377                A Directory Naming Plan           September 1998


5.2.6.1 Name Form for Domain Objects

   The OIDs in this group are under the
   iso.org.dod.internet.directory.NameForm branch of the OID tree
   (1.3.6.1.1.2).

   ( 1.3.6.1.1.2.1
     NAME domainNameForm
     OC domain
     MUST dc )

   The domainNameForm name form indicates that objects of structural
   object class domain have their RDN constructed from a value of the
   attribute dc.

5.2.6.2 Name Form for Organization Objects

   ( 1.3.6.1.1.2.2
     NAME dcOrganizationNameForm
     OC organization
     MUST dc )

   The dcOrganizationNameForm name form indicates that objects of
   structural object class organization have their RDN constructed from
   a value of the attribute dc.

5.2.6.3 Name Form for Organizational Unit Objects

   ( 1.3.6.1.1.2.3
     NAME dcOrganizationalUnitNameForm
     OC organizationalUnit
     MUST dc )

   The dcOrganizationalUnitNameForm name form indicates that objects of
   structural object class organizationalUnit have their RDN constructed
   from a value of the attribute dc.

5.2.6.4 Name Form for Locality Objects

   ( 1.3.6.1.1.2.4
     NAME dcLocalityNameForm
     OC locality
     MUST dc )

   The dcLocalityNameForm name form indicates that objects of structural
   object class locality have their RDN constructed from a value of the
   attribute dc.




Grimstad, et. al.            Informational                     [Page 14]

RFC 2377                A Directory Naming Plan           September 1998


5.2.6.5 Name Form for Organizational Person Objects

   ( 1.3.6.1.1.2.5
     NAME uidOrganizationalPersonNameForm
     OC organizationalPerson
     MUST uid )

   The uidOrganizationalPersonNameForm name form indicates that objects
   of structural object class organizationalPerson have their RDN
   constructed from a value of the attribute uid.

6.0 Security Considerations

   Although access controls may be placed on portions of the DIT to deny
   browse access to unauthorized clients, it may be possible to infer
   directory names and DIT structure in such sensitive portions of the
   DIT from the results of DNS queries. Providing public visibility to
   some portions of the DIT may assist those make such inferences.

7.0 Acknowledgments

   This plan has emerged in the course of a number of fruitful
   discussions, especially with David Chadwick, John Dale, Joe Gajewski,
   Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.

8.0 References

   [1]     Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
           Sataluri, "Using Domains in LDAP Distinguished Names", RFC
           2247, January 1998.

   [2]     X.500: The Directory -- Overview of Concepts, Models, and
           Service, CCITT Recommendation X.500, December, 1988.

   [3]     Barker, P., and S. Kille, "The COSINE and Internet X.500
           Schema", RFC 1274, November 1991.

   [4]     The North American Directory Forum, "A Naming Scheme for
           c=US", RFC 1255, September 1991.

   [5]     The North American Directory Forum, "NADF Standing Documents:
           A Brief Overview", RFC 1417, February 1993.

   [6]     Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
           Access Protocol", RFC 1777, March 1995.

   [7]     Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
           Access Protocol (v3)", RFC 2251, December 1997.



Grimstad, et. al.            Informational                     [Page 15]

RFC 2377                A Directory Naming Plan           September 1998


   [8]     Kille, S., "A String Representation of Distinguished Names",
           RFC 1779, March 1995.

   [9]     Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
           Access Protocol (v3): UTF-8 String Representation of
           Distinguished Names", RFC 2253, December 1997.

   [10]    Wahl, M., "A Summary of the Pilot X.500 Schema for use
           in LDAPv3", Work in Progress.

   [11]    Wahl, M., "A Summary of the X.500 User Schema for use with
           LDAPv3", RFC 2256, December 1997.

   [12]    Howes, T., and M. Wahl, "Referrals and Knowledge References
           in LDAP Directories", Work in Progress.

   [13]    Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
           December 1997.

   [14]    Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
           "Lightweight Directory Access Protocol (v3): Attribute Syntax
           Definitions", RFC 2252, December 1997.

   [15]    Smith, M., "Definition of the inetOrgPerson Object Class",
           Work in Progress.


























Grimstad, et. al.            Informational                     [Page 16]

RFC 2377                A Directory Naming Plan           September 1998


12.  Authors' Addresses

   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
   Lucent Technologies
   Room 4D-335, 101 Crawfords Corner Road
   Holmdel, NJ 07733-3030
   USA

   EMail:  srs@lucent.com


   Mark Wahl
   Critical Angle Inc.
   4815 W Braker Lane #502-385
   Austin, TX 78759
   USA

   EMail:  M.Wahl@critical-angle.com















Grimstad, et. al.            Informational                     [Page 17]

RFC 2377                A Directory Naming Plan           September 1998


13.  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.
























Grimstad, et. al.            Informational                     [Page 18]