viathinksoft-std-0002-oidip.txt

 



VIATHINKSOFT/WEBFAN                                         D. Marschall
SPECIFICATION No. 2                                         ViaThinkSoft
First Draft: 2010                                       2 September 2024


               === OID Information Protocol (OID-IP) ===

Abstract

   This document defines a method for retrieving information about
   Object Identifiers (OIDs) and their associated Registration
   Authorities (RAs) through the HTTP or WHOIS protocol, in a way that
   is both human-readable and machine-readable.  Besides a text output
   format, OID-IP also supports sending information in JSON and XML.

Identification of this Document

   Revision:  2024-09-02
   State:     In Force
   Filename:  viathinksoft-std-0002-oidip.txt
   URN:       urn:x-viathinksoft:std:0002:2024-09-02
   OID:       1.3.6.1.4.1.37476.3.5.10
              { iso(1) identified-organization(3) dod(6) internet(1)
                private(4) enterprise(1) 37476 specifications(3)
                communication(5) oid-ip(10) }
   WEID:      weid:pen:SX0-3-5-A-6
   IETF/RFC:  draft-viathinksoft-oidip-10

Attachments

   XML Schema:
   https://github.com/ViaThinkSoft/standards/blob/main/viathinksoft-std-
   0002-oidip.xsd

   JSON Schema:
   https://github.com/ViaThinkSoft/standards/blob/main/viathinksoft-std-
   0002-oidip.json

Copyright Notice

   Copyright (c) 2010-2024 ViaThinkSoft and the persons identified as
   the document authors.  All rights reserved.

   Licensed under the terms of the Apache 2.0 License.




 


Marschall                                                       [Page 1]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  6
   2  Request . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.1  Request via HTTP(S) Protocol (Recommended)  . . . . . . . .  7
       2.1.1  Request Method and Path . . . . . . . . . . . . . . . .  7
       2.1.2  Formats and Content-Types . . . . . . . . . . . . . . .  8
       2.1.3  Authentication  . . . . . . . . . . . . . . . . . . . .  9
       2.1.4  Preferred Language  . . . . . . . . . . . . . . . . . . 10
       2.1.5  Custom Input Parameters . . . . . . . . . . . . . . . . 10
       2.1.6  Cookies . . . . . . . . . . . . . . . . . . . . . . . . 11
     2.2  Request via WHOIS Protocol (Backwards Compatibility)  . . . 11
       2.2.1  Request Method  . . . . . . . . . . . . . . . . . . . . 11
         2.2.1.1  Basic Query String  . . . . . . . . . . . . . . . . 11
         2.2.1.2  Input Parameters  . . . . . . . . . . . . . . . . . 12
         2.2.1.3  Request ABNF Notation . . . . . . . . . . . . . . . 12
       2.2.2  Format ("format" Argument)  . . . . . . . . . . . . . . 14
       2.2.3  Authentication Tokens ("auth" Argument) . . . . . . . . 14
       2.2.4  Preferred Language ("lang" Argument)  . . . . . . . . . 15
       2.2.5  Custom Input Parameters . . . . . . . . . . . . . . . . 16
   3  Response  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     3.1  Format and Encoding . . . . . . . . . . . . . . . . . . . . 16
       3.1.1  "text" Format . . . . . . . . . . . . . . . . . . . . . 16
       3.1.2  "json" Format . . . . . . . . . . . . . . . . . . . . . 17
       3.1.3  "xml" Format  . . . . . . . . . . . . . . . . . . . . . 17
     3.2  Sections  . . . . . . . . . . . . . . . . . . . . . . . . . 17
       3.2.1  Query-Section (Information about Query and Result)  . . 18
         3.2.1.1  Query-Section "query" Field . . . . . . . . . . . . 18
         3.2.1.2  Query-Section "result" Field  . . . . . . . . . . . 18
         3.2.1.3  Query-Section "distance" Field  . . . . . . . . . . 19
         3.2.1.4  Query-Section "message" Field . . . . . . . . . . . 19
         3.2.1.5  Query-Section "lang" Field  . . . . . . . . . . . . 19
         3.2.1.6  Query-Section Other Fields  . . . . . . . . . . . . 19
       3.2.2  Object-Section (Information about the OID)  . . . . . . 19
         3.2.2.1  Object-Section "object" Field . . . . . . . . . . . 19
         3.2.2.2  Object-Section "status" Field . . . . . . . . . . . 19
         3.2.2.3  Object-Section "lang" Field . . . . . . . . . . . . 20
         3.2.2.4  Object-Section "name" Field . . . . . . . . . . . . 20
         3.2.2.5  Object-Section "description" Field  . . . . . . . . 20
         3.2.2.6  Object-Section "information" Field  . . . . . . . . 20
         3.2.2.7  Object-Section "url" Field  . . . . . . . . . . . . 20
         3.2.2.8  Object-Section "asn1-notation" Field  . . . . . . . 20
         3.2.2.9  Object-Section "iri-notation" Field . . . . . . . . 21
         3.2.2.10  Object-Section "identifier" Field  . . . . . . . . 21
         3.2.2.11  Object-Section "standardized-id" Field . . . . . . 21
         3.2.2.12  Object-Section "unicode-label" Field . . . . . . . 21
         3.2.2.13  Object-Section "long-arc" Field  . . . . . . . . . 21
 


Marschall                                                       [Page 2]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


         3.2.2.14  Object-Section "oidip-service" Field . . . . . . . 22
         3.2.2.15  Object-Section "oidip-pubkey" Field  . . . . . . . 22
         3.2.2.16  Object-Section "attribute" Field . . . . . . . . . 22
         3.2.2.17  Object-Section "parent" Field  . . . . . . . . . . 23
         3.2.2.18  Object-Section "subordinate" Field . . . . . . . . 23
         3.2.2.19  Object-Section "created" Field . . . . . . . . . . 23
         3.2.2.20  Object-Section "updated" Field . . . . . . . . . . 23
         3.2.2.21  Object-Section Other Fields  . . . . . . . . . . . 23
       3.2.3  RA-Section (Information about the Current RA) . . . . . 24
         3.2.3.1  RA-Section "ra" Field . . . . . . . . . . . . . . . 24
         3.2.3.2  RA-Section "ra-status" Field  . . . . . . . . . . . 24
         3.2.3.3  RA-Section "ra-lang" Field  . . . . . . . . . . . . 24
         3.2.3.4  RA-Section "ra-contact-name" Field  . . . . . . . . 24
         3.2.3.5  RA-Section "ra-address" Field . . . . . . . . . . . 24
         3.2.3.6  RA-Section "ra-phone" Field . . . . . . . . . . . . 25
         3.2.3.7  RA-Section "ra-mobile" Field  . . . . . . . . . . . 25
         3.2.3.8  RA-Section "ra-fax" Field . . . . . . . . . . . . . 25
         3.2.3.9  RA-Section "ra-email" Field . . . . . . . . . . . . 25
         3.2.3.10  RA-Section "ra-url" Field  . . . . . . . . . . . . 25
         3.2.3.11  RA-Section "ra-attribute" Field  . . . . . . . . . 25
         3.2.3.12  RA-Section "ra-created" Field  . . . . . . . . . . 26
         3.2.3.13  RA-Section "ra-updated" Field  . . . . . . . . . . 26
         3.2.3.14  RA-Section Other Fields  . . . . . . . . . . . . . 26
       3.2.4  Sections for Previous Registration Authorities  . . . . 26
     3.3  Digital Signature . . . . . . . . . . . . . . . . . . . . . 27
       3.3.1  "text" Format . . . . . . . . . . . . . . . . . . . . . 27
       3.3.2  "json" Format . . . . . . . . . . . . . . . . . . . . . 27
       3.3.3  "xml" Format  . . . . . . . . . . . . . . . . . . . . . 28
     3.4  Date/Time Format  . . . . . . . . . . . . . . . . . . . . . 28
       3.4.1  Date/Time Format ABNF Notation  . . . . . . . . . . . . 28
       3.4.2  Date/Time Format Examples . . . . . . . . . . . . . . . 29
     3.5  HTTP Response Status Codes  . . . . . . . . . . . . . . . . 29
   4  Referral  . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   5  Full Example ("text" Format)  . . . . . . . . . . . . . . . . . 32
     5.1  Request . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     5.2  Response  . . . . . . . . . . . . . . . . . . . . . . . . . 32
   6  Alternative Namespaces  . . . . . . . . . . . . . . . . . . . . 33
     6.1  Example: UUID Namespace . . . . . . . . . . . . . . . . . . 34
       6.1.1  Request . . . . . . . . . . . . . . . . . . . . . . . . 34
       6.1.2  Response  . . . . . . . . . . . . . . . . . . . . . . . 34
   7  Internationalization Considerations . . . . . . . . . . . . . . 34
   8  Security Considerations . . . . . . . . . . . . . . . . . . . . 35
   9  RA Considerations . . . . . . . . . . . . . . . . . . . . . . . 36
   10  References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 36
     10.2  Informative References . . . . . . . . . . . . . . . . . . 38
   Appendix A.  JSON Format Schema and Example  . . . . . . . . . . . 40
   Appendix A.1.  JSON Format Schema  . . . . . . . . . . . . . . . . 40
 


Marschall                                                       [Page 3]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   Appendix A.2.  JSON Format Example of Output . . . . . . . . . . . 49
   Appendix B.  XML Format Schema and Example . . . . . . . . . . . . 51
   Appendix B.1.  XML Format Schema . . . . . . . . . . . . . . . . . 51
   Appendix B.2.  XML Format Example of Output  . . . . . . . . . . . 60
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 62
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62










































 


Marschall                                                       [Page 4]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


1  Introduction

   An Object Identifier (OID) is an extensively used identification
   mechanism jointly developed by ITU-T and ISO/IEC for naming any type
   of object with a globally unambiguous name.  OIDs provide a
   persistent identification of objects based on a hierarchical
   structure of Registration Authorities (RA), where each parent has an
   Object Identifier and allocates Object Identifiers to child nodes. 
   More information about Object Identifiers can be found in
   Recommendation ITU-T X.660 (2011) | ISO/IEC 9834-1:2012 [X660].

   There are a few methods of retrieving information about an OID, like:

   (A) Searching through web repositories like <http://www.oid-info.com>
       or <http://www.alvestrand.no/objectid/>.  This has the
       disadvantage that the information is usually not machine-readable
       without functionalities like an API.

   (B) Retrieving information using the Object Identifier Resolution
       System (ORS) as defined in Recommendation ITU-T X.672 (2010) |
       ISO/IEC 29168-1:2011 [X672].  This has the disadvantage that
       Registration Authorities need to include specific DNS Resource
       Records to their domains, and additionally, all RAs of the
       superior OIDs must implement the ORS.

   This document describes a method for retrieving information about
   OIDs, which is both human-readable and machine-readable.

   Three of many possible use-case scenarios are:

   (1) Many web browsers and Operating Systems can handle ITU-T X.509
       certificates [X509] and usually contain a viewer application that
       shows the contents of these certificates.  Attributes that are
       unknown by the application are either only displayed by their
       OID, or hidden to avoid confusion for the user.  With OID-IP, the
       application could query the name of these unknown OIDs or even
       retrieve instructions on how the data described by these OIDs can
       be parsed and displayed.

   (2) Applications that handle SNMP (Simple Network Management
       Protocol) [RFC1157] might need information about additional MIB
       files or their OIDs.  OID-IP could aid these applications in
       gathering the required information.

   (3) In directory services like LDAP (Lightweight Directory Access
       Protocol) [RFC4511], applications could query the name of
       attributes that are described by an OID the application doesn't
       know.
 


Marschall                                                       [Page 5]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


1.1  Terminology

   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.

   The following list describes terminology and definitions used
   throughout this document:

      ABNF        Augmented Backus-Naur Form, a format used to represent
                  permissible strings in a protocol or language, as
                  defined in [RFC5234].

      arc         Synonymous for "node" in the terminology of Object
                  Identifiers.

      ASCII       American Standard Code for Information Interchange

      HTTP(S)     Hypertext Transfer Protocol (Secure), as defined in
                  [RFC9112].

      JSON        JavaScript Object Notation, an open standard file
                  format and data interchange format, as defined in
                  [RFC8259].

      OID         Object Identifier, an identifier mechanism
                  standardized by the International Telecommunication
                  Union (ITU) and ISO/IEC.

      OID-IP      Object Identifier Information Protocol, as defined in
                  this document.

      RA          Registration Authority, an entity responsible for
                  allocating arcs to sub-nodes and recording that
                  allocation (together with the organization the
                  subordinate node has been allocated to).

      TCP         Transmission Control Protocol

      UTF-8       8-bit Unicode Transformation Format, as defined in
                  [RFC3629].

      XML         Extensible Markup Language, a markup language and file
                  format for storing, transmitting, and reconstructing
                  arbitrary data ([XML]).

 


Marschall                                                       [Page 6]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


2  Request

   OID Information Protocol (OID-IP) is a text-based protocol that is
   built on top of the Hypertext Transfer Protocol [RFC9112] as defined
   in section 2.1 and/or the WHOIS protocol [RFC3912] as defined in
   section 2.2.  (The concept of OID-IP was established in 2011 and is
   already implemented by several vendors, hence WHOIS is part of this
   specification.)

2.1  Request via HTTP(S) Protocol (Recommended)

2.1.1  Request Method and Path

   All requests MUST be made using the HTTP(S) request methods "GET" or
   "POST" in the following structure:

       GET /.../<objectType>/<objectIdentifier>/<format>

       POST /.../<objectType>/<objectIdentifier>/<format>

   whereas

   <objectType> is a namespace identifier which MUST be written in
   lower-case.  It is usually "oid" (but can also be something else, see
   an example in section 6).

   <objectIdentifier> is the identifier to be requested.  For OIDs, it
   MUST be an absolute OID and MUST be written in dot-notation without
   leading dot as defined in RFC 3061, section 2 [RFC3061], e.g.
   "2.999".  Relative OIDs (e.g. relative to the OID of the Registration
   Authority operating the OID-IP service) are not allowed.

   <format> is the desired output format.  This document defines "text",
   "json", and "xml" which are described in section 2.1.2.

   Example of an URL that receives a GET request:

       https://example.com/oidip/oid/2.999/text

   To query the root node of any object type, <objectIdentifier> MUST
   have the value "root"; for example:

       https://example.com/oidip/oid/root/text

   Since the word "root" has thereby a special meaning, identifiers that
   actually have the name "root" CANNOT be queried using OID-IP.


 


Marschall                                                       [Page 7]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   This document describes the following additional GET/POST parameters:

   (1) Authentication tokens ("auth" parameter), which is described in
       section 2.1.3.

   (2) Preferred language ("lang" parameter), which is described in
       section 2.1.4.

   Constraints for custom input parameters are described in
   section 2.1.5.


2.1.2  Formats and Content-Types

   This document defines 3 formats:

   (1) "text": A text representation as defined in section 3.1.1
       (MANDATORY).  The "Content-Type" response header MUST be
       "text/vnd.viathinksoft.oidip".

   (2) "json": The JavaScript Object Notation (JSON, [RFC8259])
       representation as defined in section 3.1.2 (MANDATORY for the
       HTTP(S) request method).  The "Content-Type" response header MUST
       be "application/vnd.viathinksoft.oidip+json".

   (3) "xml": Extensible Markup Language (XML, [XML]) representation as
       defined in section 3.1.3 (MANDATORY for the HTTP(S) request
       method).  The "Content-Type" response header MUST be
       "application/vnd.viathinksoft.oidip+xml".

   The default format is "text", which is assumed if the "format"
   argument is omitted.

   Besides these 3 formats, the server can accept other formats not
   defined in this document.  The name of the formats MUST be
   alphanumeric, lower-case, and non-empty, and SHOULD be written in the
   English language (e.g. "text") or be common abbreviations (e.g.
   "json").

   If the client requests a format that is not implemented, then the
   server MUST respond with the "text" format, and the output MUST
   consist of the "query" field, "result: Service error", a fitting
   "message" field (as described in section 3.2.1), and MUST be sending
   the HTTP response code "400 Bad Request".




 


Marschall                                                       [Page 8]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


2.1.3  Authentication

   Some organizations might not want to present their OID information
   (or part of it) to the public, e.g. for reasons like privacy or
   confidentiality.  Therefore, the following authentication methods are
   possible to control the display of confidential information returned
   by the OID-IP service:

   (1) Whitelisting the client's IP address

   (2) Supply of authentication tokens by the sender

       Authentication tokens can be sent as "auth" GET parameter (can be
       entered by a human in a browser), as "auth" POST parameter, or as
       "Authorization: Bearer ..." request header (for automated
       requests).  To make authentication as easy as possible, it is
       RECOMMENDED to allow all three methods if authentication is
       implemented.

       The origin of the authentication token (whether it is hardcoded
       or previously generated by an external authentication frameworks
       such as OAuth 2.0) as well as its verification is not part of
       this specification and hence implementation specific.

       HTTP Authentication as defined in RFC 9110 MUST NOT be used.

       The GET parameter has priority over the POST parameter, which has
       priority over the HTTP(S) request header.

       Authentication tokens MUST be case-sensitive and non-empty, and
       MUST NOT contain a dollar sign ("$"), an equal sign ("="), or a
       comma sign (",").

       If multiple authentication tokens need to be submitted, then the
       "auth" argument MUST NOT be repeated.  Instead, the tokens are
       separated using a comma sign (",").  A token MUST NOT be used
       multiple times in the same query.

       Example of an URL that receives a GET request:

           https://example.com/oidip/oid/2.999/text?auth=rumpelstiltskin

       Please note that authentication tokens should only be used if the
       connection is secure.  For more information, see section 8
       "Security Considerations".

   The usage of authentication is OPTIONAL.

 


Marschall                                                       [Page 9]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


2.1.4  Preferred Language

   The client can request the preferred language of human-readable
   descriptions, names, comments, and error messages using the Accept-
   Language request header, or using a GET or POST parameter.

   The GET parameter has priority over the POST parameter, which has
   priority over the HTTP(S) request header.

   If the server has data in different languages, it should try to find
   the best-fitting language according to the client's request.

   If the GET or POST parameter is used, then the value MUST be a list
   of language tags as defined by [RFC5646], separated by a comma sign,
   sorted by preference, and containing at least one element.  So, in
   contrast to the "Accept-Language" request header, weights and
   wildcards MUST NOT be used.

   The translation SHALL only affect the "message", "name",
   "description", and "information" fields, as well as additional fields
   and comments if their translation makes sense.  Field names MUST NOT
   be translated.  For example, the field name "description" will always
   be in the English language, even if the client requests a response in
   a different language.

   The following request is an example of a valid query where the client
   asks for information written in the English language, preferring US
   American English:

       https://example.com/oidip/oid/2.999/text?lang=en-US,en

   The usage of the "Accept-Language" request header or "lang" GET/POST
   parameter is OPTIONAL.


2.1.5  Custom Input Parameters

   The usage of input parameters not described in this document is
   individual for each implementation.

   Names MUST be alphanumeric, lower-case, and non-empty, and SHOULD be
   written in the English language (e.g. "database") or be common
   abbreviations (e.g. "db" instead of "database").

   Values MUST be case-sensitive and non-empty, and MUST NOT contain a
   dollar sign ("$") or an equal sign ("=").

   The usage of the custom input parameters is OPTIONAL.
 


Marschall                                                      [Page 10]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


2.1.6  Cookies

   The presence (or absence) of cookies MUST NOT make any difference to
   the OID-IP output.  Cookies MUST NOT be used for authentication.

2.2  Request via WHOIS Protocol (Backwards Compatibility)

2.2.1  Request Method

   With the WHOIS protocol request method, an OID-IP server listens by
   default on TCP port 43 (WHOIS) for requests from OID-IP clients.  Due
   to the compatibility between OID-IP and WHOIS, existing WHOIS clients
   can be re-used and existing WHOIS servers can add the functionalities
   described in this document in addition to their usual operation.

   The OID-IP client makes a text request to the OID-IP server, then the
   OID-IP server replies with text content.  All requests are terminated
   with ASCII CR followed by ASCII LF.  The response contains multiple
   lines of text, separated by ASCII CR followed by ASCII LF.  The OID-
   IP server closes its connection as soon as the output is finished. 
   The closed TCP connection indicates to the client that the response
   has been received.

2.2.1.1  Basic Query String

   During the request, the client sends a query beginning with the
   namespace identifier (usually "oid", but it can also be something
   else, see an example in section 6), followed by a colon ":" and the
   requested identifier.

   The namespace identifier MUST be written in lower-case.

   If the namespace identifier is "oid", then the identifier must be an
   absolute OID in dot-notation, as defined in RFC 3061, section 2
   [RFC3061], but with the following differences:

   (1) The OID MAY contain a leading dot.

   (2) To query the root of the OID tree, the OID MUST be either missing
       or consisting only of a single dot.

   Examples of valid queries are:

       oid:
       oid:.
       oid:2.999
       oid:.2.999

 


Marschall                                                      [Page 11]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   All OIDs MUST be interpreted as absolute OIDs.  Relative OIDs (e.g.
   relative to the OID of the Registration Authority operating the OID-
   IP service) are not allowed.

2.2.1.2  Input Parameters

   The client can send additional information to the server using "input
   parameters".

   Names MUST be treated as case-sensitive.

   A request can contain multiple input parameters which are each
   prepended by a dollar sign ("$").

   An equal sign ("=") divides the "name" from the "value".

   Each name MUST only appear a single time in the list of input
   parameters.

   This document describes the following input parameters:

   (1) Format ("format" argument), which is described in section 2.2.2.

   (2) Authentication tokens ("auth" argument), which is described in
       section 2.2.3.

   (3) Preferred language ("lang" argument), which is described in
       section 2.2.4.

   Constraints for custom input parameters are described in
   section 2.2.5.

   The following request is an example of a valid query where the client
   sends a "format" argument with the value "json":

       oid:2.999$format=json

2.2.1.3  Request ABNF Notation

   To define the query string, the following Augmented BNF definitions
   will be used.  They are based on the ABNF styles of RFC 5234
   [RFC5234].

   query           = object optional-args

   object          = ( str-oid       ":" optional-oid ) /
                     ( other-ns-name ":" other-ns-val )
   str-oid         = %x6F.69.64           ; %s"oid"    in RFC 7405
 


Marschall                                                      [Page 12]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   ; Additional constraint: Query MUST NOT contain more than one
   ;                        argument with the same name.
   optional-args   = *( "$" argument )

   argument        = ( str-format     "=" format ) /
                     ( str-auth       "=" tokens ) /
                     ( str-lang       "=" languages ) /
                     ( other-arg-name "=" other-arg-val )
   str-format      = %x66.6F.72.6D.61.74  ; %s"format" in RFC 7405
   str-auth        = %x61.75.74.68        ; %s"auth"   in RFC 7405
   str-lang        = %x6C.61.6E.67        ; %s"lang"   in RFC 7405

   optional-oid    = [ "." ] [ oid ]

   oid             = unsigned-number *( "." unsigned-number )

   format          = str-text /
                     str-json /
                     str-xml  /
                     1*( lowercase-char / digit )
   str-text        = %x74.65.78.74        ; %s"text"   in RFC 7405
   str-json        = %x6A.73.6F.6E        ; %s"json"   in RFC 7405
   str-xml         = %x78.6D.6C           ; %s"xml"    in RFC 7405

   ; Language-Tag is defined in RFC 5646
   languages       = Language-Tag *( "," Language-Tag )

   ; Additional constraint: Tokens MUST NOT be used more than one time
   ;                        in the same query.
   tokens          = token *( "," token )

   ; Printable characters (%x21-7E), excluding dollar sign (%x24 "$"),
   ; equal sign (%x3D "="), and comma sign (%x2C ",").
   token           = 1*( %x21-23 / %x25-2B / %x2D-3C / %x3E-7E )

   ; Additional constraint: MUST NOT be <str-format> or <str-auth>.
   other-arg-name  = 1*( lowercase-char / digit )

   ; Printable characters (%x21-7E), excluding dollar sign (%x24 "$")
   ; and equal sign (%x3D "=").
   other-arg-val   = 1*( %x21-23 / %x25-3C / %x3E-7E )

   ; Additional constraint: MUST NOT be <str-oid>.
   other-ns-name   = 1*( lowercase-char / digit )

   ; Printable characters (%x21-7E), excluding dollar sign (%x24 "$").
   other-ns-val    = *( %x21-23 / %x25-7E )

 


Marschall                                                      [Page 13]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   unsigned-number = "0" / ( nonzero-digit *digit )

   digit           = %x30-39  ; 0-9
   nonzero-digit   = %x31-39  ; 1-9
   lowercase-char  = %x61-7A  ; a-z

2.2.2  Format ("format" Argument)

   The "format" argument defines the desired output format.

   This document defines 3 formats:

   (1) "text": A text representation as defined in section 3.1.1
       (MANDATORY).

   (2) "json": The JavaScript Object Notation (JSON, [RFC8259])
       representation as defined in section 3.1.2 (RECOMMENDED).

   (3) "xml": Extensible Markup Language (XML, [XML]) representation as
       defined in section 3.1.3 (RECOMMENDED).

   The default format is "text", which is assumed if the "format"
   argument is omitted.

   Besides these 3 formats, the server can accept other formats not
   defined in this document.  The name of the formats MUST be
   alphanumeric, lower-case, and non-empty, and SHOULD be written in the
   English language (e.g. "text") or be common abbreviations (e.g.
   "json").

   If the client requests a format that is not implemented, then the
   server MUST respond with the "text" format, and the output MUST
   consist of the "query" field, "result: Service error", and a fitting
   "message" field (as described in section 3.2.1).

   The usage of the argument "format" is OPTIONAL.

2.2.3  Authentication Tokens ("auth" Argument)

   Some organizations might not want to present their OID information
   (or part of it) to the public, e.g. for reasons like privacy or
   confidentiality.  Therefore, one or more "authentication tokens" can
   be sent to control the display of confidential information returned
   by the OID-IP service.

   Authentication tokens MUST be case-sensitive and non-empty, and MUST
   NOT contain a dollar sign ("$"), an equal sign ("="), or a comma sign
   (",").
 


Marschall                                                      [Page 14]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   If multiple authentication tokens need to be submitted, then the
   "auth" argument MUST NOT be repeated.  Instead, the tokens are
   separated using a comma sign (",").  A token MUST NOT be used
   multiple times in the same query.

   Examples of valid queries are:

       oid:2.999$auth=firstToken
       oid:2.999$auth=firstToken,secondToken

   Please note that authentication tokens are only weak protection.  For
   more information, see section 8 "Security Considerations".

   The usage of the argument "auth" is OPTIONAL.

2.2.4  Preferred Language ("lang" Argument)

   The client can request the preferred language of human-readable
   descriptions, names, comments, and error messages using the "lang"
   argument.

   If the server has data in different languages, it should try to find
   the best-fitting language according to the client's request.

   The value of the "lang" argument MUST be a list of language tags as
   defined by [RFC5646], separated by a comma sign, sorted by
   preference, and containing at least one element.

   The translation SHALL only affect the "message", "name",
   "description", and "information" fields, as well as additional fields
   and comments if their translation makes sense.  Field names MUST NOT
   be translated.  For example, the field name "description" will always
   be in the English language, even if the client requests a response in
   a different language.

   The following request is an example of a valid query where the client
   asks for information written in the English language, preferring US
   American English:

       oid:2.999$lang=en-US,en

   The usage of the argument "lang" is OPTIONAL.






 


Marschall                                                      [Page 15]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


2.2.5  Custom Input Parameters

   The usage of input parameters not described in this document is
   individual for each implementation.

   Names MUST be alphanumeric, lower-case, and non-empty, and SHOULD be
   written in the English language (e.g. "database") or be common
   abbreviations (e.g. "db").

   Values MUST be case-sensitive and non-empty, and MUST NOT contain a
   dollar sign ("$") or an equal sign ("=").

   The usage of the custom input parameters MUST be OPTIONAL.

3  Response

3.1  Format and Encoding

3.1.1  "text" Format

   (1) The response MUST be UTF-8 encoded (as defined in RFC 3629
       [RFC3629]), without Byte-Order-Mark (BOM).

   (2) The response contains multiple lines with field names and values,
       which MUST be separated by a double colon (":").  Whitespace
       characters after the double colon are allowed.

   (3) If possible, each line SHOULD be limited to 80 characters,
       including the field name, double colon, value, and whitespaces.

   (4) Field names and values MUST be treated as case-sensitive.

   (5) If a value needs to be split into multiple lines, e.g. if the
       line would exceed the length limit, the same field name including
       double colon MUST be repeated at the beginning of the next line.

   (6) If an attribute has multiple values (e.g. multiple Unicode
       labels, alternative email addresses, etc.), each value MUST be
       written in a new line with the same field name.

   (7) Lines with the same field name SHALL be kept together.

   (8) Comment lines MUST start with a percent sign ("%") at the
       beginning of a line, without prepending whitespaces.  They MUST
       NOT be evaluated by machines (except for signature validation, as
       mentioned in section 3.3 "Digital Signature").


 


Marschall                                                      [Page 16]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   (9) A response consists of sections, which MUST be separated by at
       least one empty line and/or comment line.

  (10) Custom sections CAN be added after any section defined in this
       document.  The query section MUST be the first section in the
       response.

3.1.2  "json" Format

   (1) The response MUST be UTF-8 encoded (as defined in RFC 3629
       [RFC3629]), without Byte-Order-Mark (BOM).

   (2) A response consists of sections, which MUST be named
       "querySection", "objectSection", "raSection", "ra1Section", etc.
       which SHOULD stay in this order.

   (3) Custom sections CAN be added.  The name of these custom sections
       MUST be the name of the first field, appended by the string
       "Section".

   (4) The JavaScript Object Notation (JSON, [RFC8259]) output MUST
       match the schema defined in Appendix A.1 of this document.

3.1.3  "xml" Format

   (1) The response MUST be UTF-8 encoded (as defined in RFC 3629
       [RFC3629]), without Byte-Order-Mark (BOM).

   (2) A response consists of sections, which MUST be named
       "querySection", "objectSection", "raSection", "ra1Section", etc.
       which MUST stay in this order.

   (3) Custom sections CAN be added.  The name of these custom sections
       MUST be the name of the first field, appended by the string
       "Section".  These custom sections MUST be specified in a
       different XML namespace at the end of the last RA section.

   (4) The Extensible Markup Language (XML, [XML]) output MUST match the
       schema defined in Appendix B.1 of this document.

3.2  Sections

   This document specifies the following sections:

   (1) Query-Section which contains the request and the result, as
       described in section 3.2.1.


 


Marschall                                                      [Page 17]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   (2) Object-Section which contains information about the OID, as
       described in section 3.2.2.

   (3) RA-Section which contains information about the current
       Registration Authority, as described in section 3.2.3.

   (4) Optional RA-Sections containing information about RAs that were
       previously in charge of managing the OID, as described in
       section 3.2.4.

3.2.1  Query-Section (Information about Query and Result)

   This section MUST always be present and MUST start with the field
   "query".  It MUST be the first section in the response.

   Possible fields are:

3.2.1.1  Query-Section "query" Field

   "query" MUST be present and contains the request string the client
   has sent.  Canonization or sanitation (like removing a leading dot in
   front of the OID) SHOULD NOT be applied at this step.  Authentication
   tokens SHOULD be omitted, though.

3.2.1.2  Query-Section "result" Field

   "result" MUST be present and SHALL be one of the following values:

   (1) "Found" means that the OID-IP service can verify that the
       requested OID exists.  The following sections will contain
       information about this OID.

   (2) "Not found; superior object found" means that the OID-IP service
       cannot verify that the requested OID exists, or it denies that
       the OID exists (e.g. because it is confidential).  However, the
       OID-IP service knows a superior OID which does exist.  The
       following sections will contain information about that superior
       OID instead.

   (3) "Not found" means that the OID-IP service cannot verify that the
       requested OID exists, or it denies that the OID exists (e.g.
       because it is confidential).  Additionally, the OID-IP service
       does not have information about any superior OID, or their
       existence is also denied.

   (4) "Service error" means that an internal error occurred, or that
       the system is in maintenance mode.  The client should try again
       later.
 


Marschall                                                      [Page 18]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


3.2.1.3  Query-Section "distance" Field

   "distance" SHOULD be present if it is applicable in the requested
   namespace (it is always applicable for OIDs) and if the result is
   "Not found; superior object found".  A distance of 1 means that the
   direct parent was found.  A distance of 2 means that the grand-parent
   was found, etc.

3.2.1.4  Query-Section "message" Field

   "message" SHOULD be present if the result is "Service error".  It
   contains a message explaining why the service is not available (e.g.
   displaying an error message).  It MUST NOT be present if the result
   has a different value.

3.2.1.5  Query-Section "lang" Field

   "lang" (OPTIONAL) contains the language of the field "message".  The
   language should be a language tag as defined in [RFC5646].

3.2.1.6  Query-Section Other Fields

   The OID-IP service SHOULD NOT add additional fields to the Query
   section.

3.2.2  Object-Section (Information about the OID)

   This section MUST be present if the result is "Found" or "Not found;
   superior object found".  It MUST start with the field "object".  It
   MUST NOT be present if the result is "Not found" or "Service error".

   Possible fields are:

3.2.2.1  Object-Section "object" Field

   "object" contains the OID in dot-notation, prepended by the namespace
   identifier and double colon ("oid:").  This field MUST be present.

3.2.2.2  Object-Section "status" Field

   "status" MUST be present and SHALL be one of the following values:

   (1) "Information available" means that information about the OID is
       fully available.

   (2) "Information partially available" means that part of the
       information about the OID is not available.  Possible reasons
       could be that part of the information is redacted due to
 


Marschall                                                      [Page 19]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


       confidentiality, or the OID-IP service only knows basic
       information, while the full information can be found somewhere
       else (e.g. at a referred OID-IP service).  The field "attribute"
       MAY be used with the value "confidential".

   (3) "Information unavailable" means that the information about the
       OID is missing, redacted due to confidentiality, or otherwise
       unavailable.  The field "attribute" MAY be used with the value
       "confidential".

3.2.2.3  Object-Section "lang" Field

   "lang" (OPTIONAL) contains the language of the fields "name",
   "description", "information", and additional fields if their
   translation makes sense.  The language should be a language tag as
   defined in [RFC5646].

3.2.2.4  Object-Section "name" Field

   "name" (OPTIONAL) contains the name of the OID.  It SHOULD be as
   short as possible.

3.2.2.5  Object-Section "description" Field

   "description" (OPTIONAL) contains a short description of the OID. 
   The description SHOULD only be a single sentence.

3.2.2.6  Object-Section "information" Field

   "information" (OPTIONAL) contains additional information, e.g.
   Management Information Base (MIB) definitions.

3.2.2.7  Object-Section "url" Field

   "url" (OPTIONAL, multiple values allowed) contains a URL (as defined
   in RFC 3986 [RFC3986]) leading to more information about the OID.

3.2.2.8  Object-Section "asn1-notation" Field

   "asn1-notation" (OPTIONAL, multiple values allowed) contains one or
   more possible notations in the ASN.1 syntax, as defined in
   Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 32.3
   [X680], e.g. {joint-iso-itu-t(2) example(999)}.

   Note: A line break, to break up lines that are too long, as defined
   in section 3.1 ("Format and Encoding") SHOULD be used.  This is no
   problem because multiple ASN.1 notations can be distinguished by
   their opening curly bracket and their closing curly bracket.
 


Marschall                                                      [Page 20]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


3.2.2.9  Object-Section "iri-notation" Field

   "iri-notation" (OPTIONAL, multiple values allowed) contains one or
   more possible notations in the OID-IRI syntax, as defined in
   Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 34.3
   [X680] (but without quotation marks), e.g. /Joint-ISO-ITU-T/Example.

   Note: A line break, to break up lines that are too long, as defined
   in section 3.1 ("Format and Encoding") SHALL NOT be used, otherwise,
   it would be ambiguous if the line break was used to shorten the line,
   or if the line break indicates a new value in case multiple OID-IRI
   notations are supplied.

3.2.2.10  Object-Section "identifier" Field

   "identifier" (OPTIONAL, multiple values allowed) contains an
   alphanumeric identifier ("NameForm") as defined in Recommendation
   ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 12.3 [X680].

3.2.2.11  Object-Section "standardized-id" Field

   "standardized-id" (OPTIONAL, multiple values allowed) contains an
   alphanumeric identifier that has a standardized "NameForm", i.e. in
   ASN.1 notation, it can be written without its associated number.  See
   more information in Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-
   1:2015, clause 32.7 [X680].

3.2.2.12  Object-Section "unicode-label" Field

   "unicode-label" (OPTIONAL, multiple values allowed) contains a Non-
   integer Unicode label, as defined in Recommendation ITU-T X.680
   (2015) | ISO/IEC 8824-1:2015, clause 12.27 [X680].

3.2.2.13  Object-Section "long-arc" Field

   "long-arc" (OPTIONAL, multiple values allowed) contains a Non-integer
   Unicode label that can be used as the first identifier in an OID
   Internationalized Resource Identifier (OID-IRI), shortening it.  More
   information can be found in Recommendation ITU-T X.660 (2011) |
   ISO/IEC 9834-1:2012, clause 3.5.8 [X660].








 


Marschall                                                      [Page 21]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


3.2.2.14  Object-Section "oidip-service" Field

   "oidip-service" (OPTIONAL, multiple values allowed) contains the
   address of a system that offers an OID-IP service that can supply
   information about the OID and/or its subordinate OIDs.

   For a HTTP(S) service, the value MUST be a URI with trailing path
   delimiter (e.g. https://example.com/oidip/).  For a WHOIS service,
   the value MUST be an IP address or hostname, followed by a double-
   colon (:) and a port number (e.g. oidip.example.com:43). Multiple
   values are allowed.  If the server accepts both the HTTP(S) protocol
   and the WHOIS protocol, then it is RECOMMENDED to present both
   services (two "oidip-service" lines).

   If the result is "Found" (i.e. the OID is existing in the local
   database), then the information "oidip-service" is only
   informational; its existence is most likely a hint that subordinate
   OIDs will be found at that OID-IP server.  If the result is "Not
   found; superior object found", then the client SHOULD query the
   referred OID-IP server to receive more information about the OID. 
   See more information in section 4 "Referral".

3.2.2.15  Object-Section "oidip-pubkey" Field

   "oidip-pubkey" (OPTIONAL, multiple values allowed) contains one or
   more valid public keys of the services that are identified in "oidip-
   service" if they use signatures (see section 3.3 "Digital
   Signature").

3.2.2.16  Object-Section "attribute" Field

   "attribute" (OPTIONAL, multiple values allowed) contains attributes
   of the OID.  An attribute MUST be one of the following values:

   (1) "confidential" means that information about the OID or part of it
       is confidential.

   (2) "draft" means that the allocation of the OID is not yet official
       and the information is subject to change without notice.  This
       includes deletion and relocation.

   (3) "frozen" means that no more child OIDs can be created under this
       OID, e.g. because the RA has stopped operating, but the existing
       child OIDs stay valid.

   (4) "leaf" means that no child OIDs can be allocated under this OID. 
       The field "subordinate" SHALL therefore not be present.

 


Marschall                                                      [Page 22]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   (5) "no-identifiers" means that the RA is not allocating alphanumeric
       identifiers.

   (6) "no-unicode-labels" means that the RA is not allocating Non-
       integer Unicode labels.

   (7) "retired" means that the OID is withdrawn, revoked, retired,
       expired, etc.  Please consult Recommendation ITU-T X.660 (2011) |
       ISO/IEC 9834-1:2012 [X660] for more information about such cases.

3.2.2.17  Object-Section "parent" Field

   "parent" (OPTIONAL) contains the OID of the nearest known parent OID,
   prepended by namespace identifier and double colon, i.e. "oid:".  It
   MAY be followed by additional human-readable information, e.g. a
   description or a list of ASN.1 identifiers.  There SHALL be at least
   1 whitespace in between.

3.2.2.18  Object-Section "subordinate" Field

   "subordinate" (OPTIONAL, multiple values allowed) contains a list of
   subordinate OIDs, prepended by namespace identifier and double colon,
   i.e. "oid:".  It MAY be followed by additional human-readable
   information, e.g. a description or a list of ASN.1 identifiers. 
   There SHALL be at least 1 whitespace in between.

3.2.2.19  Object-Section "created" Field

   "created" (OPTIONAL) contains the date and time (as specified in
   section 3.4 "Date/Time Format") when the OID was first allocated by
   the RA of the superior OID.

3.2.2.20  Object-Section "updated" Field

   "updated" (OPTIONAL) contains the date and time (as specified in
   section 3.4 "Date/Time Format") when the OID information was last
   updated.

3.2.2.21  Object-Section Other Fields

   Additional fields for the Object section can be defined by the OID-IP
   service.  The field names SHALL only consist of the lower-case
   letters "a..z", hyphens ("-"), and numbers, and SHOULD be written in
   the English language.  The field name MUST NOT begin or end with a
   hyphen and a hyphen MUST NOT be followed by another hyphen.



 


Marschall                                                      [Page 23]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


3.2.3  RA-Section (Information about the Current RA)

   This section MUST NOT be present if the result is "Not found" or
   "Service error", otherwise it MAY be present.  If it is present, it
   MUST start with the field "ra".

   Possible fields are:

3.2.3.1  RA-Section "ra" Field

   "ra" contains a general name of the RA, like the name of a person,
   the name of a group, or the name of an organization.  This field MUST
   be present.

3.2.3.2  RA-Section "ra-status" Field

   "ra-status" MUST be present and SHALL be one of the following values:

   (1) "Information available" means that information about this RA is
       fully available.

   (2) "Information partially available" means that part of the
       information is not available.  A possible reason could be that
       part of the information is redacted due to confidentiality.  The
       field "attribute" MAY be used with the value "confidential".

   (3) "Information unavailable" means that the data is missing (if the
       OID-IP service only knows the name of the RA and nothing else),
       redacted due to confidentiality, or otherwise unavailable.  The
       field "attribute" MAY be used with the value "confidential".

3.2.3.3  RA-Section "ra-lang" Field

   "ra-lang" (OPTIONAL) contains the language of the fields in this
   section, if their translation makes sense.  The language should be a
   language tag as defined in [RFC5646].

3.2.3.4  RA-Section "ra-contact-name" Field

   "ra-contact-name" (OPTIONAL, multiple values allowed) contains the
   name of a person responsible for the allocation of subordinate OIDs,
   in case "ra" is a group or organization.

3.2.3.5  RA-Section "ra-address" Field

   "ra-address" (OPTIONAL) contains the physical location of the RA. 
   While a fully qualified postal address is recommended, the field can
   also just contain a rough location like city and country name, state
 


Marschall                                                      [Page 24]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   and country name, or just the country name, etc.  The name of the
   country SHOULD always be present.

3.2.3.6  RA-Section "ra-phone" Field

   "ra-phone" (OPTIONAL, multiple values allowed) contains a landline
   phone number of the Registration Authority.  It SHOULD be written in
   the international number format specified in Recommendation ITU-T
   E.164 (2010) [E164], e.g. +1 206 555 0100.

3.2.3.7  RA-Section "ra-mobile" Field

   "ra-mobile" (OPTIONAL, multiple values allowed) contains a mobile
   phone number of the Registration Authority.  It SHOULD be written in
   the international number format specified in Recommendation ITU-T
   E.164 (2010) [E164], e.g. +1 206 555 0100.

3.2.3.8  RA-Section "ra-fax" Field

   "ra-fax" (OPTIONAL, multiple values allowed) contains a fax number of
   the Registration Authority.  It SHOULD be written in the
   international number format specified in Recommendation ITU-T E.164
   (2010) [E164], e.g. +1 206 555 0100.

3.2.3.9  RA-Section "ra-email" Field

   "ra-email" (OPTIONAL, multiple values allowed) contains an email
   address of the Registration Authority.

3.2.3.10  RA-Section "ra-url" Field

   "ra-url" (OPTIONAL, multiple values allowed) contains a URL (as
   defined in RFC 3986 [RFC3986]) leading to more information about the
   RA (usually the website of the RA).

3.2.3.11  RA-Section "ra-attribute" Field

   "ra-attribute" (OPTIONAL, multiple values allowed) contains
   attributes of the RA.  An attribute MUST be one of the following
   values:

   (1) "confidential" means that the information about the RA or part of
       it is confidential.

   (2) "retired" means that the RA is defunct.  If this attribute is set
       to the current RA, then the OID MUST have the attribute "frozen"
       (until the responsibility is transferred to a non-defunct RA, or
       until the current RA becomes active again).
 


Marschall                                                      [Page 25]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


3.2.3.12  RA-Section "ra-created" Field

   "ra-created" (OPTIONAL) contains the date and time (as specified in
   section 3.4 "Date/Time Format") when the RA was created/registered in
   the database.

3.2.3.13  RA-Section "ra-updated" Field

   "ra-updated" (OPTIONAL) contains the date and time (as specified in
   section 3.4 "Date/Time Format") when the RA information was last
   modified.

3.2.3.14  RA-Section Other Fields

   Additional fields for the RA section can be defined by the OID-IP
   service, but they MUST begin with "ra-".  The field names SHALL only
   consist of the lower-case letters "a..z", hyphens ("-"), and numbers,
   and SHOULD be written in the English language.  The field name MUST
   NOT begin or end with a hyphen and a hyphen MUST NOT be followed by
   another hyphen.

3.2.4  Sections for Previous Registration Authorities

   To optionally display information about RAs that were previously in
   charge of managing the OID, a new section per RA can be added with
   the following field name prefixes:

   "ra-" is the prefix of the current Registration Authority,
   "ra1-" is the prefix of the first RA.  It is the very first person or
   company to whom the OID was allocated by the RA of the superior OID,
   "ra2-" is the prefix of the second RA, after the responsibility has
   been transferred, etc.

   Each section MUST start with the field "ra1", "ra2", etc.

   The definition of these sections is identical to the definition of
   the RA-Section (described in section 3.2.3 "RA-Section"), just with a
   different prefix.

   The history does not need to be complete, e.g. it is no problem to
   only serve information about the first ("ra1") and the current RA
   ("ra"), or only serve information about the current RA ("ra").






 


Marschall                                                      [Page 26]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


3.3  Digital Signature

3.3.1  "text" Format

   If integrity/authenticity is required, the whole response can be
   signed, e.g. by using PGP, RSA, ECDSA, etc.  Depending on the
   signature method being used, various things need to be appended
   and/or prepended to the response (e.g. "-----BEGIN PGP MESSAGE-----"
   and "-----END PGP MESSAGE-----").  These additional lines MUST be
   prepended by a percent sign ("%") to avoid an application confusing
   these additional lines (e.g. lines belonging to a PGP header, as
   defined in RFC 4880 [RFC4880]) with parts of the actual OID-IP
   response.

3.3.2  "json" Format

   Steps for signing a message:

   (1) Make sure that the JSON file has no signature (remove the
       "signature" key if one exists).

   (2) Create a working-copy of the JSON file and canonize the contents
       using the procedures described in RFC 8785 [RFC8785].

   (3) Create a JSON Web Signature (JWS, RFC 7515 [RFC7515]) using your
       public key and the canonized form of the JSON contents.

   (4) Add the signature in the "signature" field to the original JSON
       file.  Note that the original JSON does not need to be canonized,
       since the canonization will be repeated in the verification
       procedure.

   Steps for verifying a message:

   (1) Extract the contents of the "signature" key from the JSON file. 
       This is the JSON Web Signature containing a header, a payload,
       and a signature.

   (2) Create a working-copy of the JSON file and remove the "signature"
       key there.

   (3) Canonize the remaining contents using the procedures described in
       RFC 8785 [RFC8785].

   (4) Compare the canonized contents to the base64-encoded payload of
       the JSON Web Signature which was extracted before.  The contents
       MUST be equal.

 


Marschall                                                      [Page 27]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   (5) Verify the JSON Web Signature of the original JSON file according
       to the procedures described in RFC 7515 [RFC7515].

3.3.3  "xml" Format

   Signing and verifying signatures will be performed as described in
   the W3C Recommendation "XML Signature Syntax and Processing"
   ([XMLDSig]).

3.4  Date/Time Format

   Date/Time references SHALL be formatted as described in
   section 3.4.1.

   If parts of the date/time reference are uncertain, then they SHOULD
   be omitted until the date/time reference has the highest correctness.

   Examples of valid date/time references can be found in section 3.4.2.

3.4.1  Date/Time Format ABNF Notation

   To define the format of a Date/Time reference, the following
   Augmented BNF definitions will be used.  They are based on the ABNF
   styles of RFC 5234 [RFC5234].

   date-time = year [ "-" month [ "-" day [ " " time ] ] ]

   year      = 4DIGIT

   month     = ( "0" %x31-39 ) /
               ( "1" %x30-32 )      ; 01-12

   day       = ( "0" %x31-39 ) /
               ( "1" %x30-39 ) /
               ( "2" %x30-39 ) /
               ( "3" %x30-31 )      ; 01-31

   time      = hour ":" minute [ ":" second ] [ " " timezone ]

   hour      = ( "0" %x30-39 ) /
               ( "1" %x30-39 ) /
               ( "2" %x30-33 )      ; 00-23

   minute    = %x30-35 DIGIT        ; 00-59

   second    = %x30-35 DIGIT        ; 00-59

   timezone  = ( "+" / "-" ) hour minute
 


Marschall                                                      [Page 28]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


3.4.2  Date/Time Format Examples

   Examples of valid date/time references are:

       2025-01-23 18:32:00 +0200
       2025-01-23 18:32:00
       2025-01-23 18:32 +0200
       2025-01-23 18:32
       2025-01-23
       2025-01
       2025

3.5  HTTP Response Status Codes

   For the HTTP transmission, there are the following requirements based
   on the result of the query defined in section 3.2.1:

   (1) If the result is "Found", then the HTTP(S) Response Code MUST be
       "200 OK".

   (2) If the result is "Not found; superior object found", then the
       HTTP(S) Response Code MUST be "470 Not Found - Superior Object
       Found".

   (3) If the result is "Not found", then the HTTP(S) Response Code MUST
       be "404 Not Found".

   (4) If the result is "Service Error", then the HTTP(S) Response Code
       MUST be in the range 400, 402, 405-469, 471-499, and 500-599. 
       Examples for fitting response codes are "400 Bad Request", "429
       Too Many Requests", or "500 Internal Server Error".

   (5) If the response contains a referral server (field "oidip-
       service"), then the HTTP(S) Response Code MUST NOT be a 3xx
       redirection status code.

   (6) While the 3xx redirection status code MUST NOT indicate an OID-IP
       referral as specified by section 4, the 3xx redirection status
       codes may be used if the OID-IP service itself moves, e.g. to a
       different hostname.  In this case, the client MUST follow the
       location.

   (7) Response codes 401 and 403 MUST NOT be used to indicate that
       information is partially redacted or fully unavailable due to
       missing authorization.



 


Marschall                                                      [Page 29]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   3.6  HTTP Response Headers

   Besides the usual response headers, the response SHOULD contain the
   "Content-Language" response header to indicate the language of the
   content.











































 


Marschall                                                      [Page 30]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


4  Referral

   By using the fields "oidip-service" and "oidip-pubkey", the OID-IP
   service can instruct the client to query another OID-IP service that
   might have more information about the requested OID.

   If Registration Authorities maintain up-to-date OID-IP service
   references of their OID delegations, it is possible to automatically
   retrieve information about any OID.

   Example: OID "2.999" is owned by Registration Authority "A",
   operating an OID-IP service at "a.example.com".

   Registration Authority "A" allocated OID "2.999.1000" to Registration
   Authority "B" who is operating an OID-IP service at "b.example.com".

   The client asks a.example.com for information about OID
   "2.999.1000.1" and should receive the following reply:

       query:          oid:2.999.1000.1
       result:         Not found; superior object found
       distance:       1

       object:         oid:2.999.1000
       status:         Information available
       name:           Company "B"
       oidip-service:  b.example.com:43

       ra:             "B"
       ra-status:      Information unavailable

   The client is now aware that "a.example.com" only knows OID
   "2.999.1000", and that there is a reference to another OID-IP service
   located at "b.example.com".  So, the client should then accordingly
   query "b.example.com", asking for information about OID
   "2.999.1000.1":

       query:          oid:2.999.1000.1
       result:         Found

       object:         oid:2.999.1000.1
       status:         Information available
       name:           Example OID 1

       ra:             "B"
       ra-status:      Information unavailable


 


Marschall                                                      [Page 31]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


5  Full Example ("text" Format)
5.1  Request

   HTTP(S):   https://oidip.example.com/oid/2.999/text
   WHOIS:     oid:2.999

5.2  Response

   query:          oid:2.999
   result:         Found

   object:         oid:2.999
   status:         Information available
   lang:           en-US
   name:           Example
   description:    This OID can be used by anyone, for the purposes of
   description:    documenting examples of Object Identifiers.
   asn1-notation:  {joint-iso-itu-t(2) example(999)}
   iri-notation:   /Example
   identifier:     example
   unicode-label:  Beispiel
   unicode-label:  Ejemplo
   unicode-label:  Example
   unicode-label:  Exemple
   unicode-label:  (Korean characters are omitted in this example)
   unicode-label:  (Arabian characters are omitted in this example)
   unicode-label:  (Japanese characters are omitted in this example)
   unicode-label:  (Chinese characters are omitted in this example)
   unicode-label:  (Russian characters are omitted in this example)
   long-arc:       Beispiel
   long-arc:       Ejemplo
   long-arc:       Example
   long-arc:       Exemple
   long-arc:       (Korean characters are omitted in this example)
   long-arc:       (Arabian characters are omitted in this example)
   long-arc:       (Japanese characters are omitted in this example)
   long-arc:       (Chinese characters are omitted in this example)
   long-arc:       (Russian characters are omitted in this example)
   parent:         oid:2 (joint-iso-itu-t)
   created:        2011-06
   updated:        2011-09

   ra:             ITU-T SG 17 & ISO/IEC JTC 1/SC 6
   ra-status:      Information unavailable
   % -----BEGIN RSA SIGNATURE-----
   % DwnqRtx/ONtPh4onXnrZPl9jF+G50RMLZkSwuClaoH2t/yK8CnYJrmzkzA5+gkfWkoQ
   % cq+J8J9cvnwXvBfpVHg==
   % -----END RSA SIGNATURE-----
 


Marschall                                                      [Page 32]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


6  Alternative Namespaces

   This document describes the retrieval of information about OIDs using
   the OID-IP protocol.  In addition to the OID namespace, the methods
   described in this document can also be applied to other namespaces
   like "uuid", "isbn", "gtin", etc.

   The following things need to be considered if alternative namespaces
   are implemented:

   (1) The request MUST be UTF-8 encoded (as defined in RFC 3629
       [RFC3629]), without Byte-Order-Mark (BOM).

   (2) The namespace SHALL be a namespace identifier (NID) as defined in
       RFC 8141 [RFC8141].

   (3) The namespace identifier SHALL be written in lower-case (this is
       already defined in section 2 "Request").

   (4) If available, a formal URN namespace identifier (as defined in
       RFC 8141, section 5.1 [RFC8141]) SHOULD be used, e.g. "uuid"
       should be used instead of "guid".

   (5) If things like "Owner", "Creator", "Manager", "Administrator",
       etc., are applicable to the identifiers in the namespace, then
       the RA-section as described in section 3.2.3 SHALL be used, even
       though the word "Registration Authority" might not be appropriate
       in the terminology of the namespace.

   (6) For WHOIS requests, the namespace-specific identifier MUST NOT
       contain dollar signs ("$"), because section 2.2.1.1 "Input
       Parameters" defines them as a separator for input parameters. 
       For HTTP(S) requests, the namespace-specific identifier MUST NOT
       contain a slash ("/") and MUST NOT be called "root".

   (7) The namespace-specific identifier MUST be treated as case-
       sensitive if the namespace distinguishes between lower-case and
       upper-case.

   (8) Fields that can only be used in the OID namespace (e.g. "unicode-
       label") MUST NOT be used for other namespaces.







 


Marschall                                                      [Page 33]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


6.1  Example: UUID Namespace

   The following example shows the retrieval of information about
   Universally Unique Identifiers (e.g. UUIDs used by the Microsoft
   Common Object Model, also known as GUIDs).  The UUID namespace has no
   hierarchical structure, which means that the OID-IP service can only
   respond with the result "Found", "Not found" or "Service error" and
   the fields "parent" and "subordinate" cannot be used.

   More information about UUIDs can be found in Recommendation ITU-T
   X.667 (2012) | ISO/IEC 9834-8:2014 [X667].

   More information about the Microsoft Common Object Model (COM) can be
   found at Microsoft Docs <https://learn.microsoft.com/en-
   us/windows/win32/com/component-object-model--com--portal>.

6.1.1  Request

   HTTP(S):   https://oidip.example.com/uuid/\
   b4bfcc3a-db2c-424c-b029-7fe99a87c641/text
   WHOIS:     uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641

6.1.2  Response

   query:        uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641
   result:       Found

   object:       uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641
   status:       Information available
   lang:         en-US
   name:         Desktop
   information:  GUID can be used in file dialogs as "Custom Place".

   ra:           Microsoft Corp.
   ra-status:    Information unavailable

7  Internationalization Considerations

   This document specifies that the request and response MUST be UTF-8
   encoded (as defined in RFC 3629 [RFC3629]), without Byte-Order-Mark
   (BOM).

   The OID-IP service can define additional field names, but they SHOULD
   be written in the English language so that there is consistency with
   the field names defined in this document.



 


Marschall                                                      [Page 34]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


8  Security Considerations

   (1) The knowledge of the existence of an OID, or information about
       some OIDs could be considered confidential.  In this case, the
       OID-IP service can either deny the existence of the requested OID
       (by setting the result to "Not found") or redact information in
       the Object-Section, as defined in section 3.2.2 "Object-Section".

   (2) Registration Authorities might demand that their data be kept
       confidential, or at least be partially redacted to increase
       privacy or as a measurement against spam.  In this case, the OID-
       IP service can redact information in the RA-Section, as defined
       in section 3.2.3 "RA-Section".

   (3) The OID-IP service can decide if confidential material is omitted
       or shown, based on authentication mechanisms like white-listing
       client IP addresses or by using authentication tokens supplied by
       the client during the request, as defined in section 2.1.3
       "Authentication" and section 2.2.3 "Authentication Tokens".

   (4) Unless HTTPS is used, the usage of authentication tokens or
       transmitting confidential information is not recommended if the
       traffic between client and server is transmitted through an
       untrusted network.

   (5) Authentication tokens must have a sufficient length and
       complexity to avoid successful brute force attacks, or the OID-IP
       service must limit the number of requests per time.

   (6) Like for passwords, the authentication token should be unique and
       not be used for any other purpose, e.g. as online account
       password.

   (7) Based on the client software, authentication tokens might be
       saved in the history, which might be a security risk.  For
       example, the browser history (if authentication tokens are sent
       as HTTP(S) GET parameter, or in the command-line history if the
       authentication token has been sent via command-line).

   (8) If integrity/authenticity is required, the OID-IP response can be
       signed, as described in section 3.3 "Digital Signature".







 


Marschall                                                      [Page 35]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


9  RA Considerations

   OID:  1.3.6.1.4.1.37476.3.5.10
   WEID: weid:pen:SX0-3-5-A-6
   ASN1: { iso(1) identified-organization(3) dod(6) internet(1)
   private(4) enterprise(1) 37476 specifications(3)
   communication(5) oid-ip(10) }
   IRI:  /.../Specifications/Communication/OID-IP




10  References

10.1  Normative References

   [E164]     "The international public telecommunication numbering
              plan", Recommendation ITU-T E.164 (2010), November 2010,
              <http://handle.itu.int/11.1002/1000/10688>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3061]  Mealling, M., "A URN Namespace of Object Identifiers",
              RFC 3061, DOI 10.17487/RFC3061, February 2001,
              <https://www.rfc-editor.org/info/rfc3061>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
              November 2003,
              <https://www.rfc-editor.org/info/rfc3629>.

   [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI
              10.17487/RFC3912, September 2004,
              <https://www.rfc-editor.org/info/rfc3912>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

 


Marschall                                                      [Page 36]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   [RFC5646]  Phillips, A., Ed., and M. Davis, Ed., "Tags for
              Identifying Languages", BCP 47, RFC 5646,
              DOI 10.17487/RFC5646, September 2009,
              <https://www.rfc-editor.org/info/rfc5646>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
              May 2015,
              <https://www.rfc-editor.org/info/rfc7515>.

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <https://www.rfc-editor.org/info/rfc8141>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

   [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
              "Handling Long Lines in Content of Internet-Drafts and
              RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
              <https://www.rfc-editor.org/info/rfc8792>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC7230]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022,
              <https://www.rfc-editor.org/info/rfc9112>.

   [X660]     "Information technology - Procedures for the operation of
              object identifier registration authorities: General
              procedures and top arcs of the international object
              identifier tree", Recommendation ITU-T X.660 (2011) |
              ISO/IEC 9834-1:2012, July 2011,
              <http://handle.itu.int/11.1002/1000/11336>.



 


Marschall                                                      [Page 37]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   [X680]     "Information technology - Abstract Syntax Notation One
              (ASN.1): Specification of basic notation", Recommendation
              ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, August 2015,
              <http://handle.itu.int/11.1002/1000/12479>.

   [XML]      "Extensible Markup Language (XML) 1.1 (Second Edition)"
              W3C Recommendation 16 August 2006, edited in place
              29 September 2006,
              <https://www.w3.org/TR/2006/REC-xml11-20060816/>.

   [XMLDSig]  "XML Signature Syntax and Processing Version 1.1"
              W3C Recommendation 11 April 2013,
              <https://www.w3.org/TR/xmldsig-core1/>.

   [XSD]      W3C XML Schema Definition Language (XSD)
              W3C Recommendation 5 April 2012,
              <https://www.w3.org/TR/xmlschema11-1/>.

   [JSONSch]  JSON Schema Specification
              <https://json-schema.org/specification.html>.


10.2  Informative References

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol (SNMP)", RFC 1157,
              DOI 10.17487/RFC1157, May 1990,
              <https://www.rfc-editor.org/info/rfc1157>.

   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
              Protocol (LDAP): The Protocol", RFC 4511,
              DOI 10.17487/RFC4511, June 2006,
              <https://www.rfc-editor.org/info/rfc4511>.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880,
              DOI 10.17487/RFC4880, November 2007,
              <https://www.rfc-editor.org/info/rfc4880>.

   [X509]     "Information technology - Open Systems Interconnection -
              The Directory: Public-key and attribute certificate
              frameworks", Recommendation ITU-T X.509 (2016) |
              ISO/IEC 9594-8:2017, October 2016,
              <http://handle.itu.int/11.1002/1000/13031>.




 


Marschall                                                      [Page 38]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


   [X667]     "Information technology - Procedures for the operation of
              object identifier registration authorities: Generation of
              universally unique identifiers and their use in object
              identifiers", Recommendation ITU-T X.667 (2012) |
              ISO/IEC 9834-8:2014, October 2012,
              <http://handle.itu.int/11.1002/1000/11746>.

   [X672]     "Information technology - Open systems interconnection -
              Object identifier resolution system",
              Recommendation ITU-T X.672 (2010) | ISO/IEC 29168-1:2011,
              August 2010,
              <http://handle.itu.int/11.1002/1000/10831>.




































 


Marschall                                                      [Page 39]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


Appendix A.  JSON Format Schema and Example

Appendix A.1.  JSON Format Schema

The following JSON Schema ([JSONSch]) defines the expected output the
server sends if the argument "format" is set to "json".

NOTE: '\' line wrapping per RFC 8792  [RFC8792]

<CODE BEGINS> file "viathinksoft-std-0002-oidip.json"
{
  "$id":"urn:x-viathinksoft:std:0002:2024-09-02:json-schema",
  "$schema":"https://json-schema.org/draft/2020-12/schema",
  "type":"object",
  "properties":{
    "oidip":{
      "type":"object",
      "properties":{
        "querySection":{
          "type":"object",
          "properties":{
            "query":{
              "$ref": "#/$defs/inputQueryType"
            },
            "result":{
              "type":"string",
              "enum":["Found",
                      "Not found; superior object found",
                      "Not found",
                      "Service error"]
            },
            "distance":{
              "type":"integer"
            },
            "message":{
              "type":"string"
            },
            "lang":{
              "type":"string"
            }
          },
          "required":[
            "query",
            "result"
          ]
        },
        "objectSection":{
          "type":"object",
 


Marschall                                                      [Page 40]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


          "properties":{
            "object":{
              "$ref": "#/$defs/inputQueryType"
            },
            "status":{
              "type":"string",
              "enum":["Information available",
                      "Information partially available",
                      "Information unavailable"]
            },
            "lang":{
              "type":"string"
            },
            "name":{
              "type":"string"
            },
            "description":{
              "type":"string"
            },
            "information":{
              "type":"string"
            },
            "url":{
              "type":"string"
            },
            "asn1-notation":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string"
                  }
                }
              ]
            },
            "iri-notation":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string"
                  }
 


Marschall                                                      [Page 41]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


                }
              ]
            },
            "identifier":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string"
                  }
                }
              ]
            },
            "standardized-id":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string"
                  }
                }
              ]
            },
            "unicode-label":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string"
                  }
                }
              ]
            },
            "long-arc":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
 


Marschall                                                      [Page 42]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


                  "type":"array",
                  "items":{
                    "type":"string"
                  }
                }
              ]
            },
            "oidip-service":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string"
                  }
                }
              ]
            },
            "oidip-pubkey":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string"
                  }
                }
              ]
            },
            "attribute":{
              "oneOf":[
                {
                  "type":"string",
                  "enum":["confidential",
                          "draft",
                          "frozen",
                          "leaf",
                          "no-identifiers",
                          "no-unicode-labels",
                          "retired"]
                },
                {
                  "type":"array",
                  "items":{
 


Marschall                                                      [Page 43]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


                    "type":"string",
                    "enum":["confidential",
                            "draft",
                            "frozen",
                            "leaf",
                            "no-identifiers",
                            "no-unicode-labels",
                            "retired"]
                  }
                }
              ]
            },
            "parent":{
              "type":"string"
            },
            "subordinate":{
              "oneOf":[
                {
                  "type":"string"
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string"
                  }
                }
              ]
            },
            "created":{
              "$ref": "#/$defs/dateTimeRef"
            },
            "updated":{
              "$ref": "#/$defs/dateTimeRef"
            }
          },
          "required":[
            "object",
            "status"
          ]
        },
        "raSection":{
          "type":"object",
          "properties":{
            "ra":{
              "$comment":"Note: \"ra\" keeps its name, even in \
Ra1SectionType et al.",
              "type":"string"
            },
 


Marschall                                                      [Page 44]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


            "status":{
              "type":"string",
              "enum":["Information available",
                      "Information partially available",
                      "Information unavailable"]
            },
            "lang":{
              "type":"string"
            },
            "contact-name":{
              "type":"string"
            },
            "address":{
              "type":"string"
            },
            "phone":{
              "type":"string"
            },
            "mobile":{
              "type":"string"
            },
            "fax":{
              "type":"string"
            },
            "email":{
              "type":"string"
            },
            "url":{
              "type":"string"
            },
            "attribute":{
              "oneOf":[
                {
                  "type":"string",
                  "enum":["confidential",
                          "retired"]
                },
                {
                  "type":"array",
                  "items":{
                    "type":"string",
                    "enum":["confidential",
                            "retired"]
                  }
                }
              ]
            },
            "created":{
 


Marschall                                                      [Page 45]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


              "$ref": "#/$defs/dateTimeRef"
            },
            "updated":{
              "$ref": "#/$defs/dateTimeRef"
            }
          },
          "required":[
            "ra",
            "status"
          ]
        },
        "ra1Section":{"$ref":"#/properties/oidip/properties/raSection"},
        "ra2Section":{"$ref":"#/properties/oidip/properties/raSection"},
        "ra3Section":{"$ref":"#/properties/oidip/properties/raSection"},
        "ra4Section":{"$ref":"#/properties/oidip/properties/raSection"},
        "ra5Section":{"$ref":"#/properties/oidip/properties/raSection"},
        "ra6Section":{"$ref":"#/properties/oidip/properties/raSection"},
        "ra7Section":{"$ref":"#/properties/oidip/properties/raSection"},
        "ra8Section":{"$ref":"#/properties/oidip/properties/raSection"},
        "ra9Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra10Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra11Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra12Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra13Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra14Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra15Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra16Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra17Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra18Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra19Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra20Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra21Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra22Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra23Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra24Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra25Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra26Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra27Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra28Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra29Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra30Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra31Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra32Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra33Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra34Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra35Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra36Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra37Section":{"$ref":"#/properties/oidip/properties/raSection"},
 


Marschall                                                      [Page 46]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


       "ra38Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra39Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra40Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra41Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra42Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra43Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra44Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra45Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra46Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra47Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra48Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra49Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra50Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra51Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra52Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra53Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra54Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra55Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra56Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra57Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra58Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra59Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra60Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra61Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra62Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra63Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra64Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra65Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra66Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra67Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra68Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra69Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra70Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra71Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra72Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra73Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra74Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra75Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra76Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra77Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra78Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra79Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra80Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra81Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra82Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra83Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra84Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra85Section":{"$ref":"#/properties/oidip/properties/raSection"},
 


Marschall                                                      [Page 47]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


       "ra86Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra87Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra88Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra89Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra90Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra91Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra92Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra93Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra94Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra95Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra96Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra97Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra98Section":{"$ref":"#/properties/oidip/properties/raSection"},
       "ra99Section":{"$ref":"#/properties/oidip/properties/raSection"}
      },
      "required":[
        "querySection"
      ]
    },
    "signature":{
      "type":"string",
      "pattern":"^[A-Za-z0-9+/=]+\\.[A-Za-z0-9+/=]+\\.[A-Za-z0-9+/=]+$"
    }
  },
  "required":[
    "oidip"
  ],
  "$defs":{
    "dateTimeRef":{
      "type":"string",
      "pattern":"^\\d{4}(-(0[1-9]|1[0-2])(-(0[1-9]|1\\d|2\\d|3[0-1])\
( [0-5]\\d:[0-5]\\d(:[0-5]\\d)?( [+-][0-5]\\d[0-5]\\d)?)?)?)?$"
    },
    "inputQueryType":{
      "$comment":"Note: The ABNF definition is more accurate",
      "type":"string",
      "pattern":"^[a-z0-9]+:(.*)$"
    }
  }
}
<CODE ENDS>







 


Marschall                                                      [Page 48]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


Appendix A.2.  JSON Format Example of Output

NOTE: '\' line wrapping per RFC 8792  [RFC8792]

<CODE BEGINS> file "oidip_example.json"
{
  "$schema":"urn:x-viathinksoft:std:0002:2024-09-02:json-schema",
  "oidip": {
    "querySection": {
      "query": "oid:2.999",
      "result": "Found"
    },
    "objectSection": {
      "object": "oid:2.999",
      "status": "Information available",
      "lang": "en-US",
      "name": "Example",
      "description": "This OID can be used by anyone, for the \
purposes of documenting examples of Object Identifiers.",
      "asn1-notation": "{joint-iso-itu-t(2) example(999)}",
      "iri-notation": "/Example",
      "identifier": "example",
      "unicode-label": [
            "Beispiel",
            "Ejemplo",
            "Example",
            "Exemple",
            "(Korean characters are omitted in this example)",
            "(Arabian characters are omitted in this example)",
            "(Japanese characters are omitted in this example)",
            "(Chinese characters are omitted in this example)",
            "(Russian characters are omitted in this example)"
      ],
      "long-arc": [
            "Beispiel",
            "Ejemplo",
            "Example",
            "Exemple",
            "(Korean characters are omitted in this example)",
            "(Arabian characters are omitted in this example)",
            "(Japanese characters are omitted in this example)",
            "(Chinese characters are omitted in this example)",
            "(Russian characters are omitted in this example)"
      ],
      "parent": "oid:2 (joint-iso-ccitt, joint-iso-itu-t)",
      "subordinate": [],
      "created": "2011-06",
      "updated": "2020-09"
 


Marschall                                                      [Page 49]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


    },
    "raSection": {
      "ra": "ITU-T SG 17 & ISO/IEC JTC 1/SC 6",
      "status": "Information unavailable"
    }
  },
  "signature": "(JSON Web Signature here)"
}
<CODE ENDS>







































 


Marschall                                                      [Page 50]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


Appendix B.  XML Format Schema and Example

Appendix B.1.  XML Format Schema

The following XML Schema Definition ([XSD]) defines the expected output
the server sends if the argument "format" is set to "xml".

NOTE: '\' line wrapping per RFC 8792  [RFC8792]

<CODE BEGINS> file "viathinksoft-std-0002-oidip.xsd"
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
           xmlns:ns1="urn:x-viathinksoft:std:0002:2024-09-02:\
xml-schema"
           targetNamespace="urn:x-viathinksoft:std:0002:2024-09-02:\
xml-schema"
           elementFormDefault="qualified"
           attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
           schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig\
-core-20020212/xmldsig-core-schema.xsd"/>

  <xs:element name="root">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="oidip" minOccurs="1" maxOccurs="1"
                    type="ns1:OidIpType"/>
        <xs:element minOccurs="0" maxOccurs="1"
                    ref="ds:Signature"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:complexType name="OidIpType">
    <xs:sequence>
      <xs:element name="querySection" minOccurs="1" maxOccurs="1"
                  type="ns1:QuerySectionType"/>
      <xs:element name="objectSection" minOccurs="0" maxOccurs="1"
                  type="ns1:ObjectSectionType"/>
      <xs:element name="raSection" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra1Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra2Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra3Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
 


Marschall                                                      [Page 51]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


      <xs:element name="ra4Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra5Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra6Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra7Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra8Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra9Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra10Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra11Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra12Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra13Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra14Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra15Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra16Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra17Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra18Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra19Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra20Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra21Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra22Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra23Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra24Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra25Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra26Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra27Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
 


Marschall                                                      [Page 52]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


      <xs:element name="ra28Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra29Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra30Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra31Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra32Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra33Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra34Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra35Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra36Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra37Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra38Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra39Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra40Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra41Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra42Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra43Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra44Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra45Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra46Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra47Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra48Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra49Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra50Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra51Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
 


Marschall                                                      [Page 53]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


      <xs:element name="ra52Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra53Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra54Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra55Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra56Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra57Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra58Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra59Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra60Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra61Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra62Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra63Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra64Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra65Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra66Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra67Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra68Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra69Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra70Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra71Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra72Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra73Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra74Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra75Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
 


Marschall                                                      [Page 54]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


      <xs:element name="ra76Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra77Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra78Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra79Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra80Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra81Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra82Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra83Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra84Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra85Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra86Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra87Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra88Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra89Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra90Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra91Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra92Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra93Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra94Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra95Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra96Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra97Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra98Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
      <xs:element name="ra99Section" minOccurs="0" maxOccurs="1"
                  type="ns1:RaSectionType"/>
 


Marschall                                                      [Page 55]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


      <xs:any     namespace="##other" minOccurs="0"
                  maxOccurs="unbounded" processContents="lax"/>
    </xs:sequence>
  </xs:complexType>

  <xs:simpleType name="DateTimeRef">
    <xs:restriction base="xs:string">
      <xs:pattern value="\d{4}(-(0[1-9]|1[0-2])(-(0[1-9]|1\d|2\d|3[0-\
1])( [0-5]\d:[0-5]\d(:[0-5]\d)?( [+-][0-5]\d[0-5]\d)?)?)?)?"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="QuerySectionType">
    <xs:sequence>
      <xs:element name="query" minOccurs="1" maxOccurs="1"
                  type="ns1:InputQueryType"/>
      <xs:element name="result" minOccurs="1" maxOccurs="1"
                  type="ns1:QueryResultEnumType"/>
      <xs:element name="distance" minOccurs="0" maxOccurs="1"
                  type="xs:integer"/>
      <xs:element name="message" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="lang" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:any     namespace="##other" minOccurs="0"
                  maxOccurs="unbounded" processContents="lax"/>
    </xs:sequence>
  </xs:complexType>

  <xs:simpleType name="InputQueryType">
    <xs:restriction base="xs:string">
      <!-- Note: The ABNF definition is more accurate -->
      <xs:pattern value="[a-z0-9]+:(.*)"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="QueryResultEnumType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Found"/>
      <xs:enumeration value="Not found; superior object found"/>
      <xs:enumeration value="Not found"/>
      <xs:enumeration value="Service error"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="ObjectSectionType">
    <xs:sequence>
      <xs:element name="object" minOccurs="1" maxOccurs="1"
 


Marschall                                                      [Page 56]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


                  type="ns1:ObjectIdType"/>
      <xs:element name="status" minOccurs="1" maxOccurs="1"
                  type="ns1:ObjectStatusEnumType"/>
      <xs:element name="lang" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="name" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="description" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="information" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="url" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="asn1-notation" minOccurs="0"
                  maxOccurs="unbounded" type="xs:string"/>
      <xs:element name="iri-notation" minOccurs="0"
                  maxOccurs="unbounded" type="xs:string"/>
      <xs:element name="identifier" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="standardized-id" minOccurs="0"
                  maxOccurs="unbounded" type="xs:string"/>
      <xs:element name="unicode-label" minOccurs="0"
                  maxOccurs="unbounded" type="xs:string"/>
      <xs:element name="long-arc" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="oidip-service" minOccurs="0"
                  maxOccurs="unbounded" type="xs:string"/>
      <xs:element name="oidip-pubkey" minOccurs="0"
                  maxOccurs="unbounded" type="xs:string"/>
      <xs:any     namespace="##other" minOccurs="0"
                  maxOccurs="unbounded" processContents="lax"/>
      <xs:element name="attribute" minOccurs="0" maxOccurs="unbounded"
                  type="ns1:ObjectAttributeEnumType"/>
      <xs:element name="parent" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="subordinate" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="created" minOccurs="0" maxOccurs="1"
                  type="ns1:DateTimeRef"/>
      <xs:element name="updated" minOccurs="0" maxOccurs="1"
                  type="ns1:DateTimeRef"/>
    </xs:sequence>
  </xs:complexType>

  <xs:simpleType name="ObjectIdType">
    <xs:restriction base="xs:string">
      <!-- Note: The ABNF definition is more accurate -->
      <xs:pattern value="[a-z0-9]+:(.*)"/>
 


Marschall                                                      [Page 57]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="ObjectStatusEnumType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Information available"/>
      <xs:enumeration value="Information partially available"/>
      <xs:enumeration value="Information unavailable"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="ObjectAttributeEnumType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="confidential"/>
      <xs:enumeration value="draft"/>
      <xs:enumeration value="frozen"/>
      <xs:enumeration value="leaf"/>
      <xs:enumeration value="no-identifiers"/>
      <xs:enumeration value="no-unicode-labels"/>
      <xs:enumeration value="retired"/>
    </xs:restriction>
  </xs:simpleType>  

  <xs:complexType name="RaSectionType">
    <xs:sequence>
      <!-- Note: "ra" keeps its name, even in Ra1SectionType et al. -->
      <xs:element name="ra" minOccurs="1" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="status" minOccurs="1" maxOccurs="1"
                  type="ns1:RaStatusEnumType"/>
      <xs:element name="lang" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="contact-name" minOccurs="0" maxOccurs="1"
                  type="xs:string"/>
      <xs:element name="address" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="phone" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="mobile" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="fax" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="email" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:element name="url" minOccurs="0" maxOccurs="unbounded"
                  type="xs:string"/>
      <xs:any     namespace="##other" minOccurs="0"
                  maxOccurs="unbounded" processContents="lax"/>
 


Marschall                                                      [Page 58]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


      <xs:element name="attribute" minOccurs="0"
                  maxOccurs="unbounded" type="ns1:RaAttributeEnumType"/>
      <xs:element name="created" minOccurs="0" maxOccurs="1"
                  type="ns1:DateTimeRef"/>
      <xs:element name="updated" minOccurs="0" maxOccurs="1"
                  type="ns1:DateTimeRef"/>
    </xs:sequence>
  </xs:complexType>

  <xs:simpleType name="RaStatusEnumType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Information available"/>
      <xs:enumeration value="Information partially available"/>
      <xs:enumeration value="Information unavailable"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="RaAttributeEnumType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="confidential"/>
      <xs:enumeration value="retired"/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
<CODE ENDS>






















 


Marschall                                                      [Page 59]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


Appendix B.2.  XML Format Example of Output

NOTE: '\' line wrapping per RFC 8792  [RFC8792]

<CODE BEGINS> file "oidip_example.xml"
<?xml version="1.0"?>
<root xmlns="urn:x-viathinksoft:std:0002:2024-09-02:xml-schema"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="urn:x-viathinksoft:std:0002:2024-09-02:\
xml-schema https://raw.githubusercontent.com/ViaThinkSoft/standards/\
main/viathinksoft-std-0002-oidip.xsd">
<oidip>
  <querySection>
     <query>oid:2.999</query>
     <result>Found</result>
  </querySection>
  <objectSection>
     <object>oid:2.999</object>
     <status>Information available</status>
     <lang>en-US</lang>
     <name>Example</name>
     <description>This OID can be used by anyone, for the \
purposes of documenting examples of Object Identifiers."</description>
     <asn1-notation>{ joint-iso-itu-t(2) example(999) }</asn1-notation>
     <iri-notation>/Example</iri-notation>
     <identifier>example</identifier>
     <unicode-label>Beispiel</unicode-label>
     <unicode-label>Ejemplo</unicode-label>
     <unicode-label>Example</unicode-label>
     <unicode-label>Exemple</unicode-label>
     <unicode-label>(Korean characters are omitted)</unicode-label>
     <unicode-label>(Arabian characters are omitted)</unicode-label>
     <unicode-label>(Japanese characters are omitted)</unicode-label>
     <unicode-label>(Chinese characters are omitted)</unicode-label>
     <unicode-label>(Russian characters are omitted)</unicode-label>
     <long-arc>Beispiel</long-arc>
     <long-arc>Ejemplo</long-arc>
     <long-arc>Example</long-arc>
     <long-arc>Exemple</long-arc>
     <long-arc>(Korean characters are omitted)</long-arc>
     <long-arc>(Arabian characters are omitted)</long-arc>
     <long-arc>(Japanese characters are omitted)</long-arc>
     <long-arc>(Chinese characters are omitted)</long-arc>
     <long-arc>(Russian characters are omitted)</long-arc>
     <parent>oid:2 (joint-iso-ccitt, joint-iso-itu-t)</parent>
     <created>2011-06</created>
     <updated>2020-09"</updated>
  </objectSection>
 


Marschall                                                      [Page 60]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


  <raSection>
     <ra>ITU-T SG 17 &amp; ISO/IEC JTC 1/SC 6</ra>
     <status>Information unavailable</status>
  </raSection>
</oidip>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <ds:SignedInfo>
  <ds:CanonicalizationMethod
     Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
  <ds:SignatureMethod
     Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/>
  <ds:Reference>
  <ds:Transforms>
  <ds:Transform
    Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
  </ds:Transforms>
  <ds:DigestMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>
  <ds:DigestValue>.....</ds:DigestValue>
  </ds:Reference>
  </ds:SignedInfo>
  <ds:SignatureValue>.....</ds:SignatureValue>
</ds:Signature>
</root>
<CODE ENDS>























 


Marschall                                                      [Page 61]

VTS/WF STD. 2           OID Information Protocol        2 September 2024


Acknowledgements

   I would like to thank Olivier Dubuisson for his expertise and help
   regarding all topics of Object Identifiers, and Melanie Wehowski for
   her feedback and input on the OID Information Protocol.

   Thanks to the authors of these free tools which did a very good job
   in validating various contents of this document:

   - "JSON Schema Validator" by Newtonsoft
     https://www.jsonschemavalidator.net/

   - "Free Online XML Validator" by Liquid Technologies
     https://www.liquid-technologies.com/online-xsd-validator

   - Bill's ABNF Parser
     https://tools.ietf.org/tools/bap/abnf.cgi

   - "Grammarly" spell and grammar checker
     https://app.grammarly.com/

   - "regex101" regular expression debugger
     https://regex101.com/

   - IDNITS
     https://author-tools.ietf.org/idnits

   - Title Case Converter
     https://titlecaseconverter.com/

   This document was written in Nroff Internet Draft Editor by 3xA
   Security.
   https://aaa-sec.com/nroffedit/
   https://misc.daniel-marschall.de/patches/nroffedit/ ("year 2020"
   patch)

Authors' Addresses

   Daniel Marschall
   Postfach 11 53
   69243 Bammental
   Germany

   Email: daniel-marschall@viathinksoft.de
   URI:   https://www.viathinksoft.com/






Marschall                                                      [Page 62]