Internet DRAFT - draft-coretta-oiddir-radua

draft-coretta-oiddir-radua





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


                   The OID Directory: The RA DUA
                 draft-coretta-oiddir-radua-00.txt

Abstract

   In service to the "OID Directory" ID series, this ID covers design
   strategies, requirements and procedures for the client component of
   the OID Directory Registration Authority client/server model.

   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: RA Client           February 2024


Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions ................................................2
      1.2. Acronyms Used ..............................................2
         1.2.1. Definitions ...........................................3
      1.3. Intended Audience ..........................................3
      1.5. Parameter Abstraction ......................................3
   2. The RA DUA ......................................................3
      2.1. Defined Parameters .........................................4
      2.2. Procedures .................................................5
         2.2.1. Schema Availability ...................................5
         2.2.2. Configuration .........................................5
         2.2.3. Queries ..............................................10
         2.2.4. New Allocations ......................................17
         2.2.5. Allocation Updates ...................................22
   3. IANA Considerations ............................................23
   4. Security Considerations ........................................23
   5. References .....................................................23
      5.1. Normative References ......................................23
      5.2. Informative References ....................................24
   Author's Address ..................................................25

1.  Introduction

   The X.500 Directory User Agent represents the client component within
   the traditional client/server model that interacts with any number of
   X.500 Directory System Agents for the purposes of information access.

   Within the terms of this ID series, the Directory User Agent serves
   as a client of OID registration and registrant content, as retrieved
   from a Registration Authority Directory Information Tree.

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.  Also,
   see Sections 1.7 and 1.8 of the RADIR ID for generalized terms and
   descriptions of significance to this ID series.







Coretta                Expires August 27, 2024                  [Page 2]

Internet-Draft      The OID Directory: RA Client           February 2024


1.2.1.  Definitions

   The composite acronym "RA DUA" is hereby introduced within this ID.
   The acronym abbreviates the aforementioned 'Registration Authority
   Directory User Agent' term, which describes the 'client' component
   implied within the client/server model relevant to this ID series.

   The composite acronym "RA DSA" used throughout this ID is defined in
   Section 1.2.1 of the RADSA ID.

   The composite acronym "RA DIT" used throughout this ID is defined in
   Section 1.2.1 of the RADIT ID.

1.3.  Intended Audience

   This ID is intended for application designers, X.500/LDAP architects,
   and other personnel tasked with supporting or designing components
   related to the RA client/server model in service to this ID series.

   General familiarity with the broad X.500/LDAP specification, as well
   all supporting IDs cited in Section 2 of the RADIR ID is STRONGLY
   RECOMMENDED.

1.4.  Parameter Abstraction

   For simplicity in describing certain request or argument parameters
   involving either DAP or LDAP operations in this ID, a simplified
   abstraction of ASN.1 parameters is shown to aid RA DUA adopter.

   For example, the following structure may be used to outline the
   parameters of a Read or Search Operation to be conducted as part
   of an RA DUA managed procedure.

      baseObject = dn          ; DN: see RFC4514 and X.501
      scope      = 0/1/2       ; eq. X.511 'subset'
      typesOnly  = bool or int ; see. X.511 'EntryInformationSelection'
                               ; and RFC4512 'SearchRequest'
      filter     = filter      ; see X.511 and RFC4515
      attributes = selection(s); see. X.511 'EntryInformationSelection'
                               ; and RFC4512 'AttributeSelector'

   While the abstraction has favored the use of LDAP-focused parameters
   derived from [RFC4511], adopters MAY assume similar directives
   are applicable within the context of DAP unless otherwise indicated.

2.  The RA DUA

   The RA DUA is a traditional X.500/LDAP client -- supporting most or
   all of the standard operations defined throughout clauses 9 through
   12 of ITU-T Rec. X.511, and throughout Section 4 of [RFC4511] --
   that has been OPTIMIZED for use within the terms of this ID series.


Coretta                Expires August 27, 2024                  [Page 3]

Internet-Draft      The OID Directory: RA Client           February 2024


2.1.  Defined Parameters

   The RA DUA is expected to support the directory protocols facilitated
   by the endpoint RA DSA(s), whether DAP, LDAP or both.  Support for
   connectivity via the OSI networking stack, TCP/IP or IPC socket by
   the RA DUA is determined by the operational requirements of the RA
   DSA(s) in question.

   Support for parallel X.500 protocols -- such as DOP or DSP -- is not
   specifically indicated.

   No recommendations are made regarding the "appearance" or interactive
   nature of the RA DUA (i.e.: TUI vs. GUI), nor are any recommendations
   made regarding the specific language or framework used in its design.

   No particular software license applied to the RA DUA is assumed.

   The intended application may be for any end user in general, or it
   may be administratively focused.  The RA DUA may be obtained by the
   general public, or it may be wholly proprietary and for internal use
   only.

   The capabilities of the RA DUA MAY be flexible to suit the end user,
   or it may be strictly regimented, allowing few variations of behavior
   in routine operations.

   In situations where an RA DUA is designed solely for the query and
   presentation of entries with no possibility of support for entry
   modifications, adopters MAY forego implementation of operational
   capabilities that are Write-focused in nature.

   Application designers SHOULD make use of ONLY industry-recognized
   X.500/LDAP APIs, SDKs or libraries in a manner compliant with all
   "Best Practices" suggested by both the maintainer(s) and the authors
   of the standards indicated.

   The RA DUA is not necessarily user-managed.  An RA DUA may manifest
   in "clientless" form -- for example, facilitated through a web-based
   application interface residing on the RA DSA(s) directly, thus acting
   in the context of an abstract protocol gateway.  These strategies may
   prove useful in reducing both the effort required by the end-user in
   order to access the service, as well as the costs of supporting the
   end user.

   Regardless of the design and deployment philosophies employed, the
   primary focus of the RA DUA -- with particular emphasis on any and
   all proposed optimizations -- is to reduce the tedium of access and
   administration of potentially large registration and authority bases,
   and to introduce protective controls meant to ensure integrity of all
   relevant content within the RA DIT.



Coretta                Expires August 27, 2024                  [Page 4]

Internet-Draft      The OID Directory: RA Client           February 2024


2.2.  Procedures

   The RA DUA SHALL observe the procedures defined in the following
   subsections as it pertains to the query, allocation and maintenance
   of 'registration' and 'registrant' entries within an RA DSA.

2.2.1.  Schema Availability

   The RA DUA MUST obtain -- or possess complete foreknowledge of -- all
   schema definitions officially defined in Section 2 of the RASCHEMA
   ID as well as the schema definitions serving as super types for many
   of the attribute types defined in Section 2.3 of the RASCHEMA ID.

   In addition, the RA DUA MUST both recognize and honor any additional
   DIT content rules, DIT structure rules and/or (additional) name forms
   created by the directory architects or administrators after-the-fact.

   Obtaining the necessary schema definitions is typically conducted in
   either of the following manners, shown in order of preference.

      - Through a direct Read of the 'subschemaSubentry' of the RA DSA
      - Through manual processing of the (approved) schema file(s) based
        upon the complete contents of the RASCHEMA ID

   When obtaining the schema through use of a Read or Search Operation,
   the schema SHOULD be refreshed at the commencement of a new RA DUA
   session.  This accounts for changes to the schema definitions that
   may have taken place during runtime.

   If the RA DSA has no apparent knowledge of the definitions to be used
   for the query and/or allocation of registrations and/or registrants
   within the RA DIT, the RA DUA MUST abandon attempts to interact with
   the RA DSA.  It is RECOMMENDED that, in this case, the RA DUA present
   the user with error information describing the problem.  This could
   suggest an RA DSA configuration problem, or possibly that the wrong
   RA DSA has been targeted by the RA DUA.

2.2.2.  Configuration

   There are two (2) modes of RA DUA configuration: automatic or manual.

   Section 2.3 of the RASCHEMA ID introduces a small handful of types
   intended for "advertisement" by the RA DSA and for consumption by the
   RA DUA.  These attributes are as follows:

     - 'rARegistrationBase' ; ex.: ou=Registrations,o=rA
     - 'rARegistrantBase'   ; ex.: ou=Registrants,o=rA
     - 'rADirectoryModel'   ; ex.: 1.3.6.1.4.1.56521.101.3.1.3
     - 'rAServiceMail'      ; ex.: support@ra.example.com
     - 'rAServiceURI'       ; ex.: https://ra.example.com
     - 'rADITProfile'       ; ex.: dc=example,dc=com
     - 'rATTL'              ; ex.: 86400

Coretta                Expires August 27, 2024                  [Page 5]

Internet-Draft      The OID Directory: RA Client           February 2024


   These attribute types are extended through use of the 'rADUAConfig'
   AUXILIARY object class.  See Section 2.3.6 of the RADSA ID for
   usable examples involving this class.

   Auto-discovery of these attribute types will require disclosure
   privileges for the root DSE and any other entries that bear the
   'rADUAConfig' object class.

   Though the particulars of the root DSE are well outside the scope of
   this ID series, it is typically accessed by way of the Read Operation
   executed upon a NULL baseObject.

   Retrieval SHOULD be made conditional using the 'rADUAConfig' object
   class as the filter AVA, and SHOULD involve attribute selection of
   the types shown below.

      filter     = objectClass=rADUAConfig   ; Require 'rADUAConfig'
      attributes = rARegistrationBase
                   rARegistrantBase
                   rADirectoryModel
                   rAServiceMail
                   rAServiceURI
                   rADITProfile
                   rATTL

   If zero (0) entries are returned as a result of the Read Operation,
   this indicates any of the following:

      - The RA DSA is not available
      - The root DSE is not accessible, possibly due to access rights
      - The root DSE is accessible, but lacks the 'rADUAConfig' class

   Given any of these conditions, automatic parameter input has failed.
   The RA DUA has no alternative other than manual parameter input.

   If one (1) entry is returned, the root DSE is accessible and has been
   configured for automatic input.  The RA DUA SHOULD choose to proceed
   with configuration using the values provided.

   See Section 2.3.6 of the RADSA ID regarding the possible methods
   for implementation of this entry with respect to multiple RA DITs
   served by an RA DSA as opposed to a single RA DIT.

   If manual input of configuration values is required, typically this
   would require foreknowledge of the correct values, or access to an
   informational resource which makes those values available.

   In this scenario, the RA DUA MUST request the user follow a procedure
   for manual input prior to use.  Lack of proper configuration values
   precludes any RA DUA session.



Coretta                Expires August 27, 2024                  [Page 6]

Internet-Draft      The OID Directory: RA Client           February 2024


2.2.2.1.  Processing

   Following value input -- whether automatic or manual -- the acquired
   values MUST be processed and validated.

   The following subsections cover each 'rADUAConfig'-extended attribute
   type in the context of runtime configuration of the RA DUA.

2.2.2.1.1.  'rADITProfile'

   The 'rADITProfile' attribute type stores any number of DN values,
   each acting as a reference to a DIT-housed 'rADUAConfig' entry
   which contains the standard configuration parameters required by
   the RA DUA.

   The 'rADITProfile' attribute type is a CRITICAL component within any
   implementation in which the following conditions apply:

      - Multiple RA DITs reside on a single RA DSA, with each RA DIT
        accessed using potentially different configuration values
      - Single RA DITs which bear usable configuration settings within
        DIT entry contexts -- as opposed to storage within the root DSE

   In either case, the root DSE SHALL NOT contain any of the attribute
   types extended by the MAY clauses of the 'rADUAConfig' AUXILIARY
   object class OTHER THAN the 'rADITProfile', 'rATTL', 'rAServiceMail',
   and 'rAServiceURI' attribute types.

   Similarly, referenced 'rADUAConfig' entries within an RA DIT SHALL
   NOT bear instances of the 'rADITProfile' attribute type.

   Instances where these attribute types are improperly combined within
   entries is considered a "Duplicate RA Context Error" and represents
   a serious operational deficiency that MUST be reported to the end
   user.  The RA DUA SHOULD fail the session or (optionally) allow for
   administrative override if corrective measures are to be taken.

2.2.2.1.2.  'rARegistrationBase'

   The 'rARegistrationBase' attribute type is the most CRITICAL of all
   attribute types related to RA DUA configuration.

   The purpose of this multi-valued type is to store the DN(s) in which
   'registration' entries are stored.  This parameter is REQUIRED, as it
   prevents the need for inefficient broad-level Search Operations,
   potentially within a particularly large directory information tree.

   The RA DUA MUST handle the instance value(s) as follows:





Coretta                Expires August 27, 2024                  [Page 7]

Internet-Draft      The OID Directory: RA Client           February 2024


      1.  Verify presence and accessibility of entries identified by the
          respective DN values using the Read Operation
      2.  Determine whether the given entries bear the 'registration'
          ABSTRACT object class
      2a. If the named entries DO NOT bear the 'registration' class, the
          RA DUA must interpret the entries as simple organizational
          containers housing 'registration' entries one (1) level below
      2b. If the named entries bear the 'registration' class, this is
          indicative of an official starting-point for registration
          content within the "OID Directory"
      3.  Preserve these DNs for the remainder of the session, as they
          will influence the various operations that may take place

   In the case of condition "2a", a read-only RA DUA MAY opt to fail the
   session if no 'registration' entries reside exactly one (1) level
   beneath the apparent "organizational container" entry.  The RA DUA
   MAY allow for administrative override of this behavior, thereby
   allowing retroactive registration creation within an implementation
   not yet populated.

2.2.2.1.3.  'rARegistrantBase'

   The 'rARegistrantBase' attribute type is OPTIONAL in terms of RA DUA
   configuration.  It identifies one (1) or more DNs which lead to the
   location of authority-related entries within the RA DIT.

   The RA DUA MUST handle the value(s) associated with this type as
   follows:

      1.  Verify presence and accessibility of entries identified by the
          respective DN values using the Read Operation
      2.  Compare the DN values to those within the 'rARegistrationBase'
          attribute type instance
      2a. If the DN values are identical, this implies use of combined
          authority/registration entries in a single location within the
          RA DIT -- a procedure that is generally discouraged
      2b. If the DN values are different, this implies use of dedicated
          authority entries, which bear the 'registrant' STRUCTURAL
          object class and reside in a location separate from that which
          houses entries bearing the 'registration' STRUCTURAL Object
          Class
      2c. If no DN values are specified within the 'rARegistrantBase'
          attribute type instance, the RA DUA MAY interpret this as an
          indication that no authority information is available within
          the RA DIT, and associated authority attribute types SHOULD
          NOT be requested by the RA DUA

   In the case of "2a", the RA DUA SHOULD include all attribute types
   specified within the 'currentAuthorityContext', 'sponsorContext' and
   'firstAuthorityContext' 'MAY' clauses for subsequent Read Operations
   of 'registration' entries.


Coretta                Expires August 27, 2024                  [Page 8]

Internet-Draft      The OID Directory: RA Client           February 2024


   In the case of "2b", the RA DUA SHOULD include all attribute types
   specified within 'currentAuthorityContext', 'sponsorContext' and
   'firstAuthorityContext' 'MAY' clauses for subsequent Read Operations
   of 'registrant' entries.

   Dedicated authority entries bearing the 'registrant' STRUCTURAL
   object class should be located exactly one (1) level below each
   specified 'rARegistrantBase' DN value within the RA DIT.

   Depending on the nature of implementation of this ID series, it may
   or may not be advisable to populate the 'rARegistrantBase' Attribute
   Type for consumption by all clients indiscriminately.  See Section
   5.2 of the RADIT ID for security considerations on this topic.

2.2.2.1.4.  'rADirectoryModel'

   The 'rADirectoryModel' type describes the abstract structure of the
   RA DIT in terms of 'registration' layout and probable DN syntax.  The
   employed model shall have a profound influence on the manner in which
   the RA DUA shall interact with the RA DIT.

   A specified directory model is REQUIRED for proper functioning of the
   RA DUA, whether directly or indirectly.  The decided model specifier,
   which MUST be a numeric OID, is declared using the 'rADirectoryModel'
   attribute type.

   Sections 3.1.2 and 3.1.3 of the RADIT ID define two (2) official
   directory models and DN syntax schemes identified by the following
   numeric OIDs:

      - 'twoDimensional' (1.3.6.1.4.1.56521.101.3.1.2)
      - 'threeDimensional' (1.3.6.1.4.1.56521.101.3.1.3)

   In virtually every case, the 'threeDimensional' model is STRONGLY
   RECOMMENDED for implementation and use, however RA DUAs SHOULD be
   prepared to incorporate other models that could be defined in any
   future extensions to this ID series.

   The RA DUA MUST support use of the 'threeDimensional' model without
   exception and to the letter of every recommendation set forth within
   this ID series.

   As stated clearly and in no uncertain terms within the originating
   document, the 'twoDimensional' model is STRONGLY DISCOURAGED aside
   from use in non-standard or particularly unusual scenarios.

   The RA DUA MAY support use of the 'twoDimensional' model at the
   discretion of the application designer.  Support for this model
   is purely OPTIONAL.




Coretta                Expires August 27, 2024                  [Page 9]

Internet-Draft      The OID Directory: RA Client           February 2024


   The RA DUA MUST handle the value of this instance as follows:

      1.  Determine whether the 'rADirectoryModel' attribute type has
          been set with an explicit numeric OID
      1a. If NO numeric OID has been specified, use of the RECOMMENDED
          'threeDimensional' model is to be enforced by DEFAULT
      1b. If a numeric OID has been specified, identify the value as a
          known and supported model OID and adjust RA DUA behavior in
          accordance with prescribed procedures of the RADIT ID
      1c. If a numeric OID has been specified and is not immediately
          identifiable within the terms of this ID series -- such as
          a future extension of this standard -- the RA DUA MAY defer
          to the specifics of the recommendation or ID from which the
          OID originates OR the RA DUA MAY choose to fail the session
      2.  Preserve the value for the remainder of the session, as it
          will influence the specifics of operations that may occur

   In the case of condition "1c", if the RA DUA chooses to fail the
   session, the RA DUA SHOULD present the user with an error message
   indicating the encounter with an unknown or as-of-yet unsupported
   directory model identifier.

2.2.2.1.5.  Additional Parameters

   The 'rAServiceMail' attribute type, when defined, contains any number
   of email addresses meant for support or request purposes.  Use of
   this type in the RA DIT is OPTIONAL, but SHOULD be recognized by the
   RA DUA when present.

   The 'rAServiceURI' attribute type, when defined, contains any number
   of URI values related to the service, such as terms of use, support
   information, documentation and other resources.  Use of this type in
   the RA DIT is OPTIONAL, but SHOULD be recognized by the RA DUA when
   present.

   The 'rATTL' attribute type, when defined for an entry bearing the
   'rADUAConfig' class, imposes a global entry caching TTL value meant
   for consumption and observance by qualified RA DUA implementations.
   See Section 2.2.3.4 for details and semantics regarding assignment
   and precedence strategies for a TTL.

2.2.3.  Queries

   This subsection covers strictly read-related operations, such as the
   location and presentation of a given 'registration' entry.

2.2.3.1.  Retrieving Entries

   The RECOMMENDED procedure for retrieving an entry -- in any directory
   model defined in this ID series -- is a Read Operation of the entry
   by way of its DN.  This will return either one (1) entry, or none.


Coretta                Expires August 27, 2024                 [Page 10]

Internet-Draft      The OID Directory: RA Client           February 2024


   Foreknowledge of the DN is required for a Read Operation attempt of
   this fashion.

   If the entry is a 'registration', the DN may be resolved by way of
   the associated numeric OID using the appropriate process defined in
   Section 3.1.

   'registration' entries may reference other 'registration' entries
   using the spatial attribute types defined in Section 2.3 of the
   RASCHEMA ID and discussed further in Section 2.2.3.3.

   'registrant' entries, however, aren't resolvable in any standard
   manner.  These are dedicated authority entries that are normally
   accessed through references held by any associated 'registration'
   entries.

      - 'firstAuthority' and/or 'c-firstAuthority'
      - 'currentAuthority' and/or 'c-currentAuthority'
      - 'sponsor' and/or 'c-sponsor'

   However, in cases where direct referencing of DNs within the context
   of a Read Operation is not practical, possibly due to any of the
   following ...

      - Lack of assigned spatial reference types
      - An unsupported or incoherent DN syntax is indicated
      - Administrative operations are underway

   Use of a List Operation or subtree Search Operation may be indicated.

   While this method of searching is not generally recommended within
   the spirit of this ID series, the RA DUA MAY allow this capability
   where appropriate.

   If the RA DUA encounters difficulty relating to a particularly large
   number of entries retrieved through a Search Operation, support for
   Simple Paged Results Manipulation by the RA DUA may be indicated if
   supported by the RA DSA.  For details, see clause 7.9 of ITU-T Rec.
   X.511 and the entirety of [RFC2696].

2.2.3.2.  Reading Entries

   The following subsections outline the procedures involved in the
   presentation and analysis of a 'registration' or 'registrant' entry
   successfully retrieved by way of the Read or Search Operation.

2.2.3.2.1.  Entry 'objectClass' Analysis

   Given a successfully conducted Read or Search Operation, and assuming
   a single entry -- whether 'registration' or 'registrant' -- has been
   returned, the RA DUA SHOULD first read the 'objectClass' values and
   make note of all that originate in Section 2.5 of the RASCHEMA ID.

Coretta                Expires August 27, 2024                 [Page 11]

Internet-Draft      The OID Directory: RA Client           February 2024


   The 'registration' ABSTRACT object class is a required class for any
   OID allocation.  This class MUST only appear on entries which bear
   the 'rootArc' or 'arc' STRUCTURAL class.  It is a sub type of the
   'top' ABSTRACT class, defined in Section 2.4.1 of [RFC4512] and in
   clause 13.3.3 of ITU-T Rec. X.501.

   The 'registrant' STRUCTURAL object class is only used for dedicated
   registrants, which are associated through DN references held by
   associated 'registration' entries, if any.  Appearance upon any
   other form of entry is a suboptimal or illogical state.

   Presence of the 'x660Context' and/or 'x680Context' AUXILIARY classes
   for a 'registration' entry is permitted.  These object classes extend
   multiple attribute types which conceptually relate to ITU-T Rec.
   X.660 and X.680 respectively.

   Presence of the 'x667Context' AUXILIARY class for a 'registration'
   entry is only expected in cases where an OID allocation involves a
   'registeredUUID' attribute type instance and where the assigned 'n'
   value is the equivalent unsigned 128-bit integer.

   Presence of the 'iTUTRegistration' AUXILIARY class is only permitted
   for allocations bearing the 'arc' STRUCTURAL class and describe an
   OID beginning with zero (0).  It extends no attribute types.

   Presence of the 'iSORegistration' AUXILIARY class is only permitted
   for allocations bearing the 'arc' STRUCTURAL class and describe an
   OID beginning with one (1)  It extends no attribute types.

   Presence of the 'jointISOITUTRegistration' AUXILIARY class is only
   permitted for allocations bearing the 'arc' STRUCTURAL class and
   describe an OID beginning with two (2).  It extends the 'longArc'
   attribute type.

   Entries SHALL NOT bear more than one (1) of the 'iTUTRegistration',
   'iSORegistration' or 'jointISOITUTRegistration' classes.

   Presence of the 'spatialContext' AUXILIARY class is only permitted
   for 'registration' entries.  It extends seven (7) spatial reference
   attribute types used to describe arrangement of allocations within
   the spectrum.  Additional collective incarnations of some of these
   attribute types may be indicated.

   Presence of the 'registrationSupplement' AUXILIARY class is only
   permitted for 'registration' entries.  It extends miscellaneous
   attribute types which extend from no official standards meant for
   ease-of-use only.

   Collective Attributes are described in [RFC3671].




Coretta                Expires August 27, 2024                 [Page 12]

Internet-Draft      The OID Directory: RA Client           February 2024


   Presence of the 'firstAuthorityContext', 'currentAuthorityContext',
   and 'sponsorContext' AUXILIARY classes is permitted for 'registrant'
   entries and 'registration' entries alike, and would depend upon the
   'registrant' model employed within the RA DIT.  Each of these classes
   extends several identity and contact related attribute types for use
   within the context of sponsorship, current authorities and previous
   authorities.

   Presence of the 'rADUAConfig' AUXILIARY class SHOULD NOT be permitted
   for 'registration' or 'registrant' entries and indicates a suboptimal
   or illogical state.

   Assuming no violations were perceived as outlined above, the state of
   the entry's object class stack is apparently copacetic.

2.2.3.2.2.  Attribute Types Used

   At a minimum, the RA DUA SHOULD only expect Attribute Types defined
   within Section 2.3 of the RASCHEMA ID, and/or their respective
   super types defined in [RFC4519], [RFC4524] and [RFC2079], to be
   assigned to entries within the terms of this ID series.

   See Section 3.2 of the RADIT ID for numerous examples regarding
   various attribute type use cases and requirements.

   The RA DIT MAY use other attribute type and object class definitions
   unrelated to this ID series, for supplemental reasons, however their
   incorporation would be wholly proprietary and would have no official
   standing per this ID series.

2.2.3.2.3.  Value Syntax

   Each attribute type, whether directly or indirectly, is governed via
   a syntax definition in terms of the allowed value(s) to be set for
   an entry.

   As mentioned in Section 2.1 of the RASCHEMA ID, standard syntaxes
   do not necessarily align perfectly with the syntactical requirements
   of the standards upon which this ID series is based -- namely ITU-T
   Recommendations X.660 and X.680.

   To ease the difficulty in implementing an RA DUA which honors the
   syntactical characteristics of the underlying subject matter -- as
   opposed to only recognizing the syntax alone -- Section 2.3 of the
   RASCHEMA ID includes ABNF productions for every attribute type
   defined, whether by reference or in literal form, intended for use by
   those tasked with implementation of this ID series in some manner.

   The RA DUA MUST recognize these ABNF productions when reading values
   that were retrieved through use of the Read or Search Operation.



Coretta                Expires August 27, 2024                 [Page 13]

Internet-Draft      The OID Directory: RA Client           February 2024


   The RA DUA MAY decide how to handle the case of reading a previously
   set attribute value of invalid or non-compliant form.  The RA DUA may
   warn the end-user of a value that is not well-formed, or it may opt
   to omit the value from visibility altogether.  If the RA DUA is of an
   administrative focus, the opportunity for corrective measures MAY be
   facilitated.

2.2.3.3.  Navigating Registration Entries

   Some of the more complete RA services, whether public or private,
   may offer a simple interface to facilitate intuitive incremental
   movement among registrations that are associated horizontally or
   vertically in terms of "up", "down", "left", "right", "min", "max"
   and "top".

   Depending on the needs of the intended audience, as well as the
   manner in which this specification is adopted, this can be an
   exceptionally difficult feature to implement for the RA DUA, but
   is one that can dramatically improve the user experience.

   The RA DUA SHOULD NOT assume positive support for this practice in
   all implementations of this ID series.

2.2.3.3.1. Superior Vertical References

   During the Read or Search Operation executed in order to obtain a
   'registration' entry, the RA DUA MAY request any of the following
   attribute types:

      - 'supArc'
      - 'c-supArc'
      - 'topArc'
      - 'c-topArc'

   The 'supArc' and 'c-supArc' attribute types describe the immediate
   superior (parent) registration in terms of ancestral lineage.  Only
   one (1) of each of these attribute types should be present for any
   given 'registration' entry, never both.

   The 'topArc' and 'c-topArc' attribute types describe the absolute
   root registration in terms of ancestral lineage.  Only one (1) of
   each of these attribute types should be present for any given
   'registration' entry, never both.

   Use of Collective attribute types -- namely those prefaced using the
   requisite 'c-' flag -- is not practical in the two dimensional model
   and thus need not be requested.

   At no point are the above attribute types to be requested for entries
   that bear the 'rootArc' STRUCTURAL object class.  Root registrations
   do not have superiors.


Coretta                Expires August 27, 2024                 [Page 14]

Internet-Draft      The OID Directory: RA Client           February 2024


2.2.3.3.2. Subordinate Vertical References

   Subordinate vertical references tend to be the most challenging among
   all the various attribute types related to spatial navigation within
   the terms of this ID series.

   The RA DUA MAY request the 'subArc' attribute type as part of the
   Read or Search Operation used for retrieval of a 'registration'
   entry from the RA DIT.

   At no point should an entry bear the 'subArc' attribute type if it
   bears an 'isLeafNode' instance with a value of TRUE.  This indicates
   an illogical RA DIT condition.

   When defined, the 'subArc' attribute type instance SHOULD reflect
   a complete manifest of all references for 'registration' entries
   that are direct subordinates of the bearer.  This instance SHOULD
   be requested in baseObject-scoped context, and is the only multi
   valued spatial attribute type defined within this ID series.

   The RA DUA SHOULD prefer 'subArc' enumeration to a List Operation
   beneath a 'registration'.  This method of searching is a potentially
   costly request in the face of particularly large sets of subordinate
   'registration' entries present within the RA DIT.

   The RA DUA SHOULD be prepared to manually sort the set of 'subArc'
   DN references based on its OID or NumberForm value, however this
   responsibility may be handled by the RA DSA.

2.2.3.3.3. Horizontal References

   Horizontal (sibling) references describe both adjacent as well as
   minimum and maximum 'registration' contexts.

   During a Search Operation intended to obtain a 'registration' entry,
   the RA DUA SHOULD request the following attribute types:

      - 'leftArc'
      - 'rightArc'
      - 'minArc'
      - 'c-minArc'
      - 'maxArc'
      - 'c-maxArc'

   The 'leftArc' attribute type describes the sibling 'registration'
   entry that is nearest but less than that of the bearer in terms of
   Number Form ('n') numerical magnitude.

   The 'rightArc' attribute type describes the sibling 'registration'
   entry that is nearest but greater than that of the bearer in terms
   of Number Form ('n') numerical magnitude.


Coretta                Expires August 27, 2024                 [Page 15]

Internet-Draft      The OID Directory: RA Client           February 2024


   The 'minArc' and 'c-minArc' attribute types are used to reference the
   'registration' entry bearing the lowest magnitude Number Form ('n')
   value within a set of siblings.  Only one (1) of these Attribute
   Types should be present for any given 'registration' entry, never
   both.

   The 'maxArc' and 'c-maxArc' attribute types are used to reference the
   'registration' entry bearing the highest magnitude Number Form ('n')
   value within a set of siblings.  Only one (1) of these Attribute
   Types should be present for any given 'registration' entry, never
   both.

2.2.3.4.  Client Entry Caching

   For particularly large or busy implementations of this ID series, the
   RA DUA MAY support basic client-driven entry caching of any retrieved
   'registration' and 'registrant' entries by way of either the 'rATTL'
   or 'c-rATTL' integer attribute types, as defined within Section 2.3
   of the RASCHEMA ID.

   A valid use case for caching involves serving IANA PEN registrations
   [PRIVATE], which number in the tens of thousands.  Caching may yield
   tremendous savings in terms of resource utilization associated with
   particularly large numbers of static entries being retrieved in a
   repeating manner.

   This ID makes no assumptions regarding the design or implementation
   of the underlying caching subsystem.  The only abstract requirement
   relates to the ability to cache a single directory entry for a span
   of time equivalent to the effective TTL value in minutes.

   The RA DUA SHOULD allow for the user to determine whether an entry
   being presented is derived from a cache.

2.2.3.4.1.  Semantics

   An 'rATTL' may be found in the following contexts wherever the
   'rADUAConfig', 'registration' or 'registrant' classes are present.

      - A root DSE
      - An RA DIT context
      - An individual leaf-node entry

   The collective counterpart attribute type, 'c-rATTL', may be found on
   all of the above EXCEPT the root DSE.

   Presence of an instance of either of these attribute types for any
   entry serves as an indicator to the RA DUA that a caching directive
   may be in effect depending on the value.

   The significance of value magnitude -- whether collective or not --
   is as follows:

Coretta                Expires August 27, 2024                 [Page 16]

Internet-Draft      The OID Directory: RA Client           February 2024


      - A value less than or equal to "0" is equivalent to a TTL being
        undefined: NO cached lifespan is specified
      - A value greater than or equal to "1" indicates a TTL lifespan
        expressed by that value (e.g.: "1440" for a 24-hour TTL)

   Countdown of a timespan commences at the same time the indicated
   entry is retrieved and cached by the RA DUA according to the value.

   Presence of the 'rATTL' attribute type within the RA DSA's root DSE
   indicates use of global caching, a condition in which all entries
   are cached for a fixed amount of time unless they are subjected to
   an individual override by the 'rATTL' or 'c-rATTL' types.

   Presence of the 'rATTL' attribute type within separate 'rADUAConfig'
   class profile instances indicates context-specific entry caching (for
   example, a single RA DIT in the midst of others served by a common RA
   DSA).

   The 'c-rATTL' attribute type is only present for entries when served
   by an RA DSA which supports collective attributes.  No instance of
   the 'c-rATTL' attribute type shall be present within the root DSE.

   In the face of multiple overlapping TTLs implied for an entry, these
   rules of precedence can guide the RA DUA in determining the correct
   TTL:

      - DSE-based TTL overrides nothing (lowest common denominator)
      - Contextual TTL overrides DSE TTL
      - Collective TTL overrides a subtree of a contextual TTL
      - Non-collective leaf entry TTL overrides all of the above

   If deemed appropriate within the spirit of an implementation, or if
   potentially necessary in an administrative context, the RA DUA MAY
   allow for arbitrary cache bypass, whereas the cached entry may be
   refreshed ahead of its scheduled TTL expiry.

2.2.4.  New Allocations

   The following subsections involve considerations and procedures which
   are related to the incorporation of new registration allocations into
   an RA DIT.

   Each "OID Directory" implementation will almost certainly adopt only
   certain attribute types for use in entries.

   Such restrictions may be exercised based on use of only select object
   classes within an entry, through observance of any DIT content rules
   that may be in effect, or through a form of access control.

   The RA DUA is expected to honor any policies imposed by the service
   that would influence or mandate the composition of new entries in a
   particular way.

Coretta                Expires August 27, 2024                 [Page 17]

Internet-Draft      The OID Directory: RA Client           February 2024


2.2.4.1.  Verification

   Certain preallocation checks MUST be conducted prior to any attempt
   at creating an allocation.  The following subsections describe these
   procedures.  Please note that only the three dimensional directory
   model is covered due to its STRONGLY RECOMMENDED status over the
   alternative model.

   While the RA DSA may implement 'registration' integrity controls of
   its own, the RA DUA SHALL NOT rely on such elements to mitigate bogus
   or ill-advised requests alone.  The RA DUA is REQUIRED to submit only
   well-formed and sanctioned requests, and SHALL NOT be designed under
   the unfounded assumption that the RA DSA will conduct post-operative
   or custodial amendments of any kind.

   Adopters of the RA DUA construct should remember that the context of
   an allocation request can greatly influence the perception of the
   various outcomes discussed in the following subsections.

   For example, consider the entry of retroactive 'registration' entries
   -- obsolete and wholly invalid by today's standards -- by an end user
   simply to build a thorough and well-formed implementation of the OID
   spectrum, versus a new registration being created today, and governed
   by today's standards.  The two scenarios have radically different
   implications, yet the effective action is unchanged.

   Depending on the nature and intended audience of an RA DUA solution,
   this distinction may be particularly important.  It may prove useful
   to allow for effective "overrides" for authorized identities or modes
   of operating, for example, to allow the creation of registrations
   beneath an obsolete superior context.

   It is important to note that the procedures defined in the following
   subsections do not account for any internal governance or approval
   process related to allocation request handling.

2.2.4.1.1.  Ancestral Viability

   Given an intended registration DN of:

      n=9999,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA

   The RA DUA MUST first verify the presence of the intended superior
   registration DN.

      n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA

   This search can be conducted using the following SearchRequest
   parameters:




Coretta                Expires August 27, 2024                 [Page 18]

Internet-Draft      The OID Directory: RA Client           February 2024


      baseObject = n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA
      scope      = 0
      filter     = objectClass=registration
      attributes = registrationStatus
                   registrationClassification
                   isLeafNode
                   isFrozen
                   objectClass

   If exactly one (1) entry is returned with no apparent error, the
   superior entry is confirmed to be present.  In this case, the RA DUA
   should read the values of the requested attribute types.

   If the 'registrationStatus' and/or 'registrationClassification' value
   is OBSOLETE, DEALLOCATED or some other (known) declaration of a state
   of non-operation, this MUST fail the allocation request unless the
   attempt was made in (approved) retroactive context.  The case folding
   scheme in effect for these values is not significant.

   Similarly, if the 'isFrozen' and/or 'isLeafNode' attribute types bear
   a Boolean value of TRUE, the allocation request MUST fail unless the
   attempt was made in (approved) retroactive context.

   The error 'noSuchObject' indicates the requested entry was not found.
   When using LDAP, this bears the resultCode value of "32".

   'noSuchObject' SHOULD be investigated by the RA DUA by way of an
   ancestral traversal -- a process in which each successive ancestor
   entry is subjected to a similar presence check as described above
   in incremental fashion.  Ordering of ancestral traversal checks is
   not significant, as either ordering scheme will ultimately lead to
   the same conclusion.

   Each ancestor entry is referenced using a DN value which lacks the
   leaf-node RDN component of the previously-checked descendant entry.

   For instance, continuing with the above superior DN's lineage:

      - n=1,n=6,n=3,n=1,ou=Registrations,o=rA
      - n=6,n=3,n=1,ou=Registrations,o=rA
      - n=3,n=1,ou=Registrations,o=rA
      - n=1,ou=Registrations,o=rA

   Following this procedure allows the RA DUA or the end user to locate
   where the apparent ancestral discontinuity begins within the RA DIT.

   The terminus of a registration lineage -- such as the one described
   above -- is determined based on the presence of the STRUCTURAL object
   class 'rootArc' for an entry (e.g.: "n=1,ou=Registrations,o=rA").




Coretta                Expires August 27, 2024                 [Page 19]

Internet-Draft      The OID Directory: RA Client           February 2024


2.2.4.1.2.  Number Form Uniqueness

   Within a set of sibling 'registration' entries, it is CRITICAL that
   any new allocation involve use of a horizontally-unique 'n' value.

   Using one of the RECOMMENDED DN syntaxes described in Section 3.1,
   the proper procedure simply involves a Read-based presence check of
   the intended 'registration' DN.

   For instance, if the desired allocation shall bear the DN:

      n=9999,n=3,n=1,ou=Registrations,o=rA

   A preemptive Read Operation MUST be executed in the following manner:

      baseObject = n=9999,n=3,n=1,ou=Registrations,o=rA
      scope      = 0
      typesOnly  = TRUE
      attributes = objectClass

   Use of the 'typesOnly' option is merely for bandwidth efficiency,
   as the goal of this request is to see if ANY entry exists by this
   DN -- not to examine any particular attribute type values.

   If zero (0) entries are returned alongside a 'noSuchObject' error,
   the Number Form is unique.

   Any non-zero number of entries that are returned with no apparent
   error indicates the Number Form is NOT unique and the attempt at
   allocation MUST fail.  The RA DUA SHOULD inform the user of this
   outcome.

   There are no practical override use cases for this condition.

   If using a 'registration' DN syntax other than those RECOMMENDED in
   Section 3.1, use of a filter within a List Operation executed upon
   the intended parent registration may be required at the risk of
   performance penalties proportional to the number of entries present:

      baseObject: = n=3,n=1,ou=Registrations,o=rA
      scope       = 1
      typesOnly   = TRUE
      filter      = n=9999
      attributes  = objectClass

   The same entry count semantics as described above will apply.

   See Section 2.2.4.1.3 for considerations regarding the presence
   of ranges of allocations within the set of sibling registrations.




Coretta                Expires August 27, 2024                 [Page 20]

Internet-Draft      The OID Directory: RA Client           February 2024


2.2.4.1.3.  Ranged Allocations

   During the creation of new registrations, RA DUAs MUST preemptively
   search for any range-based registrations present that might overlap
   with the intended 'n' value of the entry.  This requirement MAY be
   relaxed if it is known that ranged allocations are not supported in
   the target location.

   For example, to determine if a ranged allocation resides within the
   1.3 OID registration that would overlap with a desired Number Form,
   the RA DUA MUST perform a List Operation of the following form:

      baseObject = n=3,n=1,ou=Registrations,o=rA
      scope      = 1
      typesOnly  = TRUE
      filter     = (&(n<=X)
       (|(registrationRange>=X)(registrationRange=-1)))
      attributes = registrationRange

   Given these parameters, where the filter AVA "X" represents the 'n'
   (Number Form) chosen -- for example "100" -- the search will return
   zero (0) entries if no range violation is detected involving value
   "X".  This behavior is unchanged in the midst of multiple finite
   and/or infinite ranges, regardless of contiguity.

   Please note that integer "X" MUST be chosen or selected by some means
   by the RA DUA or its end user for this procedure to work as intended.
   "X" SHALL NOT be negative.

   An infinite range SHALL ONLY appear once in any sibling context, and
   the associated entry DN SHALL ALWAYS represent the true 'maxArc' or
   'c-maxArc' value in the same sibling context, if specified.

   If ANY number of entries are returned as a result of this allocation
   check, the registration MUST fail.  The RA DUA MAY opt to make other
   attempts using another Number Form in place of "X", or it may simply
   inform the user of an overlapping allocation attempt.

   This procedure assumes the preemptive Number Form Uniqueness check
   procedures described in Section 2.2.4.1.2 have been conducted with
   a favorable outcome as described.

   However, in certain use cases, it may be advantageous to replace the
   above 'filter' with:

      (|(&(n<=X)(|(registrationRange>=X)(registrationRange=-1)))(n=X))

   Doing so accomplishes the goals of this section and Section 2.2.4.1.2
   in a single action.




Coretta                Expires August 27, 2024                 [Page 21]

Internet-Draft      The OID Directory: RA Client           February 2024


   The RA DUA MAY opt to impose a 'typesOnly' value of FALSE to allow
   the user to manually observe the range structure(s) present within
   a set of siblings directly (by way of the 'registrationRange' type)
   if and when an overlapping allocation attempt was made.  This allows
   the user to select an appropriate Number Form value in an informed
   manner -- as opposed to trial-and-error methodology, for instance.

2.2.4.2.  Submission

   Assuming the verification procedures covered in Section 2.2.4.1 were
   of a favorable outcome, the submission of the allocation details may
   be indicated.

   This ID assumes that any requisite review or approval processes that
   are practiced by those who serve in authority over the RA have been
   performed.

   Creation of a directory entry, based upon decided allocation details,
   is the last step necessary for a proper submission.  Please see the
   RADIT ID for details and many examples regarding entry composition.

   The Add Operation is the intended means for submission of the entry.

   If the particular implementation of this ID series does not support
   this operation in this manner, the RA DSA may be expected to support
   another means out of scope for this ID series.

   Upon submission of the composed entry to the receiving RA DSA, the
   RA DUA SHOULD retrieve the newly added entry to verify attribute type
   and object class content is present as intended.  This should precede
   any declarations of successful submission to the end user.

2.2.5.  Allocation Updates

   Updates to 'registration' entries, as mentioned previously, is often
   ill-advised outside of extraordinary circumstances, likely involving
   corrections to entries deemed to be of poor form, or created in bad
   faith.  A general rule-of-thumb suggests that any 'registration' is
   typically static.

   Updates to 'registrant' entries or attributes, however, is far more
   likely if contact information, which changes over time, is present.

   Nevertheless, alterations to the content of entries in either context
   is facilitated through use of the Modify Operation for any of the
   following desired actions:

      - Addition of object class values
      - Addition of attribute type instances or values
      - Removal of undesirable or invalid attribute instances or values
      - Correction of bogus attribute type values
      - Relegation of a currentAuthority to a firstAuthority

Coretta                Expires August 27, 2024                 [Page 22]

Internet-Draft      The OID Directory: RA Client           February 2024


   In an even more exceptional (and unlikely) scenario, the correction
   of an invalid Number Form or OID RDN value is facilitated through
   use of the Modify DN Operation, which is intended for the "renaming"
   and/or "relocation" of a specified entry.  This is almost certainly
   an administratively focused use case.

   The semantics for either of these operations are well outside the
   scope of this ID series.

3.  IANA Considerations

   There are no requests to IANA in this document at this time.

4.  Security Considerations

   The RA DUA MUST possess the capability to honor any authentication
   and/or confidentiality policies imposed by the RA DSA.  This would
   imply Bind and Unbind capabilities, at the least.

   This may involve strategies related to TLS, 2FA, OTP and others.  TLS
   support may include facilities for mutual authentication.  Support of
   password-related operations -- such as those defined in [RFC3062] --
   may be indicated.

   Certain directory implementations may require these capabilities be
   exercised prior to interaction with ANY facet of the directory -- no
   matter how innocuous a request may be perceived (for instance, basic
   query of the root DSE only).  This is an especially common practice
   in high-security X.500/LDAP implementations.  Adopters are advised to
   be prepared for such conditions.

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.

   RASCHEMA   Coretta, J., "The OID Directory: The RA Schema",
              draft-coretta-oiddir-schema, February 2024.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate       
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Coretta                Expires August 27, 2024                 [Page 23]

Internet-Draft      The OID Directory: RA Client           February 2024


   [RFC2696]  C. Weider, A. Herron, A. Anantha, Microsoft, T. Howes
              and Netscape, "LDAP Control Extension for Simple Paged
              Results Manipulation", RFC 2696, September 1999.

   [RFC3671]  Zeilenga, K., "Collective Attributes in the Lightweight
              Directory Access Protocol (LDAP)", RFC 3671, December
              2003.

   [RFC4511]  J. Sermersheim, Ed. "Lightweight Directory Access Protocol
              (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC 8174, May 2017.

   [X.501]    International Telecommunication Union - Telecommunication
              Standardization Sector, "The Directory: Models", ITU-T
              X.501, October 2019.

   [X.511]    International Telecommunication Union - Telecommunication
              Standardization Sector, "The Directory: Abstract service
              definition", ITU-T X.511, October 2019.

5.2.  Informative References

   [PRIVATE]  IANA, "Private Enterprise Numbers",                       
              https://www.iana.org/assignments/enterprise-numbers.

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

   [RFC3062]  Zeilenga, K., "LDAP Password Modify Extended Operation",
              RFC 3062, February 2001.

   [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

   [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 24]

Internet-Draft      The OID Directory: RA Client           February 2024


   [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.680]    International Telecommunication Union - Telecommunication
              Standardization Sector, "Abstract Syntax Notation One
              (ASN.1): Specification of basic notation", ITU-T X.680,
              July 2002.

Author's Address

   Jesse Coretta
   California, United States

   Email: jesse.coretta@icloud.com






































Coretta                Expires August 27, 2024                 [Page 25]