RASCHEMA J. Coretta
Internet-Draft August 27, 2024
Intended status: Experimental
Obsoletes: X660LDAP
Expires: February 23, 2025
The OID Directory: The Schema
draft-coretta-oiddir-schema-02.txt
Abstract
In service to the "OID Directory" I-D series, this I-D extends schema
definitions for use within an implementation of the Registration
Authority Directory Information Tree.
See the RADIR I-D for a complete draft series manifest.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 23, 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Coretta Expires February 23, 2025 [Page 1]
Internet-Draft The OID Directory: Schema August 2024
Table of Contents
1. Introduction ....................................................4
1.1. Conventions ................................................5
1.2. Acronyms Used ..............................................5
1.3. Allocations ................................................5
1.4. Well-Known Numeric OIDs ....................................5
2. Schema Definitions ..............................................6
2.1. LDAP Syntaxes ..............................................6
2.2. Matching Rules .............................................6
2.3. Attribute Types ............................................6
2.3.1. 'n' ...................................................7
2.3.2. 'dotNotation' .........................................7
2.3.3. 'iRI' .................................................7
2.3.4. 'aSN1Notation' ........................................8
2.3.5. 'unicodeValue' ........................................9
2.3.6. 'additionalUnicodeValue' ..............................9
2.3.7. 'identifier' ..........................................9
2.3.8. 'secondaryIdentifier' ................................10
2.3.9. 'registrationInformation' ............................10
2.3.10. 'registrationURI' ...................................11
2.3.11. 'registrationCreated' ...............................11
2.3.12. 'registrationModified' ..............................11
2.3.13. 'registrationRange' .................................12
2.3.14. 'registrationStatus' ................................12
2.3.15. 'registrationClassification' ........................12
2.3.16. 'isLeafNode' ........................................13
2.3.17. 'isFrozen' ..........................................13
2.3.18. 'standardizedNameForm' ..............................13
2.3.19. 'nameAndNumberForm' .................................14
2.3.20. 'longArc' ...........................................14
2.3.21. 'supArc' ............................................15
2.3.22. 'c-supArc' ..........................................15
2.3.23. 'topArc' ............................................16
2.3.24. 'c-topArc' ..........................................16
2.3.25. 'subArc' ............................................17
2.3.26. 'leftArc' ...........................................17
2.3.27. 'minArc' ............................................17
2.3.28. 'c-minArc' ..........................................18
2.3.29. 'rightArc' ..........................................18
2.3.30. 'maxArc' ............................................19
2.3.31. 'c-maxArc' ..........................................19
2.3.32. 'discloseTo' ........................................20
2.3.33. 'c-discloseTo' ......................................20
2.3.34. 'registrantID .......................................20
2.3.35. 'currentAuthority' ..................................21
2.3.36. 'c-currentAuthority' ................................21
2.3.37. 'currentAuthorityStartTimestamp' ....................22
2.3.38. 'currentAuthorityCommonName' ........................22
2.3.39. 'currentAuthorityCountryCode' .......................22
2.3.40. 'currentAuthorityCountryName' .......................23
2.3.41. 'currentAuthorityEmail' .............................23
Coretta Expires February 23, 2025 [Page 2]
Internet-Draft The OID Directory: Schema August 2024
2.3.42. 'currentAuthorityFax' ...............................23
2.3.43. 'currentAuthorityLocality' ..........................24
2.3.44. 'currentAuthorityMobile' ............................24
2.3.45. 'currentAuthorityOrg' ...............................25
2.3.46. 'currentAuthorityPOBox' .............................25
2.3.47. 'currentAuthorityPostalAddress' .....................25
2.3.48. 'currentAuthorityPostalCode' ........................26
2.3.49. 'currentAuthorityState' .............................26
2.3.50. 'currentAuthorityStreet' ............................26
2.3.51. 'currentAuthorityTelephone' .........................27
2.3.52. 'currentAuthorityTitle' .............................27
2.3.53. 'currentAuthorityURI' ...............................27
2.3.54. 'firstAuthority' ....................................28
2.3.55. 'c-firstAuthority' ..................................28
2.3.56. 'firstAuthorityStartTimestamp' ......................29
2.3.57. 'firstAuthorityEndTimestamp' ........................29
2.3.58. 'firstAuthorityCommonName' ..........................29
2.3.59. 'firstAuthorityCountryCode' .........................30
2.3.60. 'firstAuthorityCountryName' .........................30
2.3.61. 'firstAuthorityEmail' ...............................31
2.3.62. 'firstAuthorityFax' .................................31
2.3.63. 'firstAuthorityLocality' ............................31
2.3.64. 'firstAuthorityMobile' ..............................32
2.3.65. 'firstAuthorityOrg' .................................32
2.3.66. 'firstAuthorityPOBox' ...............................32
2.3.67. 'firstAuthorityPostalAddress' .......................33
2.3.68. 'firstAuthorityPostalCode' ..........................33
2.3.69. 'firstAuthorityState' ...............................34
2.3.70. 'firstAuthorityStreet' ..............................34
2.3.71. 'firstAuthorityTelephone' ...........................34
2.3.72. 'firstAuthorityTitle' ...............................35
2.3.73. 'firstAuthorityURI' .................................35
2.3.74. 'sponsor' ...........................................35
2.3.75. 'c-sponsor' .........................................36
2.3.76. 'sponsorStartTimestamp ..............................36
2.3.77. 'sponsorEndTimestamp ................................37
2.3.78. 'sponsorCommonName' .................................37
2.3.79. 'sponsorCountryCode' ................................37
2.3.80. 'sponsorCountryName' ................................38
2.3.81. 'sponsorEmail' ......................................38
2.3.82. 'sponsorFax' ........................................38
2.3.83. 'sponsorLocality' ...................................39
2.3.84. 'sponsorMobile' .....................................39
2.3.85. 'sponsorOrg' ........................................39
2.3.86. 'sponsorPOBox' ......................................40
2.3.87. 'sponsorPostalAddress' ..............................40
2.3.88. 'sponsorPostalCode' .................................41
2.3.89. 'sponsorState' ......................................41
2.3.90. 'sponsorStreet' .....................................41
2.3.91. 'sponsorTelephone' ..................................42
2.3.92. 'sponsorTitle' ......................................42
2.3.93. 'sponsorURI' ........................................42
Coretta Expires February 23, 2025 [Page 3]
Internet-Draft The OID Directory: Schema August 2024
2.3.94. 'rADITProfile' ......................................43
2.3.95. 'rARegistrationBase' ................................43
2.3.96. 'rARegistrantBase' ..................................43
2.3.97. 'rADirectoryModel' ..................................44
2.3.98. 'rAServiceMail' .....................................44
2.3.99. 'rAServiceURI' ......................................44
2.3.100. 'rATTL' ............................................45
2.3.101. 'c-rATTL' ..........................................45
2.3.102. 'registeredUUID' ...................................46
2.3.103. 'dotEncoding' ......................................46
2.4. Matching Rule Uses ........................................46
2.5. Object Classes ............................................47
2.5.1. 'registration' .......................................47
2.5.2. 'rootArc' ............................................47
2.5.3. 'arc' ................................................47
2.5.4. 'x660Context .........................................47
2.5.5. 'x667Context .........................................48
2.5.6. 'x680Context .........................................48
2.5.7. 'x690Context .........................................48
2.5.8. 'iTUTRegistration' ...................................49
2.5.9. 'iSORegistration' ....................................49
2.5.10. 'jointISOITUTRegistration' ..........................49
2.5.11. 'spatialContext' ....................................50
2.5.12. 'registrationSupplement' ............................50
2.5.13. 'firstAuthorityContext' .............................51
2.5.14. 'currentAuthorityContext' ...........................51
2.5.15. 'sponsorContext' ....................................52
2.5.16. 'registrant' ........................................53
2.5.17. 'rADUAConfig' .......................................53
2.6. DIT Content Rules .........................................53
2.7. Name Forms ................................................54
2.7.1. 'nRootArcForm' .......................................54
2.7.2. 'nArcForm' ...........................................54
2.7.3. 'dotNotationArcForm' .................................54
2.8. DIT Structure Rules .......................................54
3. IANA Considerations ............................................55
4. Security Considerations ........................................55
5. References .....................................................55
5.1. Normative References ......................................55
5.2. Informative References ....................................57
Author's Address ..................................................57
1. Introduction
The information bases meant to house registration and registrant data
by way of modern directory standards as outlined within this series
is dependent upon a comprehensive directory schema.
The schema is used to define content and -- to a degree -- structure
within the directory.
Coretta Expires February 23, 2025 [Page 4]
Internet-Draft The OID Directory: Schema August 2024
In context, the definitions set forth are based on concepts derived
from ITU-T Recommendations [X.660], [X.680], [RFC2578], et al.
The intended end result is a directory service specially suited to
operate as an object identifier registration authority service.
1.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
all capitals, as shown here.
1.2. Acronyms Used
See Section 1.3 of the RADIR I-D for all acronym references.
1.3. Allocations
This specification extends the previously defined I-D series OID root
1.3.6.1.4.1.56521.101 per Section 1.6 of the RADIR I-D:
- 1.3.6.1.4.1.56521.101.2 (schema)
- 1.3.6.1.4.1.56521.101.2.3 (attributeTypes)
- 1.3.6.1.4.1.56521.101.2.5 (objectClasses)
- 1.3.6.1.4.1.56521.101.2.7 (nameForms)
OIDs defined in this I-D correlate to the section numbers in which
they originate. For example, the 'n' attribute type defined within
Section 2.3.1 is associated with the OID 1.3.6.1.4.1.56521.101.2.3.1.
Should this I-D be elevated to RFC status, the aforementioned root
OID prefix shall be made obsolete in favor of an IANA-assigned OID,
at which point this I-D will be updated to reference the literal
'IANA-ASSIGNED-OID' placeholder prefix, where appropriate.
1.4. Well-Known Numeric OIDs
This I-D references several well-known numeric OIDs defined by other
parties or institutions, particularly as it pertains to the content
within all of Section 2.3. These numeric OIDs are shown below:
- 1.3 (Identified-Organization, per clause A.4.2 of ITU-T Rec.
[X.660])
- 1.3.6 (dod, per Section 3.1 of [RFC1155])
- 1.3.6.1 (Internet OID, per Section 3.1 of [RFC1155])
- 1.3.6.1.1.16.1 (UUID syntax, matching rule and ordering rule, per
Sections 2.1, 2.2 and 2.3 of [RFC4530] respectively)
Coretta Expires February 23, 2025 [Page 5]
Internet-Draft The OID Directory: Schema August 2024
- 1.3.6.1.4.1.1466.115.121.1.12 (DN syntax and matching rule, per
Section 4.2.15 of [RFC4517])
- 1.3.6.1.4.1.1466.115.121.1.24 (Generalized Time syntax, per
Section 3.3.13 of [RFC4517])
- 1.3.6.1.4.1.1466.115.121.1.27 (Integer syntax, per Section 3.3.16
of [RFC4517])
- 1.3.6.1.4.1.1466.115.121.1.38 (OID syntax, per Section 3.3.26
[RFC4517])
- 1.3.6.1.4.1.1466.115.121.1.40 (Octet String syntax, per Section
3.3.25 of [RFC4517])
2. Schema Definitions
This section discusses the particulars of the LDAP schema definitions
made available through this I-D.
These schema definitions described in this section are provided using
LDAP description formats [RFC4512]. These elements are line-wrapped
and indented for readability when needed.
ALL definitions declared throughout the following subsections are to
be considered "leaf nodes" (no subordinate registrations).
2.1. LDAP Syntaxes
No LDAP syntaxes are defined anywhere in this I-D series. However,
the topic of syntax is a recurring theme in ITU-T Recommendations
[X.660], [X.680] and many other standards relevant to this series.
This section serves only to advise the reader to consider the many
defined (or cited) ABNF productions throughout Section 2.3. While
the base LDAP syntaxes used within this I-D are often insufficient
in enforcing complete compliance with relevant syntax standards,
most modern X.500/LDAP products support use of constraining rules
of some form to narrow their scope.
While the particulars of such product features are out of scope for
this I-D series, the reader is nonetheless advised to make an effort
to sufficiently constrain attribute value input so as to honor the
relevant standard(s) in question.
2.2. Matching Rules
No LDAP matching rules are defined anywhere in this I-D series.
2.3. Attribute Types
The following subsections detail one hundred three (103) attribute
types created for use within implementations of this specification.
Coretta Expires February 23, 2025 [Page 6]
Internet-Draft The OID Directory: Schema August 2024
Please note that a great many of these attribute type definitions are
sub types of attribute types defined in the following Standards, and
as such are considered dependencies:
- [RFC2079] for URI support
- [RFC4519] for so-called "core" schema elements
- [RFC4524] for Cosine schema elements
If the nature of a particular directory implementation precludes the
use of sub typed attributes, this specification may not be practical
for adoption.
The 'n' attribute type allows the assignment of an unsigned integer
used to represent the Number Form of a registration per ITU-T Rec.
[X.680].
A practical ABNF production, labeled 'number', is defined in Section
1.4 of [RFC4512].
( 1.3.6.1.4.1.56521.101.2.3.1
NAME 'n'
DESC 'X.680, cl. 32.3: NumberForm'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
Examples: "56521", "0"
2.3.2. 'dotNotation'
The 'dotNotation' attribute type allows the assignment of one (1) OID
to any non root registration.
A practical ABNF production, labeled 'numericoid', is defined within
Section 1.4 of [RFC4512].
( 1.3.6.1.4.1.56521.101.2.3.2
NAME 'dotNotation'
DESC 'X.680: OID in dotted notation'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE )
Examples: "1.3.6.1", "2.999"
The 'iRI' attribute type allows the assignment of one (1) or more
OID-IRI values to a registration.
Coretta Expires February 23, 2025 [Page 7]
Internet-Draft The OID Directory: Schema August 2024
A practical ABNF production for this attribute type, as derived from
clause 34.3 of ITU-T Rec. [X.680], is as follows:
subArcId = SOLIDUS arcId *subArcId
arcId = intUV / nintUV
nintUV = 1*iunreserved ; non-integer unicode value
intUV = number ; integer unicode value
SOLIDUS = "%x2f" ; "/"
The 'number' ABNF production originates in Section 1.4 of [RFC4512].
The 'iunreserved' ABNR production originates within Section 2.2 of
[RFC3987].
( 1.3.6.1.4.1.56521.101.2.3.3
NAME 'iRI'
DESC 'X.680, cl. 34: OID-IRI'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Examples: "/ITU-T", "/ISO/Identified-Organization", "/ASN.1"
2.3.4. 'aSN1Notation'
The 'aSN1Notation' attribute type allows the assignment of an OID in
ASN.1, or ITU-T Rec. [X.680] ObjectIdentifierValue, notation.
A practical ABNF production for this attribute type is as follows:
asn1notation = LCURL forms RCURL
forms = ( nanf / identifier ) *( SPACE ( nanf / number ) )
SPACE = "%x20" ; " "
LCURL = "%x7b" ; "{"
RCURL = "%x7d" ; "}"
The 'nanf' ABNF originates in Section 2.3.19. The 'identifier' ABNF
production originates in Section 2.3.7. The 'number' ABNF production
originates in Section 1.4 of [RFC4512].
( 1.3.6.1.4.1.56521.101.2.3.4
NAME 'aSN1Notation'
DESC 'X.680, cl. 32.3: ObjectIdentifierValue'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
Examples: "{itu-t(0)}", "{iso(1) identified-organization(3)}"
Coretta Expires February 23, 2025 [Page 8]
Internet-Draft The OID Directory: Schema August 2024
2.3.5. 'unicodeValue'
The 'unicodeValue' attribute type allows the assignment of a single
non-integer Unicode label to a registration, per ITU-T Rec. [X.660].
A practical ABNF production for this attribute type is as follows:
uval = 1*iunreserved
The ABNF production 'iunreserved' is defined in Section 2.2 of
[RFC3987].
( 1.3.6.1.4.1.56521.101.2.3.5
NAME 'unicodeValue'
DESC 'X.660, cl. 7.5: non-integer Unicode label'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE )
Examples: "ITU-T", "Identified-Organization"
2.3.6. 'additionalUnicodeValue'
The 'additionalUnicodeValue' attribute type allows for the assignment
of one (1) or more additional non-integer Unicode labels, per clause
3.5.2 of ITU-T Rec. [X.660], to a registration.
A practical ABNF production for this attribute type is defined within
Section 2.3.5.
( 1.3.6.1.4.1.56521.101.2.3.6
NAME 'additionalUnicodeValue'
DESC 'X.660, cl. 3.5.2: additional non-integer Unicode labels'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2.3.7. 'identifier'
The 'identifier' attribute type allows for the assignment of one (1)
non-numeric, non-Unicode identifier to a registration.
Per clause 12.3 of ITU-T Rec. [X.680]:
An "identifier" shall consist of an arbitrary number (one or more)
of letters, digits, and hyphens. The initial character shall be a
lower-case letter. A hyphen shall not be the last character. A
hyphen shall not be immediately followed by another hyphen.
As a practical ABNF production, the above clause translates as
follows:
Coretta Expires February 23, 2025 [Page 9]
Internet-Draft The OID Directory: Schema August 2024
identifier = leadkeychar *keychar
leadkeychar = LOWER
keychar = *( [ HYPHEN ] ( ALPHA / DIGIT ) )
ALPHA = ( LOWER / UPPER ) ; a-z / A-Z
UPPER = "%x41-%x5a" ; A-Z
LOWER = "%x61-%x7a" ; a-z
DIGIT = "%x30-%x39" ; 0-9
HYPHEN = "%x2d" ; "-"
The attribute type 'name', as defined in Section 2.18 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.7
NAME 'identifier'
DESC 'X.680, cl. 12.3: Identifier'
SUP name
SINGLE-VALUE )
Examples: "itu-t", "iso"
2.3.8. 'secondaryIdentifier'
The 'secondaryIdentifier' attribute type allows the assignment of
one (1) or more additional secondary non-numeric non-Unicode values,
per clause 3.5.1 of ITU-T Rec. [X.660], to a registration.
A practical ABNF production for this attribute type is defined within
Section 2.3.7.
The attribute type 'name', as defined in Section 2.18 of [RFC4519],
is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.8
NAME 'secondaryIdentifier'
DESC 'X.660, cl. 3.5.1: Additional Identifiers'
SUP name )
Examples: "enterprises", "ccitt"
2.3.9. 'registrationInformation'
The 'registrationInformation' attribute type allows the OPTIONAL
assignment of octet-based values intended for extended information
relating to the registration in question.
The 'OCTET' ABNF production defined in Section 1.4 of [RFC4512] is
applicable in any non-zero quantity or combination, as no defined
syntax or standard exists to govern this type.
Coretta Expires February 23, 2025 [Page 10]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.9
NAME 'registrationInformation'
DESC 'Extended octet-based registration data'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Example: "Acme, Co., Research & Development, Copyright (c) 2024"
2.3.10. 'registrationURI'
The 'registrationURI' attribute type allows for the assignment of one
(1) or more URI values, with optional labels, to a registration.
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
A practical ABNF production for this attribute type is defined within
Appendix A of [RFC3986].
( 1.3.6.1.4.1.56521.101.2.3.10
NAME 'registrationURI'
DESC 'Uniform Resource Identifier for a registration'
SUP labeledURI )
Examples: "http://example.com Example", "ftp://example.com"
2.3.11. 'registrationCreated'
The 'registrationCreated' attribute type allows for the assignment
of a generalized timestamp indicating the date and time at which a
registration was, or will be, created or officiated.
A practical ABNF production for this attribute type is defined within
Section 3.3.13 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.11
NAME 'registrationCreated'
DESC 'Generalized timestamp for a registration creation'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
Examples: "19800229114853Z", "20130109033116Z"
2.3.12. 'registrationModified'
The 'registrationModified' attribute type allows for the assignment
of one (1) or more generalized timestamp values indicating the dates
and times of all applied updates to a registration.
A practical ABNF production for this attribute type is defined within
Section 3.3.13 of [RFC4517].
Coretta Expires February 23, 2025 [Page 11]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.12
NAME 'registrationModified'
DESC 'Generalized timestamps for registration modifications'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
Examples: "19951231115959Z", "20130109033116Z"
2.3.13. 'registrationRange'
The 'registrationRange' attribute type allows for the expression of
an OID sibling allocation range, such as "100" to indicate 'up to
and including 100', or "-1" to indicate 'to infinity'.
A practical ABNF production, labeled 'number', is defined in Section
1.4 of [RFC4512]. This satisfies the unsigned form of instances of
this type.
( 1.3.6.1.4.1.56521.101.2.3.13
NAME 'registrationRange'
DESC 'Numerical registration range expression'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
Examples: "-1", "1999", "1000000"
2.3.14. 'registrationStatus'
The 'registrationStatus' attribute type allows for the assignment of
status information meant to define the state of the registration.
A practical ABNF production for the super type, 'description', is
found within Section 3.3.6 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.14
NAME 'registrationStatus'
DESC 'Current registration status'
SUP description )
Examples: "OBSOLETE", "DEALLOCATED", "RESERVED"
2.3.15. 'registrationClassification'
The 'registrationClassification' attribute type allows a registration
to bear an informal classification value, thereby describing an OID's
context or category.
A practical ABNF production for the super type, 'description', can be
found within Section 3.3.6 in [RFC4517].
Coretta Expires February 23, 2025 [Page 12]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.15
NAME 'registrationClassification'
DESC 'Known registration classification'
SUP description
SINGLE-VALUE )
Examples: "Standard", "Individual", "ASN.1 Modules"
2.3.16. 'isLeafNode'
The 'isLeafNode' attribute type allows for the assignment of a single
Boolean value indicative of whether a registration can be a parent to
any subordinate registrations.
A practical ABNF production for this attribute type is found within
Section 3.3.3 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.16
NAME 'isLeafNode'
DESC 'Whether a registration may allocate sub arcs'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
Examples: "TRUE", "FALSE", or Undefined (implies "FALSE")
The 'isFrozen' attribute type allows for the assignment of a single
Boolean value indicative of whether a registration can be a parent
to any further subordinate registrations beyond those that already
exist at present.
A practical ABNF production for this attribute type is found within
Section 3.3.3 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.17
NAME 'isFrozen'
DESC 'Whether additional sub arcs are permitted'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
Examples: "TRUE", "FALSE", or Undefined (implies "FALSE")
2.3.18. 'standardizedNameForm'
The 'standardizedNameForm' attribute type allows for the assignment
of one (1) or more Standardized NameForm values, per clauses A.2 and
A.3 of ITU-T Rec. [X.660], to a registration only if its 'identifier'
value is considered standardized.
Coretta Expires February 23, 2025 [Page 13]
Internet-Draft The OID Directory: Schema August 2024
A practical ABNF production for this attribute type is as follows:
stdnf = LCURL nonfs RCURL
nonfs = nonf *( SPACE nonf )
nonf = ( identifier / number ) ; name OR number
SPACE = "%x20" ; " "
LCURL = "%x7b" ; "{"
RCURL = "%x7d" ; "}"
The 'identifier' ABNF originates in Section 2.3.7. The 'number' ABNF
production can be found within Section 1.4 of [RFC4512].
( 1.3.6.1.4.1.56521.101.2.3.18
NAME 'standardizedNameForm'
DESC 'X.660, cl. A.2-A-3: Standardized Identifier or NameForm'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Examples: "{itu-t}", "{0 0 d}"
2.3.19. 'nameAndNumberForm'
The 'nameAndNumberForm' attribute type allows for the assignment of
an ITU-T Rec. [X.680] NameAndNumberForm value to a registration.
A practical ABNF production for this attribute type is as follows:
nanf = name LPAREN number RPAREN ; name AND numberForm
name = identifier ; name form
LPAREN = "%x28" ; "("
RPAREN = "%x29" ; ")"
The 'identifier' ABNF production can be found in Section 2.3.7. The
'number' ABNF production is defined in Section 1.4 of [RFC4512].
( 1.3.6.1.4.1.56521.101.2.3.19
NAME 'nameAndNumberForm'
DESC 'X.680, cl. 32.3: NameAndNumberForm'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
Examples: "private(4)", "itu-t(0)"
The 'longArc' attribute type allows for the assignment of one (1) or
more so-called "Long Arc" well-known identifiers to a registration.
A practical ABNF production for this attribute type is as follows:
Coretta Expires February 23, 2025 [Page 14]
Internet-Draft The OID Directory: Schema August 2024
longArc = SOLIDUS ( intUV / nintUV )
nintUV = 1*iunreserved ; non-integer unicode value
intUV = number ; integer unicode value
( 1.3.6.1.4.1.56521.101.2.3.20
NAME 'longArc'
DESC 'X.660, cl. A.7: Long Arc'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
Examples: "/Example", "/Ejemplo"
The 'supArc' attribute type allows for the assignment of an LDAP DN
value to any non-root registration, thereby identifying the DN of the
immediate superior (parent) registration.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.21
NAME 'supArc'
DESC 'Immediate superior registration DN'
SUP distinguishedName
SINGLE-VALUE )
Example: "n=1,n=2,ou=Registrations,o=rA"
The 'c-supArc' attribute type is the manifestation of the 'supArc'
attribute type defined in Section 2.3.21 with Collective Attribute
[RFC3671] support.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
This attribute type MUST NOT be present for entries that also bear
a 'supArc' attribute type instance. The value MUST be singular.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
Coretta Expires February 23, 2025 [Page 15]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.22
NAME 'c-supArc'
DESC 'Collective immediate superior registration DN'
SUP distinguishedName
COLLECTIVE )
Example: "n=1,n=2,ou=Registrations,o=rA"
The 'topArc' attribute type allows for the assignment of an LDAP DN
value to any non-root registration, thereby identifying the superior
root registration.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.23
NAME 'topArc'
DESC 'Superior root registration DN'
SUP distinguishedName
SINGLE-VALUE )
Example: "n=2,ou=Registrations,o=rA"
The 'c-topArc' attribute type is the manifestation of the 'topArc'
attribute type defined in Section 2.3.23 with Collective Attribute
[RFC3671] support.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
This attribute type MUST NOT be present for entries that also bear
a 'topArc' attribute type instance. The value MUST be singular.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.24
NAME 'c-topArc'
DESC 'Collective superior root registration DN'
SUP distinguishedName
COLLECTIVE )
Coretta Expires February 23, 2025 [Page 16]
Internet-Draft The OID Directory: Schema August 2024
Example: "n=2,ou=Registrations,o=rA"
The 'subArc' attribute type allows for the assignment of one (1) or
more LDAP DN values to a registration as a manifest of subordinate
registrations residing exactly one (1) logical level below, if any.
In robust implementations of this I-D that cover most (or all) of the
OID Tree, use of this attribute type will require careful, long-term
planning.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.25
NAME 'subArc'
DESC 'Subordinate registration DN'
SUP distinguishedName )
Example: "n=1,n=6,n=3,n=1,ou=Registrations,o=rA"
The 'leftArc' attribute type allows for the assignment of a DN value
to a registration, referencing a registration positioned to the left
side of the bearer in terms of (lesser) 'n' magnitude.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.26
NAME 'leftArc'
DESC 'Nearest antecedent registration DN'
SUP distinguishedName
SINGLE-VALUE )
Example: "n=5,n=2,ou=Registrations,o=rA"
The 'minArc' attribute type allows for the assignment of a DN value
to a registration. The value SHOULD reference the entry which bears
the lowest 'n' value of any of its siblings.
Coretta Expires February 23, 2025 [Page 17]
Internet-Draft The OID Directory: Schema August 2024
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.27
NAME 'minArc'
DESC 'First or left-most sibling registration DN'
SUP distinguishedName
SINGLE-VALUE )
Example: "n=0,n=2,ou=Registrations,o=rA"
The 'c-minArc' attribute type is the manifestation of the attribute
type 'minArc', defined in Section 2.3.27 with Collective Attribute
[RFC3671] support.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
This attribute type MUST NOT be present for entries that also bear
a 'minArc' attribute type instance. The value MUST be singular.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.28
NAME 'c-minArc'
DESC 'Collective first or left-most sibling registration DN'
SUP distinguishedName
COLLECTIVE )
Example: "n=0,n=2,ou=Registrations,o=rA"
The 'rightArc' attribute type allows for the assignment of a DN value
to a registration, referencing a registration positioned to the right
side of the bearer in terms of (greater) 'n' magnitude.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
Coretta Expires February 23, 2025 [Page 18]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.29
NAME 'rightArc'
DESC 'Nearest subsequent registration DN'
SUP distinguishedName
SINGLE-VALUE )
Example: "n=2,n=2,ou=Registrations,o=rA"
The 'maxArc' attribute type allows for the assignment of a DN value
to a registration. The value SHOULD reference the entry which bears
the highest 'n' value of any of its siblings.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.30
NAME 'maxArc'
DESC 'Final or right-most sibling registration DN'
SUP distinguishedName
SINGLE-VALUE )
Example: "n=999,n=2,ou=Registrations,o=rA"
The 'c-maxArc' attribute type is the manifestation of the attribute
type 'maxArc', defined in Section 2.3.30 with Collective Attribute
[RFC3671] support.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
This attribute type MUST NOT be present for entries that also bear
a 'maxArc' attribute type instance. The value MUST be singular.
( 1.3.6.1.4.1.56521.101.2.3.31
NAME 'c-maxArc'
DESC 'Collective final or right-most sibling registration DN'
SUP distinguishedName
COLLECTIVE )
Example: "n=999,n=2,ou=Registrations,o=rA"
Coretta Expires February 23, 2025 [Page 19]
Internet-Draft The OID Directory: Schema August 2024
2.3.32. 'discloseTo'
The 'discloseTo' attribute type allows for the assignment of one (1)
or more LDAP DN values to a registration, each of which reference an
identity that is authorized to access one (1) or more confidential
registrations in read-only fashion.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.32
NAME 'discloseTo'
DESC 'Authorized registration reader'
SUP distinguishedName )
Example: "cn=AuthorizedReader,ou=Groups,o=rA"
2.3.33. 'c-discloseTo'
The 'c-discloseTo' attribute type is the COLLECTIVE manifestation of
the attribute type 'discloseTo', defined in Section 2.3.32.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
This attribute type MAY be present for entries that also bear a
'discloseTo' attribute type instance.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.33
NAME 'c-discloseTo'
DESC 'Collective authorized registration reader'
SUP distinguishedName
COLLECTIVE )
Example: "cn=ClearanceLevel4,ou=Groups,o=rA"
2.3.34. 'registrantID'
The 'registrantID' attribute type is intended to allow for singular
assignment of a UUID, GUID or some other auto-generated value to a
registrant entry.
No specific syntax is implied for values of this type.
Coretta Expires February 23, 2025 [Page 20]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.34
NAME 'registrantID'
DESC 'Unambiguous identifier assigned to an authority'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE )
Examples: "rfc4519", "65116e61-cc02-4c50-bde7-5bdaf4e973e4"
2.3.35. 'currentAuthority'
The 'currentAuthority' attribute type allows for the assignment of
one (1) or more DN values to a registration.
The value(s) of this attribute type are meant to refer to distinct
entries that contain current registrant authority information for
the registration to which it is linked.
This attribute type is only required if registrant information is not
stored within a given registration directly.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.35
NAME 'currentAuthority'
DESC 'DN for a registrant serving as the current authority'
SUP distinguishedName )
Example: "registrantID=XYZ,ou=Registrants,o=rA"
2.3.36. 'c-currentAuthority'
The 'c-currentAuthority' attribute type is the manifestation of the
'currentAuthority' attribute type, defined in Section 2.3.35 with
Collective Attribute [RFC3671] support.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
This attribute type MAY be present for entries that also bear
a 'currentAuthority' attribute type instance.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
Coretta Expires February 23, 2025 [Page 21]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.36
NAME 'c-currentAuthority'
DESC 'Collective DN for a current authority'
SUP distinguishedName )
Example: "registrantID=XYZ,ou=Registrants,o=rA"
2.3.37. 'currentAuthorityStartTimestamp'
The 'currentAuthorityStartTimestamp' attribute type allows for the
assignment of a generalized timestamp value to a current registration
authority. The value is indicative of the date and time at which the
current registration authority was, or will be, officiated.
A practical ABNF production for this attribute type is defined within
Section 3.3.13 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.37
NAME 'currentAuthorityStartTimestamp'
DESC 'Registration authority commencement timestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
Example: "19951231115959Z"
2.3.38. 'currentAuthorityCommonName'
The 'currentAuthorityCommonName' attribute type allows for the
assignment of a common name to a current authority entry.
The attribute type 'cn', as defined in Section 2.3 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.38
NAME 'currentAuthorityCommonName'
DESC 'Common Name for a current authority'
SUP cn
SINGLE-VALUE )
Example: "Jesse Coretta", "Jane Smith"
2.3.39. 'currentAuthorityCountryCode'
The 'currentAuthorityCountryCode' attribute type allows for the
assignment of a country code to a current authority entry.
The attribute type 'c', as defined in Section 2.2 of [RFC4519],
is a super type of this attribute type.
Coretta Expires February 23, 2025 [Page 22]
Internet-Draft The OID Directory: Schema August 2024
A practical ABNF production is found in Section 3.3.4 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.39
NAME 'currentAuthorityCountryCode'
DESC 'Country Code for a current authority'
SUP c
SINGLE-VALUE )
Examples: "US", "CA"
2.3.40. 'currentAuthorityCountryName'
The 'currentAuthorityCountryName' attribute type allows for the
assignment of a country name to a current authority entry.
The attribute type 'co', as defined in Section 2.4 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.40
NAME 'currentAuthorityCountryName'
DESC 'Country name for a current authority'
SUP co
SINGLE-VALUE )
Examples: "United States", "Canada"
2.3.41. 'currentAuthorityEmail'
The 'currentAuthorityEmail' attribute type allows for the assignment
of an email address to the current registration authority entry.
The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'IA5String'.
( 1.3.6.1.4.1.56521.101.2.3.41
NAME 'currentAuthorityEmail'
DESC 'Email address for a current authority'
SUP mail
SINGLE-VALUE )
Example: "jesse.coretta@icloud.com"
2.3.42. 'currentAuthorityFax'
The 'currentAuthorityFax' attribute type allows for the assignment
of a facsimile telephone number to a current authority entry.
Coretta Expires February 23, 2025 [Page 23]
Internet-Draft The OID Directory: Schema August 2024
The attribute type 'facsimileTelephoneNumber', as defined in Section
2.10 of [RFC4519], is a super type of this attribute type.
A practical ABNF production can be found within Section 3.3.11 of
[RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.42
NAME 'currentAuthorityFax'
DESC 'Facsimile telephone number for a current authority'
SUP facsimileTelephoneNumber
SINGLE-VALUE )
Example: "+11234567890"
2.3.43. 'currentAuthorityLocality'
The 'currentAuthorityLocality' attribute type allows for a locality
name to be assigned to a current authority entry.
The attribute type 'l', as defined in Section 2.16 of [RFC4519], is
a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.43
NAME 'currentAuthorityLocality'
DESC 'Locality name for a current authority'
SUP l
SINGLE-VALUE )
Example: "Palm Springs", "Anna Maria Island"
2.3.44. 'currentAuthorityMobile'
The 'currentAuthorityMobile' attribute type allows for the assignment
of a mobile telephone number to a current authority entry.
The attribute type 'mobile', as defined in Section 2.18 of [RFC4524],
is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'PrintableString'.
( 1.3.6.1.4.1.56521.101.2.3.44
NAME 'currentAuthorityMobile'
DESC 'Mobile telephone number for a current authority'
SUP mobile
SINGLE-VALUE )
Example: "+11234567890"
Coretta Expires February 23, 2025 [Page 24]
Internet-Draft The OID Directory: Schema August 2024
2.3.45. 'currentAuthorityOrg'
The 'currentAuthorityOrg' attribute type allows for the assignment of
an organization name to a current authority entry.
The attribute type 'o', as defined in Section 2.19 of [RFC4519], is
a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.45
NAME 'currentAuthorityOrg'
DESC 'Organization name for a current authority'
SUP o
SINGLE-VALUE )
Example: "Acme, Co."
2.3.46. 'currentAuthorityPOBox'
The 'currentAuthorityPOBox' attribute type allows for the assignment
of a post office box number to a current authority entry.
The attribute type 'postOfficeBox', as defined in Section 2.25 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.46
NAME 'currentAuthorityPOBox'
DESC 'Post office box number for a current authority'
SUP postOfficeBox
SINGLE-VALUE )
Examples: "555", "475"
2.3.47. 'currentAuthorityPostalAddress'
The 'currentAuthorityPostalAddress' attribute type allows for the
assignment of a complete postal address to a current authority entry.
This single attribute may be used instead of other individual address
component attribute types, but will require field parsing on part of
the client.
The attribute type 'postalAddress', as defined in Section 2.23 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.28 in [RFC4517].
Coretta Expires February 23, 2025 [Page 25]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.47
NAME 'currentAuthorityPostalAddress'
DESC 'Full postal address for a current authority'
SUP postalAddress
SINGLE-VALUE )
Example: "1 Fake St$Anytown$CA$12345$US"
2.3.48. 'currentAuthorityPostalCode'
The 'currentAuthorityPostalCode' attribute type allows for a postal
code to be assigned to a current authority entry.
The attribute type 'postalCode', as defined in Section 2.23 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.48
NAME 'currentAuthorityPostalCode'
DESC 'Postal code for a current authority'
SUP postalCode
SINGLE-VALUE )
Examples: "92262", "34216"
2.3.49. 'currentAuthorityState'
The 'currentAuthorityState' attribute type allows for a state or
province name to be assigned to a current authority entry.
The attribute type 'st', as defined in Section 2.33 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.49
NAME 'currentAuthorityState'
DESC 'State or province name for a current authority'
SUP st
SINGLE-VALUE )
Examples: "California", "North Dakota"
2.3.50. 'currentAuthorityStreet'
The 'currentAuthorityStreet' attribute type allows for the assignment
of a street name and number to a current authority entry.
The attribute type 'street', as defined in Section 2.34 of [RFC4519],
is a super type of this attribute type.
Coretta Expires February 23, 2025 [Page 26]
Internet-Draft The OID Directory: Schema August 2024
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.50
NAME 'currentAuthorityStreet'
DESC 'Street name and number for a current authority'
SUP street
SINGLE-VALUE )
Example: "1 Fake Street"
2.3.51. 'currentAuthorityTelephone'
The 'currentAuthorityTelephone' attribute type allows for a telephone
number to be assigned to a current authority entry.
The attribute type 'telephoneNumber', as defined in Section 2.35 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'PrintableString'.
( 1.3.6.1.4.1.56521.101.2.3.51
NAME 'currentAuthorityTelephone'
DESC 'Telephone number assigned to a current authority'
SUP telephoneNumber
SINGLE-VALUE )
Example: "+11234567890"
2.3.52. 'currentAuthorityTitle'
The 'currentAuthorityTitle' attribute type allows for the assignment
of an official or professional title to a current authority entry.
The attribute type 'title', as defined in Section 2.38 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.52
NAME 'currentAuthorityTitle'
DESC 'Title assigned to a current authority'
SUP title
SINGLE-VALUE )
Example: "Chief Engineer"
2.3.53. 'currentAuthorityURI'
The 'currentAuthorityURI' attribute type allows for the assignment of
one (1) or more URI values to a current authority entry.
Coretta Expires February 23, 2025 [Page 27]
Internet-Draft The OID Directory: Schema August 2024
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
A practical ABNF production for this attribute type is defined within
Appendix A of [RFC3986].
( 1.3.6.1.4.1.56521.101.2.3.53
NAME 'currentAuthorityURI'
DESC 'Uniform Resource Identifier for a current authority'
SUP labeledURI )
Example: "http://example.com Example", "http://example.com"
2.3.54. 'firstAuthority'
The 'firstAuthority' attribute type allows for the assignment of one
(1) or more DN values to a registration entry.
The value(s) of this attribute type are meant to refer to distinct
entries that contain previous authority information.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.54
NAME 'firstAuthority'
DESC 'DN of a previous authority'
SUP distinguishedName )
Example: "registrantID=XYZ,ou=Registrants,o=rA"
2.3.55. 'c-firstAuthority'
The 'c-firstAuthority' attribute type is the manifestation of the
'firstAuthority' attribute type, defined in Section 2.3.54 with
Collective Attribute [RFC3671] support.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
This attribute type MAY be present for entries that also bear
a 'firstAuthority' attribute type instance.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
Coretta Expires February 23, 2025 [Page 28]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.55
NAME 'c-firstAuthority'
DESC 'Collective DN of a previous authority'
SUP distinguishedName
COLLECTIVE )
Example: "registrantID=XYZ,ou=Registrants,o=rA"
2.3.56. 'firstAuthorityStartTimestamp'
The 'firstAuthorityStartTimestamp' attribute type allows for the
assignment of a generalized timestamp value to a previous authority,
indicative of the date and time at which the previous authority was
officiated.
A practical ABNF production for this attribute type is defined within
Section 3.3.13 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.56
NAME 'firstAuthorityStartTimestamp'
DESC 'Previous registration authority commencement timestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
Example: "20130105135904Z"
2.3.57. 'firstAuthorityEndTimestamp'
The 'firstAuthorityEndTimestamp' attribute type allows the assignment
of a generalized timestamp value to a previous authority, indicative
of the date and time at which an entity's authoritative role was, or
will be, terminated.
A practical ABNF production for this attribute type is defined within
Section 3.3.13 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.57
NAME 'firstAuthorityEndTimestamp'
DESC 'Previous registration authority termination timestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
Example: "20170528110555Z"
2.3.58. 'firstAuthorityCommonName'
The 'firstAuthorityCommonName' attribute type allows for a common
name to be assigned to a previous registration authority entry.
Coretta Expires February 23, 2025 [Page 29]
Internet-Draft The OID Directory: Schema August 2024
The attribute type 'cn', as defined in Section 2.3 of [RFC4519], is
a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.58
NAME 'firstAuthorityCommonName'
DESC 'Common Name for a previous authority'
SUP cn
SINGLE-VALUE )
Examples: "Jesse Coretta", "Jane Smith"
2.3.59. 'firstAuthorityCountryCode'
The 'firstAuthorityCountryCode' attribute type allows for a country
code to be assigned to a previous registration authority entry.
The attribute type 'c', as defined in Section 2.2 of [RFC4519], is a
super type of this attribute type.
A practical ABNF production is found in Section 3.3.4 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.59
NAME 'firstAuthorityCountryCode'
DESC 'Country Code for a previous authority'
SUP c
SINGLE-VALUE )
Examples: "US", "CA"
2.3.60. 'firstAuthorityCountryName'
The 'firstAuthorityCountryName' attribute type allows for a country
name to be assigned to a previous registration authority entry.
The attribute type 'co', as defined in Section 2.4 of [RFC4519], is a
super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.60
NAME 'firstAuthorityCountryName'
DESC 'Country name for a previous authority'
SUP co
SINGLE-VALUE )
Examples: "United States", "Canada"
Coretta Expires February 23, 2025 [Page 30]
Internet-Draft The OID Directory: Schema August 2024
2.3.61. 'firstAuthorityEmail'
The 'firstAuthorityEmail' attribute type allows for the assignment
of an email address to a previous registration authority entry.
The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'IA5String'.
( 1.3.6.1.4.1.56521.101.2.3.61
NAME 'firstAuthorityEmail'
DESC 'Email address for a previous authority'
SUP mail
SINGLE-VALUE )
Example: "jesse.coretta@icloud.com"
2.3.62. 'firstAuthorityFax'
The 'firstAuthorityFax' attribute type allows for the assignment of a
facsimile telephone number to a previous authority entry.
The attribute type 'facsimileTelephoneNumber', as defined in Section
2.10 of [RFC4519], is a super type of this attribute type.
A practical ABNF production can be found within Section 3.3.11 of
[RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.62
NAME 'firstAuthorityFax'
DESC 'Facsimile telephone number for a previous authority'
SUP facsimileTelephoneNumber
SINGLE-VALUE )
Example: "+11234567890"
2.3.63. 'firstAuthorityLocality'
The 'firstAuthorityLocality' attribute type allows the assignment of
a locality name to a previous authority entry.
The attribute type 'l', as defined in Section 2.16 of [RFC4519], is
a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
Coretta Expires February 23, 2025 [Page 31]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.63
NAME 'firstAuthorityLocality'
DESC 'Locality name for a previous authority'
SUP l
SINGLE-VALUE )
Examples: "Palm Springs", "Anna Maria Island"
2.3.64. 'firstAuthorityMobile'
The 'firstAuthorityMobile' attribute type allows for the assignment
of a mobile telephone number to a previous authority entry.
The attribute type 'mobile', as defined in Section 2.18 of [RFC4524],
is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'PrintableString'.
( 1.3.6.1.4.1.56521.101.2.3.64
NAME 'firstAuthorityMobile'
DESC 'Mobile telephone number for a previous authority'
SUP mobile
SINGLE-VALUE )
Example: "+11234567890"
2.3.65. 'firstAuthorityOrg'
The 'firstAuthorityOrg' attribute type allows for the assignment
of an organization name to a previous authority entry.
The attribute type 'o', as defined in Section 2.19 of [RFC4519], is
a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.65
NAME 'firstAuthorityOrg'
DESC 'Organization name for a previous authority'
SUP o
SINGLE-VALUE )
Example: "Acme, Co."
2.3.66. 'firstAuthorityPOBox'
The 'firstAuthorityPOBox' attribute type allows for the assignment
of a post office box number to a previous registration authority
entry.
Coretta Expires February 23, 2025 [Page 32]
Internet-Draft The OID Directory: Schema August 2024
The attribute type 'postOfficeBox', as defined in Section 2.25 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.66
NAME 'firstAuthorityPOBox'
DESC 'Post office box number for a previous authority'
SUP postOfficeBox
SINGLE-VALUE )
Examples: "555", "475"
2.3.67. 'firstAuthorityPostalAddress'
The 'firstAuthorityPostalAddress' attribute type allows for the
assignment of a complete postal address to a previous registration
authority entry. This single attribute may be used instead of other
individual address component attribute types, but will require field
parsing on the client side.
The attribute type 'postalAddress', as defined in Section 2.23 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.28 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.67
NAME 'firstAuthorityPostalAddress'
DESC 'Full postal address for a previous authority'
SUP postalAddress
SINGLE-VALUE )
Example: "1 Fake St$Anytown$CA$12345$US"
2.3.68. 'firstAuthorityPostalCode'
The 'firstAuthorityPostalCode' attribute type allows for the
assignment of a postal code to a previous registration authority
entry.
The attribute type 'postalCode', as defined in Section 2.23 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.68
NAME 'firstAuthorityPostalCode'
DESC 'Postal code for a previous authority'
SUP postalCode
SINGLE-VALUE )
Examples: "92262", "34216"
Coretta Expires February 23, 2025 [Page 33]
Internet-Draft The OID Directory: Schema August 2024
2.3.69. 'firstAuthorityState'
The 'firstAuthorityState' attribute type allows for the assignment
of a state or province name to a previous registration authority
entry.
The attribute type 'st', as defined in Section 2.33 of [RFC4519], is
a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.69
NAME 'firstAuthorityState'
DESC 'State or province name for a previous authority'
SUP st
SINGLE-VALUE )
Examples: "California", "North Dakota"
2.3.70. 'firstAuthorityStreet'
The 'firstAuthorityStreet' attribute type allows for the assignment
of a street name and number to a previous authority entry.
The attribute type 'street', as defined in Section 2.34 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.70
NAME 'firstAuthorityStreet'
DESC 'Street name and number for a previous authority'
SUP street
SINGLE-VALUE )
Example: "1 Fake Street"
2.3.71. 'firstAuthorityTelephone'
The 'firstAuthorityTelephone' attribute type allows the assignment of
a telephone number to a previous authority entry.
The attribute type 'telephoneNumber', as defined in Section 2.35 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'PrintableString'.
Coretta Expires February 23, 2025 [Page 34]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.71
NAME 'firstAuthorityTelephone'
DESC 'Telephone number for a previous authority'
SUP telephoneNumber
SINGLE-VALUE )
Example: "+11234567890"
2.3.72. 'firstAuthorityTitle'
The 'firstAuthorityTitle' attribute type allows for the assignment
of an official or professional title to a previous authority entry.
The attribute type 'title', as defined in Section 2.38 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.72
NAME 'firstAuthorityTitle'
DESC 'Title of a previous authority'
SUP title
SINGLE-VALUE )
Example: "Chief Engineer"
2.3.73. 'firstAuthorityURI'
The 'firstAuthorityURI' attribute type allows the assignment of one
(1) or more URI values to a previous authority entry.
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
A practical ABNF production for this attribute type is defined within
Appendix A of [RFC3986].
( 1.3.6.1.4.1.56521.101.2.3.73
NAME 'firstAuthorityURI'
DESC 'Uniform Resource Identifier for a previous authority'
SUP labeledURI )
Examples: "http://example.com Example", "http://example.com"
The 'sponsor' attribute type allows for the assignment of one (1)
or more DN values to a registration.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
Coretta Expires February 23, 2025 [Page 35]
Internet-Draft The OID Directory: Schema August 2024
The attribute type 'distinguishedName', as defined in Section 2.7 of
[RFC4519], is a super type of this attribute type.
( 1.3.6.1.4.1.56521.101.2.3.74
NAME 'sponsor'
DESC 'DN of a sponsoring authority'
SUP distinguishedName )
Example: "registrantID=XYZ,ou=Registrants,o=rA"
2.3.75. 'c-sponsor'
The 'c-sponsor' attribute type is the manifestation of the 'sponsor'
attribute type, defined in Section 2.3.74 with Collective Attribute
[RFC3671] support.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
This attribute type MAY be present for entries that also bear
a 'sponsor' attribute type instance.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
( 1.3.6.1.4.1.56521.101.2.3.75
NAME 'c-sponsor'
DESC 'Collective DN of a sponsoring authority'
SUP distinguishedName
COLLECTIVE )
Example: "registrantID=XYZ,ou=Registrants,o=rA"
2.3.76. 'sponsorStartTimestamp'
The 'sponsorStartTimestamp' attribute type allows for the assignment
of a generalized timestamp value to a sponsor entry, indicative of
the date and time at which sponsorship was, or will be, officiated.
A practical ABNF production for this attribute type is defined within
Section 3.3.13 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.76
NAME 'sponsorStartTimestamp'
DESC 'Sponsoring authority commencement timestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
Example: "20130105135904Z"
Coretta Expires February 23, 2025 [Page 36]
Internet-Draft The OID Directory: Schema August 2024
2.3.77. 'sponsorEndTimestamp'
The 'sponsorEndTimestamp' attribute type allows for the assignment
of a generalized timestamp value to a sponsor entry, indicative the
date and time at which sponsorship was, or will be, terminated.
A practical ABNF production for this attribute type is defined within
Section 3.3.13 of [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.77
NAME 'sponsorEndTimestamp'
DESC 'Sponsoring authority termination timestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
Example: "20170528110555Z"
2.3.78. 'sponsorCommonName'
The 'sponsorCommonName' attribute type allows for the assignment
of a common name to a sponsor.
The attribute type 'cn', as defined in Section 2.3 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.78
NAME 'sponsorCommonName'
DESC 'Common Name of a sponsor'
SUP cn
SINGLE-VALUE )
Example: "Jane Sponsor"
2.3.79. 'sponsorCountryCode'
The 'sponsorCountryCode' attribute type allows for the assignment of
a two-letter country code to a sponsor.
The attribute type 'c', as defined in Section 2.2 of [RFC4519], is a
super type of this attribute type.
A practical ABNF production is found in Section 3.3.4 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.79
NAME 'sponsorCountryCode'
DESC 'Country code for a sponsor'
SUP c
SINGLE-VALUE )
Coretta Expires February 23, 2025 [Page 37]
Internet-Draft The OID Directory: Schema August 2024
Examples: "US", "CA"
2.3.80. 'sponsorCountryName'
The 'sponsorCountryName' attribute type allows the assignment of a
country name to a sponsor.
The attribute type 'co', as defined in Section 2.4 of [RFC4524], is
a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.80
NAME 'sponsorCountryName'
DESC 'Country name for a sponsor'
SUP co
SINGLE-VALUE )
Examples: "United States", "Canada"
2.3.81. 'sponsorEmail'
The 'sponsorEmail' attribute type allows for the assignment of an
email address to a sponsor.
The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'IA5String'.
( 1.3.6.1.4.1.56521.101.2.3.81
NAME 'sponsorEmail'
DESC 'Email address for a sponsor'
SUP mail
SINGLE-VALUE )
Example: "sponsor@example.com"
2.3.82. 'sponsorFax'
The 'sponsorFax' attribute type allows for the assignment of a
facsimile telephone number to a sponsor.
The attribute type 'facsimileTelephoneNumber', as defined in Section
2.10 of [RFC4519], is a super type of this attribute type.
A practical ABNF production can be found within Section 3.3.11 of
[RFC4517].
Coretta Expires February 23, 2025 [Page 38]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.82
NAME 'sponsorFax'
DESC 'Facsimile telephone number for a sponsor'
SUP facsimileTelephoneNumber
SINGLE-VALUE )
Example: "+11234567890"
2.3.83. 'sponsorLocality'
The 'sponsorLocality' attribute type allows for the assignment of
a locality name to a sponsor.
The attribute type 'l', as defined in Section 2.16 of [RFC4519], is
a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.83
NAME 'sponsorLocality'
DESC 'Locality name for a sponsor'
SUP l
SINGLE-VALUE )
Examples: "Palm Springs", "Anna Maria Island"
2.3.84. 'sponsorMobile'
The 'sponsorMobile' attribute type allows for the assignment of a
mobile telephone number to a sponsor.
The attribute type 'mobile', as defined in Section 2.18 of [RFC4524],
is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'PrintableString'.
( 1.3.6.1.4.1.56521.101.2.3.84
NAME 'sponsorMobile'
DESC 'Mobile telephone number for a sponsor'
SUP mobile
SINGLE-VALUE )
Example: "+11234567890"
2.3.85. 'sponsorOrg'
The 'sponsorOrg' attribute type allows for the assignment of an
organization name to a sponsor.
The attribute type 'o', as defined in Section 2.19 of [RFC4519],
is a super type of this attribute type.
Coretta Expires February 23, 2025 [Page 39]
Internet-Draft The OID Directory: Schema August 2024
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.85
NAME 'sponsorOrg'
DESC 'Organization name for a sponsor'
SUP o
SINGLE-VALUE )
Example: "Sponsor, Co."
2.3.86. 'sponsorPOBox'
The 'sponsorPOBox' attribute type allows for the assignment of a
post office box number to a sponsor.
The attribute type 'postOfficeBox', as defined in Section 2.25 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.86
NAME 'sponsorPOBox'
DESC 'Post office box number for a sponsor'
SUP postOfficeBox
SINGLE-VALUE )
Examples: "555", "475"
2.3.87. 'sponsorPostalAddress'
The 'sponsorPostalAddress' attribute type allows for the assignment
of a complete postal address sponsor. This single attribute may be
used instead of other individual address component attribute types,
but will require field parsing on the client side.
The attribute type 'postalAddress', as defined in Section 2.23 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.28 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.87
NAME 'sponsorPostalAddress'
DESC 'Full postal address for a sponsor'
SUP postalAddress
SINGLE-VALUE )
Example: "1 Fake St$Anytown$CA$12345$US"
2.3.88. 'sponsorPostalCode'
The 'sponsorPostalCode' attribute type allows for a postal code
to be assigned to a sponsor.
Coretta Expires February 23, 2025 [Page 40]
Internet-Draft The OID Directory: Schema August 2024
The attribute type 'postalCode', as defined in Section 2.23 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.88
NAME 'sponsorPostalCode'
DESC 'Postal code for a sponsor'
SUP postalCode
SINGLE-VALUE )
Example: "92262", "34216"
2.3.89. 'sponsorState'
The 'sponsorState' attribute type allows for the assignment of a
state or province name to a sponsor.
The attribute type 'st', as defined in Section 2.33 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.89
NAME 'sponsorState'
DESC 'State or province name for a sponsor'
SUP st
SINGLE-VALUE )
Examples: "California", "North Dakota"
2.3.90. 'sponsorStreet'
The 'sponsorStreet' attribute type allows for the assignment of a
street name and number to a sponsor.
The attribute type 'street', as defined in Section 2.34 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.90
NAME 'sponsorStreet'
DESC 'Street name and number for a sponsor'
SUP street
SINGLE-VALUE )
Example: "1 Fake Street"
Coretta Expires February 23, 2025 [Page 41]
Internet-Draft The OID Directory: Schema August 2024
2.3.91. 'sponsorTelephone'
The 'sponsorTelephone' attribute type allows for the assignment of
a telephone number to a sponsor.
The attribute type 'telephoneNumber', as defined in Section 2.35 of
[RFC4519], is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'PrintableString'.
( 1.3.6.1.4.1.56521.101.2.3.91
NAME 'sponsorTelephone'
DESC 'Telephone number for a sponsor'
SUP telephoneNumber
SINGLE-VALUE )
Example: "+11234567890"
2.3.92. 'sponsorTitle'
The 'sponsorTitle' attribute type allows for the assignment of an
official or professional title to a sponsor.
The attribute type 'title', as defined in Section 2.38 of [RFC4519],
is a super type of this attribute type.
A practical ABNF production is found in Section 3.3.6 in [RFC4517].
( 1.3.6.1.4.1.56521.101.2.3.92
NAME 'sponsorTitle'
DESC 'Title of a sponsor'
SUP title
SINGLE-VALUE )
Example: "Executive Sponsor"
2.3.93. 'sponsorURI'
The 'sponsorURI' attribute type allows for the assignment of one (1)
or more URI values, each with an optional label, to a sponsor.
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
A practical ABNF production for this attribute type is defined within
Appendix A of [RFC3986].
( 1.3.6.1.4.1.56521.101.2.3.93
NAME 'sponsorURI'
DESC 'Uniform Resource Identifier for a sponsor'
SUP labeledURI )
Coretta Expires February 23, 2025 [Page 42]
Internet-Draft The OID Directory: Schema August 2024
Examples: "http://example.com Example", "http://example.com"
2.3.94. 'rADITProfile'
The 'rADITProfile' attribute type references entries which contain
optimal 'rADUAConfig' configuration settings for client consumption.
The attribute type 'distinguishedName', as defined in Section 2.7
of [RFC4519], is a super type of this attribute type.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
( 1.3.6.1.4.1.56521.101.2.3.94
NAME 'rADITProfile'
DESC 'Advertised RA DIT profile DNs served by an RA DSA'
SUP distinguishedName )
Examples: "n=1,dc=example,dc=com" "n=1,n=4,n=1,n=6,n=3,n=1"
2.3.95. 'rARegistrationBase'
The 'rARegistrationBase' attribute type allows for the storage of one
(1) or more DNs that refer to entries under which 'registration'
entries reside.
The attribute type 'distinguishedName', as defined in Section 2.7
of [RFC4519], is a super type of this attribute type.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
( 1.3.6.1.4.1.56521.101.2.3.95
NAME 'rARegistrationBase'
DESC 'DN of a registration base within an RA DIT'
SUP distinguishedName )
Example: "ou=Registrations,o=rA"
2.3.96. 'rARegistrantBase'
The 'rARegistrantBase' attribute type allows for the storage of one
(1) or more LDAP DNs that refer to entries under which 'registrant'
entries reside.
The attribute type 'distinguishedName', as defined in Section 2.7
of [RFC4519], is a super type of this attribute type.
A practical ABNF production for this attribute type can be found in
Section 3 of [RFC4514].
Coretta Expires February 23, 2025 [Page 43]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.3.96
NAME 'rARegistrantBase'
DESC 'DN of a registrant base within an RA DIT'
SUP distinguishedName )
Example: "ou=Registrants,o=rA"
2.3.97. 'rADirectoryModel'
The 'rADirectoryModel' attribute type allows for the storage of a
numerical OID meant to declare the structural design of the RA DIT.
A practical ABNF production, labeled 'numericoid', is defined within
Section 1.4 of [RFC4512].
( 1.3.6.1.4.1.56521.101.2.3.97
NAME 'rADirectoryModel'
DESC 'Governing directory model OID'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE )
Example: "1.3.6.1.4.1.56521.101.3.1.3"
2.3.98. 'rAServiceMail'
The 'rAServiceMail' attribute type allows for the assignment of an
email address to an 'rADUAConfig' entry for the purpose of support
or error reporting.
The attribute type 'mail', as defined in Section 2.16 of [RFC4524],
is a super type of this attribute type.
A practical ABNF production can be found in Section 3.2 of [RFC4517],
labeled 'IA5String'.
( 1.3.6.1.4.1.56521.101.2.3.98
NAME 'rAServiceMail'
DESC 'Registration Authority contact email address'
SUP mail )
Example: "ra@example.com"
2.3.99. 'rAServiceURI'
The 'rAServiceURI' attribute type allows for the assignment of one
(1) or more URI values to an 'rADUAConfig' entry for the purpose of
directing users to an appropriate RA endpoint for request handling.
The attribute type 'labeledURI', as defined in [RFC2079], is a super
type of this attribute type.
Coretta Expires February 23, 2025 [Page 44]
Internet-Draft The OID Directory: Schema August 2024
A practical ABNF production for this attribute type is defined within
Appendix A of [RFC3986].
( 1.3.6.1.4.1.56521.101.2.3.99
NAME 'rAServiceURI'
DESC 'Registration Authority URI'
SUP labeledURI )
Example: "http://example.com/ra.html Registrations"
The 'rATTL' attribute type allows for the specification of a TTL
value, expressed in seconds.
A practical ABNF production, labeled 'number', can be found within
Section 1.4 of [RFC4512].
See the RADUA I-D for details relating to client-driven entry
caching and practical value implementation.
( 1.3.6.1.4.1.56521.101.2.3.100
NAME 'rATTL'
DESC 'RA entry Time to Live, expressed in seconds'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
Examples: "0", "3600", "-1", "86400"
The 'c-rATTL' attribute type is the manifestation of the 'rATTL'
type, defined in Section 2.3.99 with Collective Attribute support.
This attribute type should only be used in directory environments
which actively support and require [RFC3671] capabilities.
See the RADUA I-D for details relating to client-driven entry
caching and practical value implementation.
A practical ABNF production, labeled 'number', can be found within
Section 1.4 of [RFC4512].
( 1.3.6.1.4.1.56521.101.2.3.101
NAME 'c-rATTL'
DESC 'Collective RA entry Time to Live, expressed in seconds'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
COLLECTIVE )
Coretta Expires February 23, 2025 [Page 45]
Internet-Draft The OID Directory: Schema August 2024
2.3.102. 'registeredUUID'
The 'registeredUUID' attribute type assigns a hexadecimal UUID value
to a registration, as covered in ITU-T Rec. [X.667].
A practical ABNF production for this attribute type is defined within
[RFC9562], but will depend on the UUID version supported by the given
RA DSA(s).
( 1.3.6.1.4.1.56521.101.2.3.102
NAME 'registeredUUID'
DESC 'X.667 registered UUID'
EQUALITY UUIDMatch
ORDERING UUIDOrderingMatch
SYNTAX 1.3.6.1.1.16.1
SINGLE-VALUE )
Example: "e6bcf22c-00bf-4b3d-b11f-36ec0522aa93"
2.3.103. 'dotEncoding'
The 'dotEncoding' attributeType allows the storage of the raw ASN.1
encoding of the 'dotNotation' for a registration. Clients SHOULD
expect values of the 'dotEncoding' attribute type to manifest as
Base64-encoded content.
A practical ABNF production for this attribute type is as follows:
dotEncoding = tag length bytes
tag = "%x06" ; ASN.1 OBJECT IDENTIFIER tag (6)
length = 1*OCTET ; BE number of encoded bytes
bytes = 1*OCTET ; encoded bytes
The 'OCTET' ABNF production is defined within [RFC4512] Section 1.4.
The OID encoding scheme is defined within clause 8.19 of ITU-T Rec.
[X.690].
( 1.3.6.1.4.1.56521.101.2.3.103
NAME 'dotEncoding'
DESC 'X.690 cl. 8.19: encoded numeric OID'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE )
Example: "BgEr"
2.4. Matching Rule Uses
No LDAP Matching Rule Uses definitions are defined anywhere in this
I-D series.
Coretta Expires February 23, 2025 [Page 46]
Internet-Draft The OID Directory: Schema August 2024
2.5. Object Classes
The following subsections describe seventeen (17) object classes
defined within this I-D.
2.5.1. 'registration'
The 'registration' ABSTRACT class, which is a sub type of 'top', per
Section 2.4.1 of [RFC4512], serves as the foundation for ALL entries
intended to represent OID registrations in the spirit of this I-D.
( 1.3.6.1.4.1.56521.101.2.5.1
NAME 'registration'
DESC 'Abstract OID arc class'
SUP top ABSTRACT
MUST n
MAY ( description $ seeAlso $ rATTL ) )
2.5.2. 'rootArc'
The 'rootArc' STRUCTURAL class is meant to define a maximum of three
(3) root registrations for an RA DIT, per ITU-T Rec. [X.660].
Entries that bear this class SHALL ONLY represent the following root
registrations:
- ITU-T ({itu-t(0)})
- ISO ({iso(1)})
- Joint-ISO-ITU-T ({joint-iso-itu-t(2)})
( 1.3.6.1.4.1.56521.101.2.5.2
NAME 'rootArc'
DESC 'X.660, cl. A.2: root arc class'
SUP registration STRUCTURAL )
The 'arc' STRUCTURAL object class extends a collection of attribute
types for use when allocating subordinate registrations in an RA DIT.
( 1.3.6.1.4.1.56521.101.2.5.3
NAME 'arc'
DESC 'X.660, cl. A.3-A.5: subordinate arc class'
SUP registration STRUCTURAL )
2.5.4. 'x660Context'
The 'x660Context' AUXILIARY class extends a collection of attribute
types derived from Rec. ITU-T [X.660].
Coretta Expires February 23, 2025 [Page 47]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.5.4
NAME 'x660Context'
DESC 'X.660 contextual class'
SUP registration AUXILIARY
MAY ( additionalUnicodeValue $
currentAuthority $
firstAuthority $
secondaryIdentifier $
sponsor $
standardizedNameForm $
unicodeValue ) )
2.5.5. 'x667Context'
The 'x667Context' AUXILIARY class extends a single attribute type,
'registeredUUID' as defined in Section 2.3.101, for use within the
context of an ITU-T Rec. [X.667] (UUID) registration.
( 1.3.6.1.4.1.56521.101.2.5.5
NAME 'x667Context'
DESC 'X.667 contextual class'
SUP registration AUXILIARY
MUST registeredUUID )
2.5.6. 'x680Context'
The 'x680Context' AUXILIARY class extends a collection of attribute
types derived from ITU-T Rec. [X.680].
( 1.3.6.1.4.1.56521.101.2.5.6
NAME 'x680Context'
DESC 'X.680 contextual class'
SUP registration AUXILIARY
MAY ( aSN1Notation $
dotNotation $
identifier $
iRI $
nameAndNumberForm ) )
2.5.7. 'x690Context'
The 'x690Context' AUXILIARY class extends a collection of attribute
types derived from ITU-T Rec. [X.690]. Any additional encoding types
that may be added in future revisions or extensions of this I-D will
be specified in the MAY clause of this class.
( 1.3.6.1.4.1.56521.101.2.5.7
NAME 'x690Context'
DESC 'X.690 contextual class'
SUP registration AUXILIARY
MAY dotEncoding )
Coretta Expires February 23, 2025 [Page 48]
Internet-Draft The OID Directory: Schema August 2024
2.5.8. 'iTUTRegistration'
The 'iTUTRegistration' AUXILIARY class labels the registration as
belonging to the International Telecommunications Union (ITU-T) in
subordinate form.
It is NOT RECOMMENDED to assign this class to any entry which bears
the 'rootArc' STRUCTURAL object class, per in Section 2.5.1. This
class SHALL NOT appear on entries bearing the 'iSORegistration' (per
Section 2.5.9) or 'jointISOITUTRegistration' (per Section 2.5.10)
class.
The 'x660Context' (Section 2.5.4), 'x680Context' (Section 2.5.6) and
'x690Context' (Section 2.5.7) are super classes of this class.
( 1.3.6.1.4.1.56521.101.2.5.8
NAME 'iTUTRegistration'
DESC 'X.660, cl. A.2: ITU-T'
SUP ( x660Context $
x680Context $
x690Context )
AUXILIARY )
2.5.9. 'iSORegistration'
The 'iSORegistration' AUXILIARY class labels the OID registration as
belonging to the International Organization for Standardization (ISO)
in subordinate form.
It is NOT RECOMMENDED to assign this class to any entry which bears
the 'rootArc' STRUCTURAL object class, per Section 2.5.1. This class
SHALL NOT appear on entries bearing the 'iTUTRegistration' (defined
in Section 2.5.8) or 'jointISOITUTRegistration' (per Section 2.5.10)
class.
The 'x660Context' (Section 2.5.4), 'x680Context' (Section 2.5.6) and
'x690Context' (Section 2.5.7) are super classes of this class.
( 1.3.6.1.4.1.56521.101.2.5.9
NAME 'iSORegistration'
DESC 'X.660, cl. A.2: ISO'
SUP ( x660Context $
x680Context $
x690Context )
AUXILIARY )
2.5.10. 'jointISOITUTRegistration'
The 'jointISOITUTRegistration' AUXILIARY class labels a registration
as being jointly administered by the International Organization for
Standardization (ISO) and the International Telecommunications Union
(ITU-T) in cooperative fashion.
Coretta Expires February 23, 2025 [Page 49]
Internet-Draft The OID Directory: Schema August 2024
It is NOT RECOMMENDED to assign this class to any entry which bears
the 'rootArc' STRUCTURAL object class, per Section 2.5.1. This class
SHALL NOT appear on entries bearing the 'iTUTRegistration' (defined
in Section 2.5.8) or 'iSORegistration' (per Section 2.5.9) class.
This class extends use of the 'longArc' attribute type, as defined in
Section 2.3.20.
The 'x660Context' (Section 2.5.4), 'x667Context' (Section 2.5.5),
'x680Context' (Section 2.5.6) and 'x690Context' (Section 2.5.7)
object classes are super classes of this class.
( 1.3.6.1.4.1.56521.101.2.5.10
NAME 'jointISOITUTRegistration'
DESC 'X.660, cl. A.2: Joint ISO/ITU-T Administration'
SUP ( x660Context $
x680Context $
x690Context )
AUXILIARY
MAY longArc )
2.5.11. 'spatialContext'
The 'spatialContext' AUXILIARY class extends vertical and horizontal
associative attribute types intended to describe the logical position
of a registration in relation to adjacent registrations.
Use of this class is entirely OPTIONAL, but can greatly aid in the
creation of navigational interfaces which allow both horizontal and
vertical movement across entire ancestries.
See the RADIT I-D for further details on this topic.
( 1.3.6.1.4.1.56521.101.2.5.11
NAME 'spatialContext'
DESC 'Logical spatial orientation and association class'
SUP registration AUXILIARY
MAY ( topArc $
supArc $
subArc $
minArc $
maxArc $
leftArc $
rightArc ) )
2.5.12. 'registrationSupplement'
The 'registrationSupplement' AUXILIARY class extends a variety of
miscellaneous and non-standard attribute types for OPTIONAL.
Coretta Expires February 23, 2025 [Page 50]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.5.12
NAME 'registrationSupplement'
DESC 'Supplemental registration class'
SUP registration AUXILIARY
MAY ( discloseTo $ isFrozen $ isLeafNode $
registrationClassification $
registrationCreated $
registrationInformation $
registrationModified $
registrationRange $
registrationStatus $
registrationURI ) )
2.5.13. 'firstAuthorityContext'
The 'firstAuthorityContext' AUXILIARY class extends attribute types
intended to store previous authority information.
( 1.3.6.1.4.1.56521.101.2.5.13
NAME 'firstAuthorityContext'
DESC 'Initial registration authority class'
SUP top AUXILIARY
MAY ( firstAuthorityCommonName $
firstAuthorityCountryCode $
firstAuthorityCountryName $
firstAuthorityEmail $
firstAuthorityEndTimestamp $
firstAuthorityFax $
firstAuthorityLocality $
firstAuthorityMobile $
firstAuthorityOrg $
firstAuthorityPOBox $
firstAuthorityPostalAddress $
firstAuthorityPostalCode $
firstAuthorityStartTimestamp $
firstAuthorityState $
firstAuthorityStreet $
firstAuthorityTelephone $
firstAuthorityTitle $
firstAuthorityURI ) )
2.5.14. 'currentAuthorityContext'
The 'currentAuthorityContext' AUXILIARY class extends attribute types
intended to store current authority information.
Coretta Expires February 23, 2025 [Page 51]
Internet-Draft The OID Directory: Schema August 2024
( 1.3.6.1.4.1.56521.101.2.5.14
NAME 'currentAuthorityContext'
DESC 'Current registration authority class'
SUP top AUXILIARY
MAY ( currentAuthorityCommonName $
currentAuthorityCountryCode $
currentAuthorityCountryName $
currentAuthorityEmail $
currentAuthorityFax $
currentAuthorityLocality $
currentAuthorityMobile $
currentAuthorityOrg $
currentAuthorityPOBox $
currentAuthorityPostalAddress $
currentAuthorityPostalCode $
currentAuthorityStartTimestamp $
currentAuthorityState $
currentAuthorityStreet $
currentAuthorityTelephone $
currentAuthorityTitle $
currentAuthorityURI ) )
2.5.15. 'sponsorContext'
The 'currentAuthorityContext' AUXILIARY class extends attribute types
intended to store sponsoring authority information.
( 1.3.6.1.4.1.56521.101.2.5.15
NAME 'sponsorContext'
DESC 'Registration sponsoring authority class'
SUP top AUXILIARY
MAY ( sponsorCommonName $
sponsorCountryCode $
sponsorCountryName $
sponsorEmail $
sponsorEndTimestamp $
sponsorFax $
sponsorLocality $
sponsorMobile $
sponsorOrg $
sponsorPOBox $
sponsorPostalAddress $
sponsorPostalCode $
sponsorStartTimestamp $
sponsorState $
sponsorStreet $
sponsorTelephone $
sponsorTitle $
sponsorURI ) )
Coretta Expires February 23, 2025 [Page 52]
Internet-Draft The OID Directory: Schema August 2024
2.5.16. 'registrant'
The 'registrant' object class allows for current, previous (first)
and/or sponsorship data to be stored within an entry.
This object class is STRUCTURAL, and cannot be combined with the
'registration' object class within a single entry.
Use of the 'registrant' object class within an RA DIT implies use
of so-called dedicated authority entries, as described within the
RADIT I-D.
( 1.3.6.1.4.1.56521.101.2.5.16
NAME 'registrant'
DESC 'Generalized auxiliary class for registrant data'
SUP top STRUCTURAL
MUST registrantID
MAY ( description $
seeAlso $
rATTL ) )
2.5.17. 'rADUAConfig'
The 'rADUAConfig' object class allows for the storage of so-called
auto-discovered attribute types meant to guide the RA DUA in its
attempt to access registration and/or registrant information stored
within the RA DIT served by the RA DSA.
( 1.3.6.1.4.1.56521.101.2.5.17
NAME 'rADUAConfig'
DESC 'RA DUA configuration advertisement class'
SUP top AUXILIARY
MAY ( description $
rADITProfile $
rADirectoryModel $
rARegistrationBase $
rARegistrantBase $
rAServiceMail $
rAServiceURI $
rATTL ) )
2.6. DIT Content Rules
No DIT Content Rules are officially defined anywhere in this I-D
series.
If the X.500/LDAP product(s) in question registers positive support
for these kinds of definitions, per Section 4.1.6 of [RFC4512], and
the reader desires the ability to control the contents of any and all
individual registration and/or registrant entries in a more granular
manner, they are advised to consider the composition and use of one
(1) or more custom rules of this design.
Coretta Expires February 23, 2025 [Page 53]
Internet-Draft The OID Directory: Schema August 2024
2.7. Name Forms
This section defines three (3) Name Forms for use in the composition
of any DIT Structure Rules required, if supported by the X.500/LDAP
product(s) in question. See Section 4.1.7.2 of [RFC4512] for further
details.
2.7.1. 'nRootArcForm'
The 'nRootArcForm' name form is devised to control the RDN of the
entries bearing the 'rootArc' STRUCTURAL object class. Within the
RECOMMENDED three dimensional model of this I-D series, use the 'n'
(Number Form) attribute type is the preferred RDN component.
( 1.3.6.1.4.1.56521.101.2.7.1
NAME 'nRootArcForm'
DESC 'root arc name form for a number form RDN'
OC rootArc
MUST n )
2.7.2. 'nArcForm'
The 'nArcForm' name form is devised to control the RDN of the entries
bearing the 'arc' STRUCTURAL object class. Within the RECOMMENDED
three dimensional model of this I-D series, the 'n' (Number Form)
attribute type is the preferred RDN component.
( 1.3.6.1.4.1.56521.101.2.7.2
NAME 'nArcForm'
DESC 'arc name form for a number form RDN'
OC arc
MUST n )
2.7.3. 'dotNotationArcForm'
The 'dotNotationArcForm' name form is devised to control the RDN
of the bearings bearing the 'arc' STRUCTURAL object class. Within
the STRONGLY DISCOURAGED two dimensional model of this I-D series,
the 'dotNotation' (numeric OID) attribute type is the preferred RDN
component.
( 1.3.6.1.4.1.56521.101.2.7.3
NAME 'dotNotationArcForm'
DESC 'arc name form for a numeric OID RDN'
OC arc
MUST dotNotation )
2.8. DIT Structure Rules
No DIT structure rules are officially defined anywhere in this I-D
series.
Coretta Expires February 23, 2025 [Page 54]
Internet-Draft The OID Directory: Schema August 2024
The name form definitions per Section 2.7 may be used in the creation
of custom DIT structure rules by the directory administrator(s) if
desired. See Section 4.1.7.1 of [RFC4512] for further details.
3. IANA Considerations
There are no requests to IANA in this document at this time.
4. Security Considerations
There are no security considerations applicable to this I-D.
5. References
5.1. Normative References
RADIR Coretta, J., "The OID Directory: A Technical Roadmap",
draft-coretta-oiddir-roadmap, February 2024.
RADIT Coretta, J., "The OID Directory: The RA DIT",
draft-coretta-oiddir-radit, February 2024.
RADSA Coretta, J., "The OID Directory: The RA DSA",
draft-coretta-oiddir-radsa, February 2024.
RADUA Coretta, J., "The OID Directory: The RA DUA",
draft-coretta-oiddir-radua, February 2024.
[RFC2079] Smith, M., "Definition of an X.500 attribute type and an
object class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997.
[RFC2578] Rose, M., et al, "Structure of Management Information
Version 2 (SMIv2)", RFC 2578, April 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
Directory Access Protocol (LDAP)", RFC 3671, December
2003.
[RFC3986] Lee-Berners, T., "Uniform Resource Identifier (URI):
Generic Syntax", RFC 3986, January 2005.
[RFC3987] Duerst, M., "Internationalized Resource Identifiers
(IRIs)", RFC 3987, January 2005.
[RFC9562] K. Davis., et al, "Universally Unique IDentifiers (UUIDs)"
RFC 9562, May 2024.
Coretta Expires February 23, 2025 [Page 55]
Internet-Draft The OID Directory: Schema August 2024
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006.
[RFC4517] Legg, Ed., S., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, June
2006.
[RFC4524] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): COSINE LDAP/X.500 Schema", RFC 4524, June 2006.
[RFC4530] Zeilenga, K,. "Lightweight Directory Access Protocol
(LDAP) entryUUID Operational Attribute", RFC 4530, June
2006.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
[X.660] International Telecommunication Union - Telecommunication
Standardization Sector, "General procedures and top arcs
of the international object identifier tree", ITU-T X.660,
July 2011.
[X.667] International Telecommunication Union - Telecommunication
Standardization Sector, "Information technology -
Procedures for the operation of object identifier
registration authorities: Generation of universally unique
identifiers and their use in object identifiers", ITU-T
X.667, October 2012.
[X.680] International Telecommunication Union - Telecommunication
Standardization Sector, "Abstract Syntax Notation One
(ASN.1): Specification of basic notation", ITU-T X.680,
July 2002.
[X.690] International Telecommunication Union - Telecommunication
Standardization Sector, "ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T X.690, February 2021.
Coretta Expires February 23, 2025 [Page 56]
Internet-Draft The OID Directory: Schema August 2024
5.2. Informative References
[RFC1155] Rose, M., "Structure and Identification of Management
Information for TCP/IP-based Internets", RFC 1155, May
1990.
[X.500] International Telecommunication Union - Telecommunication
Standardization Sector, "The Directory: Overview of
concepts, models and services", ITU-T X.500, October 2019.
Author's Address
Jesse Coretta
California, United States
Email: jesse.coretta@icloud.com
Coretta Expires February 23, 2025 [Page 57]