RASCHEMA                                                      J. Coretta
Internet-Draft                                         February 29, 2024
Intended status: Experimental
Obsoletes: X660LDAP
Expires: August 27, 2024


                   The OID Directory: The Schema
                draft-coretta-oiddir-schema-01.txt

Abstract

   In service to the "OID Directory" ID series, this ID declares schema
   definitions for use within an implementation of the Registration
   Authority Directory Information Tree.

   See the RADIR ID 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 August 27, 2024.

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 August 27, 2024                  [Page 1]

Internet-Draft        The OID Directory: Schema            February 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' ........................................8
         2.3.6. 'additionalUnicodeValue' ..............................9
         2.3.7. 'identifier' ..........................................9
         2.3.8. 'secondaryIdentifier' ................................10
         2.3.9. 'registrationInformation' ............................10
         2.3.10. 'registrationURI' ...................................10
         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 August 27, 2024                  [Page 2]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                  [Page 3]

Internet-Draft        The OID Directory: Schema            February 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.4. Matching Rule Uses ........................................46
      2.5. Object Classes ............................................46
         2.5.1. 'registration' .......................................46
         2.5.2. 'rootArc' ............................................46
         2.5.3. 'arc' ................................................47
         2.5.4. 'x660Context .........................................47
         2.5.5. 'x667Context .........................................47
         2.5.6. 'x680Context .........................................47
         2.5.7. 'iTUTRegistration' ...................................48
         2.5.8. 'iSORegistration' ....................................48
         2.5.9. 'jointISOITUTRegistration' ...........................49
         2.5.10. 'spatialContext' ....................................49
         2.5.11. 'registrationSupplement' ............................50
         2.5.12. 'firstAuthorityContext' .............................50
         2.5.13. 'currentAuthorityContext' ...........................51
         2.5.14. 'sponsorContext' ....................................51
         2.5.15. 'registrant' ........................................52
         2.5.16. 'rADUAConfig' .......................................52
      2.6. DIT Content Rules .........................................52
      2.7. Name Forms ................................................53
         2.7.1. 'nRootArcForm' .......................................53
         2.7.2. 'nArcForm' ...........................................53
         2.7.3. 'dotNotationArcForm' .................................53
      2.8. DIT Structure Rules .......................................53
   3. IANA Considerations ............................................54
   4. Security Considerations ........................................54
   5. References .....................................................54
      5.1. Normative References ......................................54
      5.2. Informative References ....................................55
   Author's Address ..................................................56

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.

   In context, the definitions set forth are based on concepts derived
   from ITU-T Recommendations [X.660], [X.680], [RFC2578] et al.


Coretta                Expires August 27, 2024                  [Page 4]

Internet-Draft        The OID Directory: Schema            February 2024


   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 ID for all acronym references.

1.3.  Allocations

   This specification extends the previously defined ID series OID root
   '1.3.6.1.4.1.56521.101', defined in Section 1.6 of the RADIR ID:

     - 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)

   All OIDs defined in this ID 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 ID be elevated to RFC status, the aforementioned ID root
   OID prefix shall be rendered obsolete in favor of an IANA-assigned
   OID, at which point this ID will be updated to reference the literal
   'IANA-ASSIGNED-OID' placeholder prefix, where appropriate.

1.4.  Well-Known Numeric OIDs

   This ID 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)

     - 1.3.6.1.4.1.1466.115.121.1.12 (DN syntax and matching rule, per
       Section 4.2.15 of [RFC4517])

Coretta                Expires August 27, 2024                  [Page 5]

Internet-Draft        The OID Directory: Schema            February 2024


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

   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.

2.1.  LDAP Syntaxes

   No LDAP syntaxes are defined anywhere in this ID 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 ID 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 ID 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 rule definitions are defined anywhere in this
   ID series.

2.3.  Attribute Types

   The following subsections detail one hundred two (102) LDAP attribute
   types created for use within implementations of this specification.

   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:

Coretta                Expires August 27, 2024                  [Page 6]

Internet-Draft        The OID Directory: Schema            February 2024


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

2.3.1.  'n'

   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' 'numberForm' )
          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"

2.3.3.  'iRI'

   The 'iRI' attribute type allows the assignment of one (1) or more
   OID-IRI values to a registration.

   A practical ABNF production for this attribute type, as derived from
   clause 34.3 of ITU-T Rec. [X.680], is as follows:


Coretta                Expires August 27, 2024                  [Page 7]

Internet-Draft        The OID Directory: Schema            February 2024


     subArcId   = SOLIDUS arcId [ subArcId ]
     arcId      = SOLIDUS ( 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 *( SPACE nanf )

     SPACE        = "%x20"   ; " "
     LCURL        = "%x7b"   ; "{"
     RCURL        = "%x7d"   ; "}"

   The 'nanf' ABNF originates in Section 2.3.19.

      ( 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)}"

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

Coretta                Expires August 27, 2024                  [Page 8]

Internet-Draft        The OID Directory: Schema            February 2024


   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, or nameForm, 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:

      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"            ; "-"


Coretta                Expires August 27, 2024                  [Page 9]

Internet-Draft        The OID Directory: Schema            February 2024


   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' 'nameForm' )
          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.

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

Coretta                Expires August 27, 2024                 [Page 10]

Internet-Draft        The OID Directory: Schema            February 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.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].

      ( 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"




Coretta                Expires August 27, 2024                 [Page 11]

Internet-Draft        The OID Directory: Schema            February 2024


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

      ( 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"


Coretta                Expires August 27, 2024                 [Page 12]

Internet-Draft        The OID Directory: Schema            February 2024


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")

2.3.17.  'isFrozen'

   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.

   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




Coretta                Expires August 27, 2024                 [Page 13]

Internet-Draft        The OID Directory: Schema            February 2024


     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:

     nonf       = ( nanf  / number )        ; nanf OR numberForm
     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)", "56521"

2.3.20.  'longArc'

   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:

     longArc    = SOLIDUS ( intUV / nintUV )
     nintUV     = 1*iunreserved ; non-integer unicode value
     intUV      = number        ; integer unicode value


Coretta                Expires August 27, 2024                 [Page 14]

Internet-Draft        The OID Directory: Schema            February 2024


      ( 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"

2.3.21.  'supArc'

   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"

2.3.22.  'c-supArc'

   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.

      ( 1.3.6.1.4.1.56521.101.2.3.22
          NAME 'c-supArc'
          DESC 'Collective immediate superior registration DN'
          SUP distinguishedName
          COLLECTIVE )


Coretta                Expires August 27, 2024                 [Page 15]

Internet-Draft        The OID Directory: Schema            February 2024


   Example: "n=1,n=2,ou=Registrations,o=rA"

2.3.23.  'topArc'

   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"

2.3.24.  'c-topArc'

   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 )

   Example: "n=2,ou=Registrations,o=rA"






Coretta                Expires August 27, 2024                 [Page 16]

Internet-Draft        The OID Directory: Schema            February 2024


2.3.25.  'subArc'

   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 ID 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"

2.3.26.  'leftArc'

   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"

2.3.27.  'minArc'

   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.

   A practical ABNF production for this attribute type can be found in
   Section 3 of [RFC4514].


Coretta                Expires August 27, 2024                 [Page 17]

Internet-Draft        The OID Directory: Schema            February 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.27
          NAME 'minArc'
          DESC 'First or left-most sibling registration DN'
          SUP distinguishedName
          SINGLE-VALUE )

   Example: "n=0,n=2,ou=Registrations,o=rA"

2.3.28.  'c-minArc'

   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"

2.3.29.  'rightArc'

   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 August 27, 2024                 [Page 18]

Internet-Draft        The OID Directory: Schema            February 2024


      ( 1.3.6.1.4.1.56521.101.2.3.29
          NAME 'rightArc'
          DESC 'Nearest subsequent registration DN'
          SINGLE-VALUE
          SUP distinguishedName )

   Example: "n=2,n=2,ou=Registrations,o=rA"

2.3.30.  'maxArc'

   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"

2.3.31.  'c-maxArc'

   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 August 27, 2024                 [Page 19]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 20]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 21]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 22]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 23]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 24]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 25]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 26]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 27]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 28]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 29]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 30]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 31]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 32]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 33]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 34]

Internet-Draft        The OID Directory: Schema            February 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"

2.3.74.  'sponsor'

   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 August 27, 2024                 [Page 35]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 36]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 37]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 38]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 39]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 40]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 41]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 42]

Internet-Draft        The OID Directory: Schema            February 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 August 27, 2024                 [Page 43]

Internet-Draft        The OID Directory: Schema            February 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.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 August 27, 2024                 [Page 44]

Internet-Draft        The OID Directory: Schema            February 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"

2.3.100.  'rATTL'

   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 ID 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"

2.3.101.  'c-rATTL'

   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 ID 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 August 27, 2024                 [Page 45]

Internet-Draft        The OID Directory: Schema            February 2024


2.3.102.  'registeredUUID'

   The 'registeredUUID' attribute type assigns a hexadecimal UUID value
   to a registration.

   A practical ABNF production for this attribute type is defined within
   Section 3 of [RFC4122].

      ( 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.4.  Matching Rule Uses

   No LDAP Matching Rule Uses definitions are defined anywhere in this
   ID series.

2.5.  Object Classes

   The following subsections describe sixteen (16) LDAP object classes
   defined within this ID.

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 within the spirit of this ID.

      ( 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)})

Coretta                Expires August 27, 2024                 [Page 46]

Internet-Draft        The OID Directory: Schema            February 2024


      ( 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 )

2.5.3.  'arc'

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

      ( 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].





Coretta                Expires August 27, 2024                 [Page 47]

Internet-Draft        The OID Directory: Schema            February 2024


      ( 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.  '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.8) or 'jointISOITUTRegistration' (per Section 2.5.9)
   class.

   The 'x660Context' (Section 2.5.4) and 'x680Context' (Section 2.5.6)
   are super classes of this class.

      ( 1.3.6.1.4.1.56521.101.2.5.7
          NAME 'iTUTRegistration'
          DESC 'X.660, cl. A.2: ITU-T'
          SUP ( x660Context $
                x680Context )
          AUXILIARY )

2.5.8.  '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.7) or 'jointISOITUTRegistration' (per Section 2.5.9)
   class.

   The 'x660Context' (Section 2.5.4) and 'x680Context' (Section 2.5.6)
   are super classes of this class.







Coretta                Expires August 27, 2024                 [Page 48]

Internet-Draft        The OID Directory: Schema            February 2024


      ( 1.3.6.1.4.1.56521.101.2.5.8
          NAME 'iSORegistration'
          DESC 'X.660, cl. A.2: ISO'
          SUP ( x660Context $
                x680Context )
          AUXILIARY )

2.5.9.  '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.

   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.7) or 'iSORegistration' (per Section 2.5.8) class.

   This class extends use of the 'longArc' attribute type, as defined in
   Section 2.3.20.

   The 'x660Context' (Section 2.5.4) and 'x680Context' (Section 2.5.6)
   are super classes of this class.

      ( 1.3.6.1.4.1.56521.101.2.5.9
          NAME 'jointISOITUTRegistration'
          DESC 'X.660, cl. A.2: Joint ISO/ITU-T Administration'
          SUP ( x660Context $
                x680Context )
          AUXILIARY
          MAY longArc )

2.5.10.  '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 ID for further details on this topic.









Coretta                Expires August 27, 2024                 [Page 49]

Internet-Draft        The OID Directory: Schema            February 2024


      ( 1.3.6.1.4.1.56521.101.2.5.10
          NAME 'spatialContext'
          DESC 'Logical spatial orientation and association class'
          SUP registration AUXILIARY
          MAY ( topArc $ supArc $ subArc $
                minArc $ maxArc $
                leftArc $ rightArc ) )

2.5.11.  'registrationSupplement'

   The 'registrationSupplement' AUXILIARY class extends a variety of
   miscellaneous and non-standard attribute types for OPTIONAL.

      ( 1.3.6.1.4.1.56521.101.2.5.11
          NAME 'registrationSupplement'
          DESC 'Supplemental registration class'
          SUP registration AUXILIARY
          MAY ( discloseTo $ isFrozen $ isLeafNode $
                registrationClassification $
                registrationCreated $
                registrationInformation $
                registrationModified $
                registrationRange $
                registrationStatus $
                registrationURI ) )

2.5.12.  'firstAuthorityContext'

   The 'firstAuthorityContext' AUXILIARY class extends attribute types
   intended to store previous authority information.

      ( 1.3.6.1.4.1.56521.101.2.5.12
          NAME 'firstAuthorityContext'
          DESC 'Initial registration authority class'
          SUP top AUXILIARY
          MAY ( firstAuthorityCommonName $
                firstAuthorityCountryCode $
                firstAuthorityCountryName $
                firstAuthorityCountryName $
                firstAuthorityEmail $
                firstAuthorityEndTimestamp $
                firstAuthorityFax $
                firstAuthorityLocality $
                firstAuthorityMobile $
                firstAuthorityOrg $
                firstAuthorityPostalCode $
                firstAuthorityStartTimestamp $
                firstAuthorityState $
                firstAuthorityStreet $
                firstAuthorityTelephone $
                firstAuthorityTitle $
                firstAuthorityURI ) )

Coretta                Expires August 27, 2024                 [Page 50]

Internet-Draft        The OID Directory: Schema            February 2024


2.5.13.  'currentAuthorityContext'

   The 'currentAuthorityContext' AUXILIARY class extends attribute types
   intended to store current authority information.

      ( 1.3.6.1.4.1.56521.101.2.5.13
          NAME 'currentAuthorityContext'
          DESC 'Current registration authority class'
          SUP top AUXILIARY
          MAY ( currentAuthorityCommonName $
                currentAuthorityCountryCode $
                currentAuthorityCountryName $
                currentAuthorityCountryName $
                currentAuthorityEmail $
                currentAuthorityFax $
                currentAuthorityLocality $
                currentAuthorityMobile $
                currentAuthorityOrg $
                currentAuthorityPostalCode $
                currentAuthorityStartTimestamp $
                currentAuthorityState $
                currentAuthorityStreet $
                currentAuthorityTelephone $
                currentAuthorityTitle $
                currentAuthorityURI ) )

2.5.14.  'sponsorContext'

   The 'currentAuthorityContext' AUXILIARY class extends attribute types
   intended to store sponsoring authority information.

      ( 1.3.6.1.4.1.56521.101.2.5.14
          NAME 'sponsorContext'
          DESC 'Registration sponsoring authority class'
          SUP top AUXILIARY
          MAY ( sponsorCommonName $
                sponsorCountryCode $
                sponsorCountryName $
                sponsorCountryName $
                sponsorEmail $
                sponsorEndTimestamp $
                sponsorFax $
                sponsorLocality $
                sponsorMobile $
                sponsorOrg $
                sponsorPostalCode $
                sponsorStartTimestamp $
                sponsorState $
                sponsorStreet $
                sponsorTelephone $
                sponsorTitle $
                sponsorURI ) )

Coretta                Expires August 27, 2024                 [Page 51]

Internet-Draft        The OID Directory: Schema            February 2024


2.5.15.  '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 ID.

      ( 1.3.6.1.4.1.56521.101.2.5.15
          NAME 'registrant'
          DESC 'Generalized auxiliary class for registrant data'
          SUP top STRUCTURAL
          MUST registrantID
          MAY ( description $ seeAlso $ rATTL ) )

2.5.16.  '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.16
          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 ID
   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 August 27, 2024                 [Page 52]

Internet-Draft        The OID Directory: Schema            February 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
   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 ID 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 ID 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 ID 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 ID
   series.


Coretta                Expires August 27, 2024                 [Page 53]

Internet-Draft        The OID Directory: Schema            February 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 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 ID.

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.

   [RFC4122]  Leach, P., "A Universally Unique IDentifier (UUID) URN
              Namespace", RFC 4122, July 2005.



Coretta                Expires August 27, 2024                 [Page 54]

Internet-Draft        The OID Directory: Schema            February 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.

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.

Coretta                Expires August 27, 2024                 [Page 55]

Internet-Draft        The OID Directory: Schema            February 2024


   [X.672]    International Telecommunication Union - Telecommunication
              Standardization Sector, "OID resolution system: Problems,
              requirements and potential solutions", ITU-T X.672, March
              2020.

Author's Address

   Jesse Coretta
   California, United States

   Email: jesse.coretta@icloud.com








































Coretta                Expires August 27, 2024                 [Page 56]