File: rfc2798.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1123 lines) | stat: -rw-r--r-- 32,929 bytes parent folder | download | duplicates (9)
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
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123






Network Working Group                                          M. Smith
Request for Comments: 2798                      Netscape Communications
Category: Informational                                      April 2000


           Definition of the inetOrgPerson LDAP Object Class

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 (2000).  All Rights Reserved.

Abstract

   While the X.500 standards define many useful attribute types [X520]
   and object classes [X521], they do not define a person object class
   that meets the requirements found in today's Internet and Intranet
   directory service deployments.  We define a new object class called
   inetOrgPerson for use in LDAP and X.500 directory services that
   extends the X.521 standard organizationalPerson class to meet these
   needs.

























Smith                        Informational                      [Page 1]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


Table of Contents

   1.     Background and Intended Usage...............................2
   2.     New Attribute Types Used in the inetOrgPerson Object Class..3
   2.1.      Vehicle license or registration plate....................3
   2.2.      Department number........................................3
   2.3.      Display Name.............................................4
   2.4.      Employee Number..........................................4
   2.5.      Employee Type............................................4
   2.6.      JPEG Photograph..........................................5
   2.7.      Preferred Language.......................................5
   2.8.      User S/MIME Certificate..................................5
   2.9.      User PKCS #12............................................6
   3.     Definition of the inetOrgPerson Object Class................6
   4.     Example of an inetOrgPerson Entry...........................7
   5.     Security Considerations.....................................8
   6.     Acknowledgments.............................................8
   7.     Bibliography................................................8
   8.     Author's Address............................................9
   9.     Appendix A - inetOrgPerson Schema Summary..................10
   9.1.     Attribute Types..........................................10
   9.1.1.      New attribute types that are defined in this document.10
   9.1.2.      Attribute types from RFC 2256.........................12
   9.1.3.      Attribute types from RFC 1274.........................15
   9.1.4.      Attribute type from RFC 2079..........................16
   9.2.     Syntaxes.................................................17
   9.2.1.      Syntaxes from RFC 2252................................17
   9.2.2.      Syntaxes from RFC 2256................................17
   9.3.     Matching Rules...........................................17
   9.3.1.      Matching rules from RFC 2252..........................17
   9.3.2.      Matching rule from RFC 2256...........................18
   9.3.3.      Additional matching rules from X.520..................18
   9.3.4.      Matching rules not defined in any referenced document.19
   10.    Full Copyright Statement...................................20

1.  Background and Intended Usage

   The inetOrgPerson object class is a general purpose object class that
   holds attributes about people.  The attributes it holds were chosen
   to accommodate information requirements found in typical Internet and
   Intranet directory service deployments.  The inetOrgPerson object
   class is designed to be used within directory services based on the
   LDAP [RFC2251] and the X.500 family of protocols, and it should be
   useful in other contexts as well.  There is no requirement for
   directory services implementors to use the inetOrgPerson object
   class; it is simply presented as well-documented class that
   implementors can choose to use if they find it useful.




Smith                        Informational                      [Page 2]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


   The attribute type and object class definitions in this document are
   written using the BNF form of AttributeTypeDescription and
   ObjectClassDescription given in [RFC2252].  In some cases lines have
   been folded for readability.

   Attributes that are referenced but not defined in this document are
   included in one of the following documents:

      The COSINE and Internet X.500 Schema [RFC1274]

      Definition of an X.500 Attribute Type and an Object Class to Hold
      Uniform Resource Identifiers (URIs) [RFC2079]

      A Summary of the X.500(96) User Schema for use with LDAPv3
      [RFC2256]

   See Appendix A for a summary of the attribute types, associated
   syntaxes, and matching rules used in this document.

2.  New Attribute Types Used in the inetOrgPerson Object Class

2.1.  Vehicle license or registration plate.

   This multivalued field is used to record the values of the license or
   registration plate associated with an individual.

    ( 2.16.840.1.113730.3.1.1 NAME 'carLicense'
      DESC 'vehicle license or registration plate'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

2.2.  Department number

   Code for department to which a person belongs.  This can also be
   strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123).

    ( 2.16.840.1.113730.3.1.2
      NAME 'departmentNumber'
      DESC 'identifies a department within an organization'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )








Smith                        Informational                      [Page 3]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


2.3.  Display Name

   When displaying an entry, especially within a one-line summary list,
   it is useful to be able to identify a name to be used.  Since other
   attribute types such as 'cn' are multivalued, an additional attribute
   type is needed.  Display name is defined for this purpose.

  ( 2.16.840.1.113730.3.1.241
    NAME 'displayName'
    DESC 'preferred name of a person to be used when displaying entries'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

2.4.  Employee Number

   Numeric or alphanumeric identifier assigned to a person, typically
   based on order of hire or association with an organization.  Single
   valued.

    ( 2.16.840.1.113730.3.1.3
      NAME 'employeeNumber'
      DESC 'numerically identifies an employee within an organization'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
      SINGLE-VALUE )

2.5.  Employee Type

   Used to identify the employer to employee relationship.  Typical
   values used will be "Contractor", "Employee", "Intern", "Temp",
   "External", and "Unknown" but any value may be used.

    ( 2.16.840.1.113730.3.1.4
      NAME 'employeeType'
      DESC 'type of employment for a person'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )










Smith                        Informational                      [Page 4]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


2.6.  JPEG Photograph

   Used to store one or more images of a person using the JPEG File
   Interchange Format [JFIF].

    ( 0.9.2342.19200300.100.1.60
      NAME 'jpegPhoto'
      DESC 'a JPEG image'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )

   Note that the jpegPhoto attribute type was defined for use in the
   Internet X.500 pilots but no referencable definition for it could be
   located.

2.7.  Preferred Language

   Used to indicate an individual's preferred written or spoken
   language.  This is useful for international correspondence or human-
   computer interaction.  Values for this attribute type MUST conform to
   the definition of the Accept-Language header field defined in
   [RFC2068] with one exception:  the sequence "Accept-Language" ":"
   should be omitted.  This is a single valued attribute type.

    ( 2.16.840.1.113730.3.1.39
      NAME 'preferredLanguage'
      DESC 'preferred written or spoken language for a person'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
      SINGLE-VALUE )
   )

2.8.  User S/MIME Certificate

   A PKCS#7 [RFC2315] SignedData, where the content that is signed is
   ignored by consumers of userSMIMECertificate values.  It is
   recommended that values have a `contentType' of data with an absent
   `content' field.  Values of this attribute contain a person's entire
   certificate chain and an smimeCapabilities field [RFC2633] that at a
   minimum describes their SMIME algorithm capabilities.  Values for
   this attribute are to be stored and requested in binary form, as
   'userSMIMECertificate;binary'.  If available, this attribute is
   preferred over the userCertificate attribute for S/MIME applications.

    ( 2.16.840.1.113730.3.1.40
      NAME 'userSMIMECertificate'
      DESC 'PKCS#7 SignedData used to support S/MIME'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )



Smith                        Informational                      [Page 5]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


2.9.  User PKCS #12

   PKCS #12 [PKCS12] provides a format for exchange of personal identity
   information.  When such information is stored in a directory service,
   the userPKCS12 attribute should be used. This attribute is to be
   stored and requested in binary form, as 'userPKCS12;binary'.  The
   attribute values are PFX PDUs stored as binary data.

( 2.16.840.1.113730.3.1.216
  NAME 'userPKCS12'
  DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

3.  Definition of the inetOrgPerson Object Class

   The inetOrgPerson represents people who are associated with an
   organization in some way.  It is a structural class and is derived
   from the organizationalPerson class which is defined in X.521 [X521].

( 2.16.840.1.113730.3.2.2
    NAME 'inetOrgPerson'
    SUP organizationalPerson
    STRUCTURAL
    MAY (
        audio $ businessCategory $ carLicense $ departmentNumber $
        displayName $ employeeNumber $ employeeType $ givenName $
        homePhone $ homePostalAddress $ initials $ jpegPhoto $
        labeledURI $ mail $ manager $ mobile $ o $ pager $
        photo $ roomNumber $ secretary $ uid $ userCertificate $
        x500uniqueIdentifier $ preferredLanguage $
        userSMIMECertificate $ userPKCS12
    )
)

   For reference, we list the following additional attribute types that
   are part of the inetOrgPerson object class.  These attribute types
   are inherited from organizationalPerson (which in turn is derived
   from the person object class):













Smith                        Informational                      [Page 6]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


    MUST (
        cn $ objectClass $ sn
    )
    MAY (
        description $ destinationIndicator $ facsimileTelephoneNumber $
        internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $
        postalAddress $ postalCode $ postOfficeBox $
        preferredDeliveryMethod $ registeredAddress $ seeAlso $
        st $ street $ telephoneNumber $ teletexTerminalIdentifier $
        telexNumber $ title $ userPassword $ x121Address
    )

4.  Example of an inetOrgPerson Entry

   The following example is expressed using the LDIF notation defined in
   [LDIF].

   version: 1
   dn: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
   objectClass: top
   objectClass: person
   objectClass: organizationalPerson
   objectClass: inetOrgPerson
   cn: Barbara Jensen
   cn: Babs Jensen
   displayName: Babs Jensen
   sn: Jensen
   givenName: Barbara
   initials: BJJ
   title: manager, product development
   uid: bjensen
   mail: bjensen@siroe.com
   telephoneNumber: +1 408 555 1862
   facsimileTelephoneNumber: +1 408 555 1992
   mobile: +1 408 555 1941
   roomNumber: 0209
   carLicense: 6ABC246
   o: Siroe
   ou: Product Development
   departmentNumber: 2604
   employeeNumber: 42
   employeeType: full time
   preferredLanguage: fr, en-gb;q=0.8, en;q=0.7
   labeledURI: http://www.siroe.com/users/bjensen My Home Page







Smith                        Informational                      [Page 7]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


5.  Security Considerations

   Attributes of directory entries are used to provide descriptive
   information about the real-world objects they represent, which can be
   people, organizations or devices.  Most countries have privacy laws
   regarding the publication of information about people.

   Transfer of cleartext passwords are strongly discouraged where the
   underlying transport service cannot guarantee confidentiality and may
   result in disclosure of the password to unauthorized parties.

6.  Acknowledgments

   The Netscape Directory Server team created the inetOrgPerson object
   class based on experience and customer requirements.  Anil Bhavnani
   and John Kristian in particular deserve credit for all of the early
   design work.

   Many members of the Internet community, in particular those in the
   IETF ASID and LDAPEXT groups, also contributed to the design of this
   object class.

7.  Bibliography

   [JFIF]    E. Hamilton, "JPEG File Interchange Format (Version 1.02)",
             C-Cube Microsystems, Milpitas, CA, September 1, 1992.

   [LDIF]    G. Good, "The LDAP Data Interchange Format (LDIF) -
             Technical Specification", Work in Progress.

   [PKCS12]  "PKCS #12: Personal Information Exchange Standard", Version
             1.0 Draft, 30 April 1997.

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

   [RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
             Multiparts for MIME:  Multipart/Signed and
             Multipart/Encrypted", RFC 1847, October 1995.

   [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
             2068, January 1997.

   [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
             Object Class to Hold Uniform Resource Identifiers (URIs)",
             RFC 2079, January 1997.




Smith                        Informational                      [Page 8]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


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

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

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

   [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
             1.5", RFC 2315, March 1998.

   [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
             2633, June 1999.

   [X520]    ITU-T Rec. X.520, "The Directory: Selected Attribute
             Types", 1996.

   [X521]    ITU-T Rec. X.521, "The Directory: Selected Object Classes",
             1996.

8.  Author's Address

   Mark Smith
   Netscape Communications Corp.
   501 E. Middlefield Rd., Mailstop MV068
   Mountain View, CA 94043, USA

   Phone:  +1 650 937-3477
   EMail:  mcs@netscape.com




















Smith                        Informational                      [Page 9]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


9.  Appendix A - inetOrgPerson Schema Summary

   This appendix provides definitions of all the attribute types
   included in the inetOrgPerson object class along with their
   associated syntaxes and matching rules.

9.1.  Attribute Types

9.1.1.  New attribute types that are defined in this document

  ( 2.16.840.1.113730.3.1.1 NAME 'carLicense'
    DESC 'vehicle license or registration plate'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

  ( 2.16.840.1.113730.3.1.2
    NAME 'departmentNumber'
    DESC 'identifies a department within an organization'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

  ( 2.16.840.1.113730.3.1.241
    NAME 'displayName'
    DESC 'preferred name of a person to be used when displaying entries'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

  ( 2.16.840.1.113730.3.1.3
    NAME 'employeeNumber'
    DESC 'numerically identifies an employee within an organization'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

  ( 2.16.840.1.113730.3.1.4
    NAME 'employeeType'
    DESC 'type of employment for a person'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )






Smith                        Informational                     [Page 10]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


  ( 0.9.2342.19200300.100.1.60
    NAME 'jpegPhoto'
    DESC 'a JPEG image'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
  Note: The jpegPhoto attribute type was defined for use in the
    Internet X.500 pilots but no referencable definition for it
    could be located.

  ( 2.16.840.1.113730.3.1.39
    NAME 'preferredLanguage'
    DESC 'preferred written or spoken language for a person'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

  ( 2.16.840.1.113730.3.1.40
    NAME 'userSMIMECertificate'
    DESC 'signed message used to support S/MIME'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

  ( 2.16.840.1.113730.3.1.216
    NAME 'userPKCS12'
    DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

9.1.2.  Attribute types from RFC 2256

   Note that the original definitions of these types can be found in
   X.520.

    ( 2.5.4.15
      NAME 'businessCategory'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

    ( 2.5.4.3
      NAME 'cn'
      SUP name )

    ( 2.5.4.13
      NAME 'description'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )





Smith                        Informational                     [Page 11]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


    ( 2.5.4.27
      NAME 'destinationIndicator'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )

    ( 2.5.4.23
      NAME 'facsimileTelephoneNumber'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )

    ( 2.5.4.42
      NAME 'givenName'
      SUP name )

    ( 2.5.4.43
      NAME 'initials'
      SUP name )

    ( 2.5.4.25
      NAME 'internationaliSDNNumber'
      EQUALITY numericStringMatch
      SUBSTR numericStringSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )

    ( 2.5.4.7
      NAME 'l'
      SUP name )

    ( 2.5.4.0
      NAME 'objectClass'
      EQUALITY objectIdentifierMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

    ( 2.5.4.10
      NAME 'o'
      SUP name )

    ( 2.5.4.11
      NAME 'ou'
      SUP name )

    ( 2.5.4.19
      NAME 'physicalDeliveryOfficeName'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )





Smith                        Informational                     [Page 12]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


    ( 2.5.4.18
      NAME 'postOfficeBox'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )

    ( 2.5.4.16
      NAME 'postalAddress'
      EQUALITY caseIgnoreListMatch
      SUBSTR caseIgnoreListSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

    ( 2.5.4.17
      NAME 'postalCode'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )

    ( 2.5.4.28
      NAME 'preferredDeliveryMethod'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
      SINGLE-VALUE )

    ( 2.5.4.26
      NAME 'registeredAddress'
      SUP postalAddress
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

    ( 2.5.4.34
      NAME 'seeAlso'
      SUP distinguishedName )

    ( 2.5.4.4
      NAME 'sn'
      SUP name )

    ( 2.5.4.8
      NAME 'st'
      SUP name )

    ( 2.5.4.9
      NAME 'street'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )






Smith                        Informational                     [Page 13]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


    ( 2.5.4.20
      NAME 'telephoneNumber'
      EQUALITY telephoneNumberMatch
      SUBSTR telephoneNumberSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )

    ( 2.5.4.22
      NAME 'teletexTerminalIdentifier'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )

    ( 2.5.4.21
      NAME 'telexNumber'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )

    ( 2.5.4.12
      NAME 'title'
      SUP name )

    ( 2.5.4.36
      NAME 'userCertificate'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

    ( 2.5.4.35
      NAME 'userPassword'
      EQUALITY octetStringMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )

    ( 2.5.4.24
      NAME 'x121Address'
      EQUALITY numericStringMatch
      SUBSTR numericStringSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )

    ( 2.5.4.45
      NAME 'x500UniqueIdentifier'
      EQUALITY bitStringMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

   Some attribute types included in inetOrgPerson are derived from the
   'name' and 'distinguishedName' attribute supertypes:

    ( 2.5.4.41
      NAME 'name'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )





Smith                        Informational                     [Page 14]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


    ( 2.5.4.49
      NAME 'distinguishedName'
      EQUALITY distinguishedNameMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

9.1.3.  Attribute types from RFC 1274

    ( 0.9.2342.19200300.100.1.55
      NAME 'audio'
      EQUALITY octetStringMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{250000} )
    Note: The syntax used here for the audio attribute type is Octet
      String. RFC 1274 uses a syntax called audio which is not defined
      in RFC 1274.

    ( 0.9.2342.19200300.100.1.20
      NAME 'homePhone'
      EQUALITY telephoneNumberMatch
      SUBSTR telephoneNumberSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
    Note: RFC 1274 uses the longer name 'homeTelephoneNumber'.

    ( 0.9.2342.19200300.100.1.39
      NAME 'homePostalAddress'
      EQUALITY caseIgnoreListMatch
      SUBSTR caseIgnoreListSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

    ( 0.9.2342.19200300.100.1.3
      NAME 'mail'
      EQUALITY caseIgnoreIA5Match
      SUBSTR caseIgnoreIA5SubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
    Note: RFC 1274 uses the longer name 'rfc822Mailbox' and syntax OID
      of 0.9.2342.19200300.100.3.5.  All recent LDAP documents and most
      deployed LDAP implementations refer to this attribute as 'mail'
      and define the IA5 String syntax using using the OID
      1.3.6.1.4.1.1466.115.121.1.26, as is done here.

    ( 0.9.2342.19200300.100.1.10
      NAME 'manager'
      EQUALITY distinguishedNameMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )








Smith                        Informational                     [Page 15]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


    ( 0.9.2342.19200300.100.1.41
      NAME 'mobile'
      EQUALITY telephoneNumberMatch
      SUBSTR telephoneNumberSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
    Note: RFC 1274 uses the longer name 'mobileTelephoneNumber'.

    ( 0.9.2342.19200300.100.1.42
      NAME 'pager'
      EQUALITY telephoneNumberMatch
      SUBSTR telephoneNumberSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
    Note: RFC 1274 uses the longer name 'pagerTelephoneNumber'.

    ( 0.9.2342.19200300.100.1.7
      NAME 'photo' )
    Note: Photo attribute values are encoded in G3 fax format with an
      ASN.1 wrapper. Please refer to RFC 1274 section 9.3.7 for
      detailed syntax information for this attribute.

    ( 0.9.2342.19200300.100.1.6
      NAME 'roomNumber'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

    ( 0.9.2342.19200300.100.1.21
      NAME 'secretary'
      EQUALITY distinguishedNameMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

    ( 0.9.2342.19200300.100.1.1
      NAME 'uid'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
    Note: RFC 1274 uses the longer name 'userid'.

9.1.4.  Attribute type from RFC 2079

    ( 1.3.6.1.4.1.250.1.57
      NAME 'labeledURI'
      EQUALITY caseExactMatch
      SUBSTR caseExactSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )






Smith                        Informational                     [Page 16]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


9.2.  Syntaxes

9.2.1.  Syntaxes from RFC 2252

    ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )

    ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )

    ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )

    ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )

    ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )

    ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )

    ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )

    ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )

    ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )

    ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )

    ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )

    ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )

    ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )

9.2.2.  Syntaxes from RFC 2256

    ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )

    ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )

    ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )

    ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )

9.3.  Matching Rules

9.3.1.  Matching rules from RFC 2252

   Note that the original definition of many of these matching rules can
   be found in X.520.





Smith                        Informational                     [Page 17]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


    ( 2.5.13.16 NAME 'bitStringMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

    ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

    ( 2.5.13.11 NAME 'caseIgnoreListMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

    ( 2.5.13.2 NAME 'caseIgnoreMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

    ( 2.5.13.1 NAME 'distinguishedNameMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

    ( 2.5.13.8 NAME 'numericStringMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

    ( 2.5.13.0 NAME 'objectIdentifierMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

    ( 2.5.13.20 NAME 'telephoneNumberMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

9.3.2.  Matching rule from RFC 2256

   Note that the original definition of this matching rule can be found
   in X.520.

    ( 2.5.13.17 NAME 'octetStringMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

9.3.3.  Additional matching rules from X.520

   caseExactMatch

       ( 2.5.13.5 NAME 'caseExactMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   This rule determines whether a presented string exactly matches an
   attribute value of syntax DirectoryString.  It is identical to
   caseIgnoreMatch except that case is not ignored.  Multiple adjoining
   whitespace characters are treated the same as an individual space,
   and leading and trailing whitespace is ignored.







Smith                        Informational                     [Page 18]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


   caseExactSubstringsMatch

       ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   This rules determines whether the initial, any and final substring
   elements in a presented value are present in an attribute value of
   syntax DirectoryString.  It is identical to caseIgnoreSubstringsMatch
   except that case is not ignored.

   caseIgnoreListSubstringsMatch

       ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   This rule compares a presented substring with an attribute value
   which is a sequence of DirectoryStrings, but where the case of
   letters is not significant for comparison purposes.  A presented
   value matches a stored value if and only if the presented value
   matches the string formed by concatenating the strings of the stored
   value.  Matching is done according to the caseIgnoreSubstringsMatch
   rule except that none of the initial, final, or any values of the
   presented value match a substring of the concatenated string which
   spans more than one of the strings of the stored value.

9.3.4.  Matching rules not defined in any referenced document

   caseIgnoreIA5SubstringsMatch

       ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   This rules determines whether the initial, any and final substring
   elements in a presented value are present in an attribute value of
   syntax IA5 String without regard to the case of the letters in the
   strings.  It is expected that this matching rule will be added to an
   update of RFC 2252.














Smith                        Informational                     [Page 19]

RFC 2798          The LDAP inetOrgPerson Object Class         April 2000


10.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Smith                        Informational                     [Page 20]