Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
O
OpenLDAP
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package registry
Container Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Lukas However
OpenLDAP
Commits
627265e3
Commit
627265e3
authored
24 years ago
by
Kurt Zeilenga
Browse files
Options
Downloads
Patches
Plain Diff
replace inetOrgPerson I-D with RFC
parent
1973c664
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/rfc/rfc2798.txt
+1123
-0
1123 additions, 0 deletions
doc/rfc/rfc2798.txt
with
1123 additions
and
0 deletions
doc/
drafts/draft-smith-ldap-inetorgperson-xx
.txt
→
doc/
rfc/rfc2798
.txt
+
1123
−
0
View file @
627265e3
The LDAP inetOrgPerson Object Class Mark Smith
INTERNET-DRAFT Netscape Communications
Intended Category: Informational 31 January 2000
Expires: 31 July 2000
Definition of the inetOrgPerson LDAP Object Class
Filename: draft-smith-ldap-inetorgperson-04.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Network Working Group M. Smith
Request for Comments: 2798 Netscape Communications
Category: Informational April 2000
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This draft document will be submitted to the RFC Editor as an Informa-
tional document. Distribution of this memo is unlimited. Please send
comments to the author <mcs@netscape.com>.
Definition of the inetOrgPerson LDAP Object Class
Copyright (C) The Internet Society (1996-2000). All Rights Reserved.
Status of this Memo
Please see the Copyright section near the end of this document for more
information.
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This Internet Draft expires on 31 July 2000.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
2.
Abstract
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.
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.
M. Smith Network Working Group [Page 1]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
3. Table of Contents
1. Status of this Memo............................................1
2. Abstract.......................................................1
3. Table of Contents..............................................2
4. Background and Intended Usage..................................3
5. New Attribute Types Used in the inetOrgPerson Object Class.....3
5.1. Vehicle license or registration plate.......................3
5.2. Department number...........................................4
5.3. Display Name................................................4
5.4. Employee Number.............................................4
5.5. Employee Type...............................................4
5.6. JPEG Photograph.............................................5
5.7. Preferred Language..........................................5
5.8. User S/MIME Certificate.....................................5
5.9. User PKCS #12...............................................6
6. Definition of the inetOrgPerson Object Class...................6
7. Example of an inetOrgPerson Entry..............................7
8. Security Considerations........................................8
9. Acknowledgments................................................8
10. Copyright......................................................8
11. Bibliography...................................................9
12. Author's Address...............................................10
13. Appendix A - inetOrgPerson Schema Summary......................10
13.1. Attribute Types.............................................10
13.1.1. New attribute types that are defined in this document....10
13.1.2. Attribute types from RFC 2256............................12
13.1.3. Attribute types from RFC 1274............................15
13.1.4. Attribute type from RFC 2079.............................17
13.2. Syntaxes....................................................17
13.2.1. Syntaxes from RFC 2252...................................17
13.2.2. Syntaxes from RFC 2256...................................18
13.3. Matching Rules..............................................18
13.3.1. Matching rules from RFC 2252.............................18
13.3.2. Matching rule from RFC 2256..............................19
13.3.3. Additional matching rules from X.520.....................19
13.3.4. Matching rules not defined in any referenced document....20
14. Appendix B - Change History....................................20
...
...
@@ -105,50 +49,98 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
M. Smith Network Working Group [Page 2]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
4. 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.
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]
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.
Definition of an X.500 Attribute Type and an Object Class to Hold
Uniform Resource Identifiers (URIs) [RFC2079]
Attributes that are referenced but not defined in this document are
included in one of the following documents:
A Summary of the X.500(96) User Schema for use with LDAPv3 [RFC2256
]
The COSINE and Internet X.500 Schema [RFC1274
]
See Appendix A for a summary of the a
ttribute
t
ype
s, associated syn-
taxes, and matching rules used in this document.
Definition of an X.500 A
ttribute
T
ype
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]
5. New Attribute Types Used in the inetOrgPerson Object Class
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
5
.1. Vehicle license or registration plate.
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.
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'
...
...
@@ -156,49 +148,50 @@ registration plate associated with an individual.
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 )
M. Smith Network Working Group [Page 3]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
5.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
5.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 attri-
bute types such as 'cn' are multivalued, an additional attribute type is
needed. Display name is defined for this purpose.
2.3. Display Name
( 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 )
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 )
5
.4. Employee Number
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.
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'
...
...
@@ -208,19 +201,11 @@ on order of hire or association with an organization. Single valued.
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
2.5. Employee Type
5.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.
M. Smith Network Working Group [Page 4]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
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'
...
...
@@ -230,28 +215,41 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
5.6. JPEG Photograph
Used to store one or more images of a person using the JPEG File Inter-
change Format [JFIF].
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
Inter-
net X.500 pilots but no referencable definition for it could be
located.
Note that the jpegPhoto attribute type was defined for use in the
Inter
net X.500 pilots but no referencable definition for it could be
located.
5
.7. Preferred Language
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 defini-
tion 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.
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 defini
tion 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'
...
...
@@ -260,28 +258,19 @@ is a single valued attribute type.
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
)
5.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
M. Smith Network Working Group [Page 5]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
)
2.8. User S/MIME Certificate
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.
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'
...
...
@@ -289,25 +278,30 @@ attribute for S/MIME applications.
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
5.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.
Smith Informational [Page 5]
RFC 2798 The LDAP inetOrgPerson Object Class April 2000
( 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 )
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.
6. Definition of the inetOrgPerson Object Class
( 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 )
The inetOrgPerson represents people who are associated with an organiza-
tion in some way. It is a structural class and is derived from the
organizationalPerson class which is defined in X.521 [X521].
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'
...
...
@@ -315,28 +309,36 @@ organizationalPerson class which is defined in X.521 [X521].
STRUCTURAL
MAY (
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $
homePostalAddress $ initials $ jpegPhoto $
labeledURI $
mail $ manager $ mobile $ o $ pager $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $
homePostalAddress $ initials $ jpegPhoto $
labeledURI $
mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $
userPKCS12
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):
For reference, we list the following additional attribute types that are
M. Smith Network Working Group [Page 6]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
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
...
...
@@ -350,284 +352,248 @@ person object class):
telexNumber $ title $ userPassword $ x121Address
)
4. Example of an inetOrgPerson Entry
7. 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
M. Smith Network Working Group [Page 7]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
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
labeledURI: http://www.siroe.com/users/bjensen My Home Page
8. Security Considerations
Attributes of directory entries are used to provide descriptive informa-
tion 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.
9. Acknowledgments
Smith Informational [Page 7]
RFC 2798 The LDAP inetOrgPerson Object Class April 2000
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.
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.
10. Copyright
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.
Copyright (C) The Internet Society (1996-2000). All Rights Reserved.
6. Acknowledgments
This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, 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 Stan-
dards process must be followed, or as required to translate it into
languages other than English.
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.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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.
This document and the information contained herein is provided on an "AS
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.
M. Smith Network Working Group [Page 8]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
[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.
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 FIT-
NESS FOR A PARTICULAR PURPOSE.
[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.
11. 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" INTERNET-DRAFT <draft-good-ldap-ldif-05.txt>, 19
October 1999.
Smith Informational [Page 8]
RFC 2798 The LDAP inetOrgPerson Object Class April 2000
[PKCS12]
"PKCS #12: Personal Information Exchange Standard", Version 1.0
DRAFT, 30 April 1997.
[RFC1274]
P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC
1274, November 1991.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC1847]
J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts
for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847,
October 1995.
[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.
[RFC2068]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[RFC2079]
M. Smith, "Definition of an X.500 Attribute Type and an Object
Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, Janu-
ary 1997.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
1.5", RFC 2315, March 1998.
[RFC2251]
M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
(v3)", RFC 2251, December 1997.
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[RFC2252]
M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins,
[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
M. Smith Network Working Group [Page 9]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
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
"Lightweight Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[RFC2256]
M. Wahl, "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[RFC2315]
B. Kaliski, "PKCS #7: Cryptographic Message Syntax Version 1.5",
RFC 2315, March 1998.
[RFC2633]
B. Ramsdell, "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.
12. 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
13. 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.
13.1. Attribute Types
13.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
M. Smith Network Working Group [Page 10]
Smith Informational [Page 9]
INTERNET-DRAFT
The LDAP inetOrgPerson Object Class
31 January
2000
RFC 2798
The LDAP inetOrgPerson Object Class
April
2000
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
9. Appendix A - inetOrgPerson Schema Summary
( 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 )
This appendix provides definitions of all the attribute types
included in the inetOrgPerson object class along with their
associated syntaxes and matching rules.
( 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 )
9.1. Attribute Types
( 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 )
9.1.1. New attribute types that are defined in this document
( 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 )
( 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 )
( 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 )
M.
Smith
Network Working Group
[Page 1
1
]
Smith
Informational
[Page 1
0
]
INTERNET-DRAFT
The LDAP inetOrgPerson Object Class
31 January
2000
RFC 2798
The LDAP inetOrgPerson Object Class
April
2000
( 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 )
( 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.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 )
( 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 )
13.1.2. Attribute types from RFC 2256
( 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 )
Note that the original definitions of these types can be found in X.520.
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'
...
...
@@ -645,6 +611,15 @@ Note that the original definitions of these types can be found in X.520.
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
...
...
@@ -663,13 +638,6 @@ Note that the original definitions of these types can be found in X.520.
NAME 'initials'
SUP name )
M. Smith Network Working Group [Page 12]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
( 2.5.4.25
NAME 'internationaliSDNNumber'
EQUALITY numericStringMatch
...
...
@@ -699,6 +667,15 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
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
...
...
@@ -718,14 +695,6 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
( 2.5.4.28
M. Smith Network Working Group [Page 13]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
NAME 'preferredDeliveryMethod'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
SINGLE-VALUE )
...
...
@@ -753,6 +722,16 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
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
...
...
@@ -775,13 +754,6 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
NAME 'userCertificate'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
M. Smith Network Working Group [Page 14]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
( 2.5.4.35
NAME 'userPassword'
EQUALITY octetStringMatch
...
...
@@ -798,8 +770,8 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
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:
Some attribute types included in inetOrgPerson are derived from the
'name' and 'distinguishedName' attribute supertypes:
( 2.5.4.41
NAME 'name'
...
...
@@ -807,13 +779,21 @@ Some attribute types included in inetOrgPerson are derived from the
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 )
13.1.3. Attribute types from RFC 1274
9.1.3. Attribute types from RFC 1274
( 0.9.2342.19200300.100.1.55
NAME 'audio'
...
...
@@ -830,14 +810,6 @@ Some attribute types included in inetOrgPerson are derived from the
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
Note: RFC 1274 uses the longer name 'homeTelephoneNumber'.
M. Smith Network Working Group [Page 15]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
( 0.9.2342.19200300.100.1.39
NAME 'homePostalAddress'
EQUALITY caseIgnoreListMatch
...
...
@@ -860,6 +832,18 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
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
...
...
@@ -886,14 +870,6 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
M. Smith Network Working Group [Page 16]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
( 0.9.2342.19200300.100.1.21
NAME 'secretary'
EQUALITY distinguishedNameMatch
...
...
@@ -906,8 +882,7 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
Note: RFC 1274 uses the longer name 'userid'.
13.1.4. Attribute type from RFC 2079
9.1.4. Attribute type from RFC 2079
( 1.3.6.1.4.1.250.1.57
NAME 'labeledURI'
...
...
@@ -916,10 +891,18 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
13.2. Syntaxes
13.2.1. Syntaxes from RFC 2252
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' )
...
...
@@ -943,19 +926,11 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
M. Smith Network Working Group [Page 17]
INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
( 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' )
13.2.2. Syntaxes from RFC 2256
9.2.2. Syntaxes from RFC 2256
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
...
...
@@ -965,15 +940,21 @@ INTERNET-DRAFT The LDAP inetOrgPerson Object Class 31 January 2000
( 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.
13.3. Matching Rules
13.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 )
...
...
@@ -999,113 +980,138 @@ found in X.520.
( 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.
M. Smith Network Working Group [Page 18]
Smith Informational [Page 18]
INTERNET-DRAFT
The LDAP inetOrgPerson Object Class
31 January
2000
RFC 2798
The LDAP inetOrgPerson Object Class
April
2000
13.3.2. Matching rule from RFC 2256
caseExactSubstringsMatch
Note that the original definition of this matching rule can be found in
X.520.
( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
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 )
13.3.3. Additional matching rules from X.520
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.
caseExactMatch
9.3.4. Matching rules not defined in any referenced document
( 2.5.13.5 NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
caseIgnoreIA5SubstringsMatch
This rule determines whether a presented string exactly matches an
attribute value of syntax DirectoryString. It is identical to caseIg-
noreMatch except that case is not ignored. Multiple adjoining whi-
tespace characters are treated the same as an individual space, and
leading and trailing whitespace is ignored.
( 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.
caseExactSubstringsMatch
( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
This rules determines whether the initial, any and final substring ele-
ments 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.41 )
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 accord-
ing to the caseIgnoreSubstringsMatch rule except that none of the ini-
tial, 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
M. Smith Network Working Group [Page 19]
Smith Informational [Page 19]
INTERNET-DRAFT
The LDAP inetOrgPerson Object Class
31 January
2000
RFC 2798
The LDAP inetOrgPerson Object Class
April
2000
stored value.
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
13.3.4. Matching rules not defined in any referenced document
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.
caseIgnoreIA5SubstringsMatch
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
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.
This rules determines whether the initial, any and final substring ele-
ments 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.
14. Appendix B - Change History
Changes since draft-smith-ldap-inetorgperson-03.txt:
Replaced the definition of the User S/MIME Certificate attribute type
(userSMIMECertificate) with a much more precise definition (section
5.8). The new definition required two new references to be added:
RFC 2315 and RFC 2633 (section 11).
Removed extra closing parenthesis `)' after the userPKCS12 definition
(section 5.9).
Updated the [LDIF] reference to point to the latest draft (section
11) and added a "version: 1" line to the LDIF example (section 7).
Also replaced all occurrences of "Airius" and with "Siroe" in the
example since we don't have permission to use the Airius name.
Corrected the SYNTAX OIDs for userSMIMECertificate and userPKCS12 in
Appendix A to match that used in the main text (section 13.1.1).
Improved the note included in Appendix A that discusses the
`rfc822Mailbox' vs. `mail' issue (section 13.1.3).
Updated the copyright year range to includ 2000 (sections 1 and 10).
This Internet Draft expires on 31 July 2000.
...
...
@@ -1113,5 +1119,5 @@ Changes since draft-smith-ldap-inetorgperson-03.txt:
M.
Smith
Network Working Group
[Page 20]
Smith
Informational
[Page 20]
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment