idnits 2.17.1 draft-viathinksoft-oidip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 30, 2022) is 759 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCyyyy' is mentioned on line 968, but not defined == Unused Reference: 'RFC8792' is defined on line 1014, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Marschall 3 Intended Status: Informational ViaThinkSoft 4 Expires: October 1, 2022 March 30, 2022 6 Retrieving information about Object Identifiers 7 using a text-based protocol 8 draft-viathinksoft-oidip-02 10 Abstract 12 This document defines a method for retrieving information about 13 Object Identifiers (OIDs) and their associated Registration 14 Authorities (RAs) using a text-based protocol, in a way that is both 15 human-readable and machine-readable. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 1, 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1 Authentication Tokens . . . . . . . . . . . . . . . . . . . 6 55 2.2 Server Commands . . . . . . . . . . . . . . . . . . . . . . 6 56 2.2.1 "format" command . . . . . . . . . . . . . . . . . . . 7 57 2.3 Request ABNF Notation . . . . . . . . . . . . . . . . . . . 8 58 3 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.1 Format and Encoding . . . . . . . . . . . . . . . . . . . . 9 60 3.1.1 "text" Format . . . . . . . . . . . . . . . . . . . . . 9 61 3.1.2 "json" Format . . . . . . . . . . . . . . . . . . . . . 9 62 3.1.3 "xml" Format . . . . . . . . . . . . . . . . . . . . . . 9 63 3.1.4 "html" Format . . . . . . . . . . . . . . . . . . . . . 9 64 3.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.2.1 Query-Section (Information about Query and Result) . . 10 66 3.2.2 Object-Section (Information about the OID) . . . . . . 11 67 3.2.3 RA-Section (Information about the Current RA) . . . . . 14 68 3.2.4 Sections for Previous Registration Authorities . . . . 16 69 3.3 Digital Signature . . . . . . . . . . . . . . . . . . . . . 16 70 3.4 Date/Time Format . . . . . . . . . . . . . . . . . . . . . 17 71 3.4.1 Date/Time Format ABNF Notation . . . . . . . . . . . . 18 72 3.4.2 Date/Time Format Examples . . . . . . . . . . . . . . . 18 73 4 Referral . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 5 Full Example ("text" Format) . . . . . . . . . . . . . . . . . 20 75 5.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 5.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 6 Alternative Namespaces . . . . . . . . . . . . . . . . . . . . 21 78 6.1 Example: UUID Namespace . . . . . . . . . . . . . . . . . . 22 79 7 Internationalization Considerations . . . . . . . . . . . . . . 22 80 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 81 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 82 9.1 Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 24 83 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 10.1 Normative References . . . . . . . . . . . . . . . . . . . 24 85 10.2 Informative References . . . . . . . . . . . . . . . . . . 26 86 Appendix A: JSON Schema . . . . . . . . . . . . . . . . . . . . . 27 87 A.1 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 A.2 Example of output . . . . . . . . . . . . . . . . . . . . . 33 89 Appendix B: XML Schema . . . . . . . . . . . . . . . . . . . . . . 34 90 B.1 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 91 B.2 Example of output . . . . . . . . . . . . . . . . . . . . . 38 92 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 39 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 95 1 Introduction 97 An Object Identifier (OID) is an extensively used identification 98 mechanism jointly developed by ITU-T and ISO/IEC for naming any type 99 of object with a globally unambiguous name. OIDs provide a 100 persistent identification of objects based on a hierarchical 101 structure of Registration Authorities (RA), where each parent has an 102 Object Identifier and allocates Object Identifiers to child nodes. 103 More information about Object Identifiers can be found in 104 Recommendation ITU-T X.660 (2011) | ISO/IEC 9834-1:2012 [X660]. 106 There are a few methods of retrieving information about an OID, like: 108 (A) Searching through web repositories like 109 or . This has the disadvantage 110 that the information is usually not machine-readable without 111 functionalities like an API. 113 (B) Retrieving information using the Object Identifier Resolution 114 System (ORS) as defined in Recommendation ITU-T X.672 (2010) | 115 ISO/IEC 29168-1:2011 [X672]. This has the disadvantage that 116 Registration Authorities need to include specific DNS Resource 117 Records to their domains, and additionally, all RAs of the superior 118 OIDs must implement the ORS. 120 This document describes an additional method for retrieving 121 information about OIDs, which is both human-readable and machine- 122 readable. 124 Three of many possible use-case scenarios are: 126 (1) Many web-browsers and Operating Systems can handle ITU-T X.509 127 certificates [X509] and usually contain a viewer application that 128 shows the contents of these certificates. Attributes that are 129 unknown by the application are either only displayed by their OID, or 130 hidden to avoid confusion to the user. With OID-IP, the application 131 could query the name of these unknown OIDs or even retrieve 132 instructions on how the data described by this OID can be parsed and 133 displayed. 135 (2) Applications that handle SNMP (Simple Network Management 136 Protocol) [RFC1157] might need information about additional MIB files 137 or their OIDs. OID-IP could aid these applications in gathering the 138 required information. 140 (3) In directory services like LDAP (Lightweight Directory Access 141 Protocol) [RFC4511], applications could query the name of attributes 142 that are described by an OID the application doesn't know. 144 1.1 Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 In this document, "RA" is an abbreviation for "Registration 151 Authority", "OID" is an abbreviation for "Object Identifier" and 152 "OID-IP" is an abbreviation for "Object Identifier Information 153 Protocol". 155 2 Request 157 OID-IP is a text-based protocol. 159 An OID-IP server listens on TCP port XXX for requests from OID-IP 160 clients. The OID-IP client makes a text request to the OID-IP 161 server, then the OID-IP server replies with text content. All 162 requests are terminated with ASCII CR followed by ASCII LF. The 163 response contains multiple lines of text, separated by ASCII CR 164 followed by ASCII LF. The OID-IP server closes its connection as 165 soon as the output is finished. The closed TCP connection is the 166 indication to the client that the response has been received. 168 Alternatively to TCP port XXX, an OID-IP server can listen to the 169 WHOIS TCP port 43. Existing WHOIS servers can add the 170 functionalities described in this document in addition to their usual 171 operation, i.e. they may accept queries beginning with "oid:" as well 172 as other types of queries. 174 During the request, the client sends a query beginning with "oid:", 175 followed by an OID in dot-notation, as defined in RFC 3061, section 2 176 [RFC3061], but with the following differences: 178 (1) The OID MAY contain a leading dot. 180 (2) To query the root of the OID tree, the OID MUST be either missing 181 or consisting only of a single dot. 183 Examples of valid queries are: 185 oid: 186 oid:. 187 oid:2.999 188 oid:.2.999 190 All OIDs MUST be interpreted as absolute OIDs. Relative OIDs (e.g. 191 relative to the OID of the Registration Authority operating the OID- 192 IP service) are not allowed. 194 The namespace identifier (i.e. "oid") MUST be written in lower-case. 196 2.1 Authentication Tokens 198 Some organizations might not want to present their OID information 199 (or part of it) to the public, e.g. for reasons like privacy or 200 confidentiality. Therefore, at the end of the query, the client can 201 append case-sensitive, non-empty alphanumeric authentication tokens 202 to control the display of confidential information returned by the 203 OID-IP service. 205 Each authentication token MUST be prepended by a dollar sign ("$"). 207 Examples of valid queries are: 209 oid:2.999$firstToken 210 oid:2.999$firstToken$secondToken 212 Please note that authentication tokens are only weak protection. For 213 more information, see section 8 "Security Considerations". 215 2.2 Server Commands 217 The client can send additional information to the server using 218 "server commands". These are similar to Authentication Tokens, with 219 the difference that they contain an equal sign ("=") which divides 220 the "name" from the "value". Names and values are case-sensitive 221 alphanumeric strings. A request can contain multiple server commands 222 which are each prepended by a dollar sign ("$"). The usage of server 223 commands is individual for each server and implementation. 225 The following request is an example of a valid query where the client 226 sends a "format" command with the value "json": 228 oid:2.999$format=json 230 2.2.1 "format" command 232 The "format" command defines the desired output format. 234 This document defines four formats: 236 (1) "text": A text representation as defined in section 3.1.1. 237 (MANDATORY) 239 (2) "json": The JavaScript Object Notation (JSON, [RFC8259]) 240 representation as defined in section 3.1.2. (OPTIONAL) 242 (3) "xml": Extensible Markup Language (XML, [XML]) representation as 243 defined in section 3.1.3. (OPTIONAL) 245 (4) "html": Hypertext Markup Language (HTML) representation as 246 defined in section 3.1.4. (OPTIONAL) 248 The default format is "text", which is assumed if the "format" 249 command is omitted. 251 Besides these four formats, the server can also accept other formats 252 not defined in this document. The name of the formats SHALL be 253 lower-case. 255 If the client requests a format that is not implemented, then the 256 server MUST respond with the "text" format, and the output MUST 257 consist of the "query" field, "result: Service error", and a fitting 258 "message" field (as described section in 3.2.1). 260 2.3 Request ABNF Notation 262 To define the query string, the following Augmented BNF definitions 263 will be used. They are based on the ABNF styles of RFC 5234 264 [RFC5234]. 266 query = namespace ":" optional-oid *( "$" authtoken ) 267 *( "$" cmdname "=" cmdval ) 269 namespace = %x6F %x69 %x64 ; "oid" 271 optional-oid = [ "." ] [ oid ] 273 oid = unsigned-number *( "." unsigned-number ) 275 authtoken = 1*( char-or-digit ) 277 cmdname = 1*( char-or-digit ) 279 cmdval = 1*( char-or-digit ) 281 digit = %x30-39 ; 0-9 283 nonzero-digit = %x31-39 ; 1-9 285 uppercase-char = %x41-5A ; A-Z 287 lowercase-char = %x61-7A ; a-z 289 char-or-digit = uppercase-char / lowercase-char / digit 291 unsigned-number = "0" / nonzero-digit *( digit ) 293 3 Response 295 3.1 Format and Encoding 297 3.1.1 "text" Format 299 (1) The response MUST be UTF-8 encoded (as defined in RFC 3629 300 [RFC3629]), without Byte-Order-Mark (BOM). 302 (2) The response contains multiple lines with field names and values, 303 which MUST be separated by a double colon (":"). Whitespace 304 characters after the double colon are allowed. 306 (3) If possible, each line SHOULD be limited to 80 characters, 307 including the field name, double colon, value, and whitespaces. 309 (4) Field names and values MUST be treated case-sensitive. 311 (5) If a value needs to be split into multiple lines, e.g. if the 312 line would exceed the length limit, the same field name including 313 double colon MUST be repeated at the beginning of the next line. 315 (6) If an attribute has multiple values (e.g. multiple Unicode 316 labels, alternative email addresses, etc.), each value MUST be 317 written in a new line with the same field name. 319 (7) Lines with the same field name SHALL be kept together. 321 (8) Comment lines MUST start with a percent sign ("%") at the 322 beginning of a line, without prepending whitespaces. They MUST NOT 323 be evaluated by machines (except for signature validation, as 324 mentioned in section 3.3 "Digital Signature"). 326 3.1.2 "json" Format 328 The JavaScript Object Notation (JSON, [RFC8259]) output MUST match 329 the schema defined in Appendix A of this document. 331 3.1.3 "xml" Format 333 The Extensible Markup Language (XML, [XML]) output MUST match the 334 schema defined in Appendix B of this document. 336 3.1.4 "html" Format 338 There are no special requirements for the HTML output format, as it 339 is only intended as human-readable output. 341 3.2 Structure 343 A response consists of sections, which SHOULD be separated by at 344 least one empty line and/or comment line. 346 This document specifies the following sections (which SHALL stay in 347 this order): 349 (1) Query-Section which contains the request and the result. This 350 section MUST start with the field "query". 352 (2) Object-Section which contains information about the OID. This 353 section MUST start with the field "object". 355 (3) RA-Section which contains information about the current 356 Registration Authority. This section MUST start with the field "ra". 358 (4) Optional RA-Sections containing information about RAs that were 359 previously in charge of managing the OID. 361 The OID-IP service MAY define additional sections after any of these 362 sections, but the Query-Section MUST be the first section in the 363 response. 365 3.2.1 Query-Section (Information about Query and Result) 367 This section MUST always be present and MUST start with the field 368 "query". It MUST be the first section in the response. 370 Possible fields are: 372 (1) "query" MUST be present and contains the request string the 373 client has sent. Canonization or sanitation (like removing a leading 374 dot in front of the OID) SHOULD NOT be applied at this step. 375 Authentication tokens SHOULD be omitted, though. 377 (2) "result" MUST be present and SHALL be one of the following 378 values: 380 "Found" means that the OID-IP service can verify that the 381 requested OID exists. The following sections will contain 382 information about this OID. 384 "Not found; superior object found" means that the OID-IP service 385 cannot verify that the requested OID exists, or it denies that 386 the OID exists (e.g. because it is confidential). However, the 387 OID-IP service knows a superior OID which does exist. The 388 following sections will contain information about that superior 389 OID instead. 391 "Not found" means that the OID-IP service cannot verify that the 392 requested OID exists, or it denies that the OID exists (e.g. 393 because it is confidential). Additionally, the OID-IP service 394 does not have information about any superior OID, or their 395 existence is also denied. 397 "Service error" means that an internal error occurred, or that 398 the system is in maintenance mode. The client should try again 399 later. 401 (3) "distance" SHOULD be present if it is applicable in the requested 402 namespace (it is always applicable for OIDs) and if the result is 403 "Not found; superior object found". A distance of 1 means that the 404 direct parent was found. A distance of 2 means that the grand-parent 405 was found, etc. 407 (4) "message" SHOULD be present if the result is "Service error". It 408 contains a message explaining why the service is not available (e.g. 409 displaying an error message). It MUST NOT be present if the result 410 has a different value. 412 The OID-IP service SHOULD NOT add additional fields to this section. 414 3.2.2 Object-Section (Information about the OID) 416 This section MUST be present if the result is "Found" or "Not found; 417 superior object found". It MUST start with the field "object". It 418 MUST NOT be present if the result is "Not found" or "Service error". 420 Possible fields are: 422 (1) "object" contains the OID in dot-notation, prepended by the 423 namespace identifier and double colon ("oid:"). This field MUST be 424 present. 426 (2) "status" MUST be present and SHALL be one of the following 427 values: 429 "Information available" means that information about the OID is 430 fully available. 432 "Information partially available" means that part of the 433 information about the OID is not available. Possible reasons 434 could be that part of the information is redacted due to 435 confidentiality, or the OID-IP service only knows basic 436 information, while the full information can be found somewhere 437 else (e.g. at a referred OID-IP service). The field "attribute" 438 MAY be used with the value "confidential". 440 "Information unavailable" means that the information about the 441 OID is missing, redacted due to confidentiality, or otherwise 442 unavailable. The field "attribute" MAY be used with the value 443 "confidential". 445 (3) "name" (OPTIONAL) contains the name of the OID. It SHOULD be as 446 short as possible. 448 (4) "description" (OPTIONAL) contains a short description of the OID. 449 The description SHOULD only be a single sentence. 451 (5) "information" (OPTIONAL) contains additional information, e.g. 452 Management Information Base (MIB) definitions. 454 (6) "url" (OPTIONAL, multiple values allowed) contains a URL (as 455 defined in RFC 3986 [RFC3986]) leading to more information about the 456 OID. 458 (7) "asn1-notation" (OPTIONAL, multiple values allowed) contains one 459 or more possible notations in the ASN.1 syntax, as defined in 460 Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 32.3 461 [X680], e.g. {joint-iso-itu-t(2) example(999)}. 463 Note: A line-break, to break up lines that are too long, as 464 defined in section 3.1 ("Format and Encoding") SHOULD be used. 465 This is no problem because multiple ASN.1 notations can be 466 distinguished by their opening curly bracket and their closing 467 curly bracket. 469 (8) "iri-notation" (OPTIONAL, multiple values allowed) contains one 470 or more possible notations in the OID-IRI syntax, as defined in 471 Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 34.3 472 [X680] (but without quotation marks), e.g. /Joint-ISO-ITU-T/Example. 474 Note: A line-break, to break up lines which are too long, as 475 defined in section 3.1 ("Format and Encoding") SHALL NOT be used, 476 otherwise, it would be ambiguous if the line-break was used to 477 shorten the line, or if the line-break indicates a new value in 478 case multiple OID-IRI notations are supplied. 480 (9) "identifier" (OPTIONAL, multiple values allowed) contains an 481 alphanumeric identifier ("NameForm") as defined in Recommendation 482 ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 12.3 [X680]. 484 (10) "standardized-id" (OPTIONAL, multiple values allowed) contains 485 an alphanumeric identifier that has a standardized "NameForm", i.e. 486 in ASN.1 notation, it can be written without its associated number. 487 See more information in Recommendation ITU-T X.680 (2015) | ISO/IEC 488 8824-1:2015, clause 32.7 [X680]. 490 (11) "unicode-label" (OPTIONAL, multiple values allowed) contains a 491 Non-integer Unicode label, as defined in Recommendation ITU-T X.680 492 (2015) | ISO/IEC 8824-1:2015, clause 12.27 [X680]. 494 (12) "long-arc" (OPTIONAL, multiple values allowed) contains a Non- 495 integer Unicode label that can be used as the first identifier in an 496 OID Internationalized Resource Identifier (OID-IRI), shortening it. 497 More information can be found in Recommendation ITU-T X.660 (2011) | 498 ISO/IEC 9834-1:2012, clause 3.5.8 [X660]. 500 (13) "oidip-service" (OPTIONAL) contains an IP address or hostname of 501 a system that offers an OID-IP service that can supply information 502 about the OID and/or its subordinate OIDs, followed by a double-colon 503 (:) and a port number. If the result is "Found" (i.e. the OID is 504 existing in the local database), then the information "oidip-service" 505 is only informational; its existence is most likely a hint that 506 subordinate OIDs will be found at that OID-IP server. If the result 507 is "Not found; superior object found", then the client SHOULD query 508 the referred OID-IP server to receive more information about the OID. 509 See more information in section 4 "Referral". 511 (14) "attribute" (OPTIONAL, multiple values allowed) contains 512 attributes of the OID. An attribute MUST be one of the following 513 values: 515 "confidential" means that information about the OID or part of it 516 is confidential. 518 "draft" means that the allocation of the OID is not yet official 519 and the information is subject to change without notice. This 520 includes deletion and relocation. 522 "frozen" means that no more child OIDs can be created under this 523 OID, e.g. because the RA has stopped operating, but the existing 524 child OIDs stay valid. 526 "leaf" means that no child OIDs can be allocated under this OID. 527 The field "subordinate" SHALL therefore not be present. 529 "no-identifiers" means that the RA is not allocating alphanumeric 530 identifiers. 532 "no-unicode-labels" means that the RA is not allocating Non- 533 integer Unicode labels. 535 "retired" means that the OID is withdrawn, revoked, retired, 536 expired, etc. Please consult Recommendation ITU-T X.660 (2011) | 537 ISO/IEC 9834-1:2012 [X660] for more information about such cases. 539 (15) "parent" (OPTIONAL) contains the OID of the nearest known parent 540 OID, prepended by namespace identifier and double colon, i.e. "oid:". 541 It MAY be followed by additional human-readable information, e.g. a 542 description or a list of ASN.1 identifiers. There SHALL be at least 543 1 whitespace in between. 545 (16) "subordinate" (OPTIONAL, multiple values allowed) contains a 546 list of subordinate OIDs, prepended by namespace identifier and 547 double colon, i.e. "oid:". It MAY be followed by additional human- 548 readable information, e.g. a description or a list of ASN.1 549 identifiers. There SHALL be at least 1 whitespace in between. 551 (17) "created" (OPTIONAL) contains the date and time (as specified in 552 section 3.4 "Date/Time Format") when the OID was first allocated by 553 the RA of the superior OID. 555 (18) "updated" (OPTIONAL) contains the date and time (as specified in 556 section 3.4 "Date/Time Format") when the OID information was last 557 updated. 559 Additional fields can be defined by the OID-IP service. The field 560 names SHALL only consist of the lower-case letters "a..z", hyphens 561 ("-"), and numbers, and SHOULD be written in the English language. 562 The field name MUST NOT begin or end with a hyphen and a hyphen MUST 563 NOT be followed by another hyphen. 565 3.2.3 RA-Section (Information about the Current RA) 567 This section MUST NOT be present if the result is "Not found" or 568 "Service error", otherwise it MAY be present. If it is present, it 569 MUST start with the field "ra". 571 Possible fields are: 573 (1) "ra" contains a general name of the RA, like the name of a 574 person, the name of a group, or the name of an organization. This 575 field MUST be present. 577 (2) "ra-status" MUST be present and SHALL be one of the following 578 values: 580 "Information available" means that information about this RA is 581 fully available. 583 "Information partially available" means that part of the 584 information is not available. A possible reason could be that 585 part of the information is redacted due to confidentiality. The 586 field "attribute" MAY be used with the value "confidential". 588 "Information unavailable" means that the data is missing (if the 589 OID-IP service only knows the name of the RA and nothing else), 590 redacted due to confidentiality, or otherwise unavailable. The 591 field "attribute" MAY be used with the value "confidential". 593 (3) "ra-contact-name" (OPTIONAL, multiple values allowed) contains 594 the name of a person responsible for the allocation of subordinate 595 OIDs, in case "ra" is a group or organization. 597 (4) "ra-address" (OPTIONAL) contains the physical location of the RA. 598 While a fully qualified postal address is recommended, the field can 599 also just contain a rough location like city and country name, state 600 and country name, or just the country name, etc. The name of the 601 country SHOULD always be present. 603 (5) "ra-phone" (OPTIONAL, multiple values allowed) contains a 604 landline phone number of the Registration Authority. It SHOULD be 605 written in the international number format specified in 606 Recommendation ITU-T E.164 (2010) [E164], e.g. +1 206 555 0100. 608 (6) "ra-mobile" (OPTIONAL, multiple values allowed) contains a mobile 609 phone number of the Registration Authority. It SHOULD be written in 610 the international number format specified in Recommendation ITU-T 611 E.164 (2010) [E164], e.g. +1 206 555 0100. 613 (7) "ra-fax" (OPTIONAL, multiple values allowed) contains a fax 614 number of the Registration Authority. It SHOULD be written in the 615 international number format specified in Recommendation ITU-T E.164 616 (2010) [E164], e.g. +1 206 555 0100. 618 (8) "ra-email" (OPTIONAL, multiple values allowed) contains an email 619 address of the Registration Authority. 621 (9) "ra-url" (OPTIONAL, multiple values allowed) contains a URL (as 622 defined in RFC 3986 [RFC3986]) leading to more information about the 623 RA (usually the website of the RA). 625 (10) "ra-attribute" (OPTIONAL, multiple values allowed) contains 626 attributes of the RA. An attribute MUST be one of the following 627 values: 629 "confidential" means that the information about the RA or part of 630 it is confidential. 632 "retired" means that the RA is defunct. If this attribute is set 633 to the current RA, then the OID MUST have the attribute "frozen" 634 (until the responsibility is transferred to a non-defunct RA, or 635 until the current RA becomes active again). 637 (11) "ra-created" (OPTIONAL) contains the date and time (as specified 638 in section 3.4 "Date/Time Format") when the RA was created/registered 639 in the database. 641 (12) "ra-updated" (OPTIONAL) contains the date and time (as specified 642 in section 3.4 "Date/Time Format") when the RA information was last 643 modified. 645 Additional fields can be defined by the OID-IP service, but they MUST 646 begin with "ra-". The field names SHALL only consist of the lower- 647 case letters "a..z", hyphens ("-"), and numbers, and SHOULD be 648 written in the English language. The field name MUST NOT begin or 649 end with a hyphen and a hyphen MUST NOT be followed by another 650 hyphen. 652 3.2.4 Sections for Previous Registration Authorities 654 To optionally display information about RAs that were previously in 655 charge of managing the OID, a new section per RA can be added with 656 the following field name prefixes: 658 "ra-" is the prefix of the current Registration Authority. 660 "ra1-" is the prefix of the first RA. It is the very first person or 661 company to whom the OID was allocated by the RA of the superior OID. 662 "ra2-" is the prefix of the second RA, after the responsibility has 663 been transferred. etc. 665 The definition of these sections is identical to the definition of 666 the RA-Section (described in section 3.2.3 "RA-Section"), just with a 667 different prefix. 669 The history does not need to be complete, e.g. it is no problem to 670 only serve information about the first and the current RA, or only 671 serve information about the current RA. 673 3.3 Digital Signature 675 If integrity/authenticity is required, the whole response can be 676 signed, e.g. by using S/MIME, RSA, or PGP. This document does not 677 describe a mechanism for detecting which signature method was used. 678 The creation and verification of the signature are therefore 679 implementation-specific and no interoperability regarding signature 680 creation and validation is given at this time. 682 Depending on the signature method being used, various things need to 683 be appended and/or prepended to the response. These additional lines 684 MUST be prepended by a percent sign ("%") to avoid that an 685 application confuses these additional lines (e.g. lines belonging to 686 a PGP header, as defined in RFC 4880 [RFC4880]) with parts of the 687 actual OID-IP response. 689 3.4 Date/Time Format 691 Date/Time references SHALL be formatted as described in 692 section 3.4.1. 694 If parts of the date/time reference are uncertain, then they SHOULD 695 be omitted until the date/time reference has the highest correctness. 697 Examples of valid date/time references can be found in section 3.4.2. 699 3.4.1 Date/Time Format ABNF Notation 701 To define the format of a Date/Time reference, the following 702 Augmented BNF definitions will be used. They are based on the ABNF 703 styles of RFC 5234 [RFC5234]. 705 date-time = year [ "-" month [ "-" day [ " " time ] ] ] 707 year = 4*4DIGIT 709 month = ( "0" %x31-39 ) / 710 ( "1" %x30-32 ) ; 01-12 712 day = ( "0" %x31-39 ) / 713 ( "1" %x30-39 ) / 714 ( "2" %x30-39 ) / 715 ( "3" %x30-31 ) / ; 01-31 717 time = hour ":" minute [ ":" second ] [ " " timezone ] 719 hour = ( "0" %x30-39 ) / 720 ( "1" %x30-39 ) / 721 ( "2" %x30-33 ) ; 00-23 723 minute = %x30-35 DIGIT ; 00-59 725 second = %x30-35 DIGIT ; 00-59 727 timezone = ( "+" / "-" ) hour minute 729 3.4.2 Date/Time Format Examples 731 Examples of valid date/time references are: 733 2022-09-29 18:32:00 +0200 734 2022-09-29 18:32:00 735 2022-09-29 18:32 +0200 736 2022-09-29 18:32 737 2022-09-29 738 2022-09 739 2022 741 4 Referral 743 By using the field "oidip-service", the OID-IP service can instruct 744 the client to query another OID-IP service that might have more 745 information about the requested OID. 747 If Registration Authorities maintain up-to-date OID-IP service 748 references of their OID delegations, it is possible to automatically 749 retrieve information about any OID. 751 Example: OID "2.999" is owned by Registration Authority "A", 752 operating an OID-IP service at "a.example.com". 754 Registration Authority "A" allocated OID "2.999.1000" to Registration 755 Authority "B" who is operating an OID-IP service at "b.example.com". 757 The client asks a.example.com for information about OID 758 "2.999.1000.1" and should receive the following reply: 760 query: oid:2.999.1000.1 761 result: Not found; superior object found 762 distance: 1 764 object: oid:2.999.1000 765 status: Information available 766 name: Company "B" 767 oidip-service: b.example.com:XXX 769 ra: "B" 770 ra-status: Information unavailable 772 The client is now aware that "a.example.com" only knows OID 773 "2.999.1000", and that there is a reference to another OID-IP service 774 located at "b.example.com". So, the client should then accordingly 775 query "b.example.com", asking for information about OID 776 "2.999.1000.1": 778 query: oid:2.999.1000.1 779 result: Found 781 object: oid:2.999.1000.1 782 status: Information available 783 name: Example OID 1 785 ra: "B" 786 ra-status: Information unavailable 788 5 Full Example ("text" Format) 790 5.1 Request 792 oid:2.999 794 5.2 Response 796 query: oid:2.999 797 result: Found 799 object: oid:2.999 800 status: Information available 801 name: Example 802 description: This OID can be used by anyone, for the purposes of 803 description: documenting examples of Object Identifiers. 804 asn1-notation: {joint-iso-itu-t(2) example(999)} 805 iri-notation: /Example 806 identifier: example 807 unicode-label: Beispiel 808 unicode-label: Ejemplo 809 unicode-label: Example 810 unicode-label: Exemple 811 unicode-label: (Korean characters are omitted in this example) 812 unicode-label: (Arabian characters are omitted in this example) 813 unicode-label: (Japanese characters are omitted in this example) 814 unicode-label: (Chinese characters are omitted in this example) 815 unicode-label: (Russian characters are omitted in this example) 816 long-arc: Beispiel 817 long-arc: Ejemplo 818 long-arc: Example 819 long-arc: Exemple 820 long-arc: (Korean characters are omitted in this example) 821 long-arc: (Arabian characters are omitted in this example) 822 long-arc: (Japanese characters are omitted in this example) 823 long-arc: (Chinese characters are omitted in this example) 824 long-arc: (Russian characters are omitted in this example) 825 parent: oid:2 (joint-iso-itu-t) 826 created: 2011-06 827 updated: 2011-09 829 ra: ITU-T SG 17 & ISO/IEC JTC 1/SC 6 830 ra-status: Information unavailable 831 % -----BEGIN RSA SIGNATURE----- 832 % DwnqRtx/ONtPh4onXnrZPl9jF+G50RMLZkSwuClaoH2t/yK8CnYJrmzkzA5+gkfWkoQ 833 % cq+J8J9cvnwXvBfpVHh+7lyNOVW1N016TYFcBt8MVxb6K2KhkKclqeA6wz0kSUuE4qR 834 % ZohzrZBcCP7aLIpcaoVi6QACAt6J0vOvYBaf0= 835 % -----END RSA SIGNATURE----- 837 6 Alternative Namespaces 839 This document describes the retrieval of information about OIDs using 840 the OID-IP protocol. In addition to the OID namespace, the methods 841 described in this document can also be applied to other namespaces 842 like "uuid", "isbn", "gtin" etc. 844 Following things need to be considered if alternative namespaces are 845 implemented: 847 (1) The request MUST be UTF-8 encoded (as defined in RFC 3629 848 [RFC3629]), without Byte-Order-Mark (BOM). 850 (2) The namespace SHALL be a namespace identifier (NID) as defined in 851 RFC 8141 [RFC8141]. 853 (3) The namespace identifier SHALL be written in lower-case (this is 854 already defined in section 2 "Request"). 856 (4) If available, a formal URN namespace identifier (as defined in 857 RFC 8141, section 5.1 [RFC8141]) SHOULD be used, e.g. "uuid" should 858 be used instead of "guid". 860 (5) If things like "Owner", "Creator", "Manager", "Administrator", 861 etc., are relevant to the identifiers in the namespace, then the RA- 862 section as described in section 3.2.3 SHALL be used, even though the 863 word "Registration Authority" might not be appropriate in the 864 terminology of the namespace. 866 (6) The namespace-specific identifier MUST NOT contain dollar signs 867 ("$"), because section 2.1 "Authentication Tokens" defines them as a 868 separator for authentication tokens. 870 (7) The namespace-specific identifier MUST be treated case-sensitive 871 if the namespace distinguishes between lower-case and upper-case. 873 (8) Fields that can only be used in the OID namespace (e.g. "unicode- 874 label") MUST NOT be used for other namespaces. 876 6.1 Example: UUID Namespace 878 The following example shows the retrieval of information about 879 Universally Unique Identifiers (e.g. UUIDs used by the Microsoft 880 Common Object Model, also known as GUIDs). The UUID namespace has no 881 hierarchical structure, which means that the OID-IP service can only 882 respond with the result "Found", "Not found" or "Service error" and 883 the fields "parent" and "subordinate" cannot be used. 885 Request: 887 uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 889 Response: 891 query: uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 892 result: Found 894 object: uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 895 status: Information available 896 name: Desktop 897 information: GUID can be used in file dialogs as "Custom Place". 899 ra: Microsoft Corp. 900 ra-status: Information unavailable 902 More information about UUIDs can be found in Recommendation ITU-T 903 X.667 (2012) | ISO/IEC 9834-8:2014 [X667]. 905 More information about the Microsoft Common Object Model (COM) can be 906 found at Microsoft Docs . 909 7 Internationalization Considerations 911 This document specifies that the request and response MUST be UTF-8 912 encoded (as defined in RFC 3629 [RFC3629]), without Byte-Order-Mark 913 (BOM). 915 The OID-IP service can define additional field names, but they SHOULD 916 be written in the English language so that there is consistency with 917 the field names defined in this document. 919 8 Security Considerations 921 (1) The knowledge of existence or information about some OIDs could 922 be considered confidential. In this case, the OID-IP service can 923 either deny the existence of the requested OID (by setting the result 924 to "Not found") or redact information in the Object-Section, as 925 defined in section 3.2.2 "Object-Section". 927 (2) Registration Authorities might demand that their data is kept 928 confidential, or at least be partially redacted to increase privacy 929 or as a measurement against spam. In this case, the OID-IP service 930 can redact information in the RA-Section, as defined in section 3.2.3 931 "RA-Section". 933 (3) The OID-IP service can decide if confidential material is omitted 934 or shown, based on authentication mechanisms like white-listing 935 client IP addresses or by using authentication tokens supplied by the 936 client during the request, as defined in section 2.1 "Authentication 937 Tokens". 939 (4) The usage of authentication tokens is not recommended if the 940 traffic between client and server is transmitted through an untrusted 941 network, because the OID-IP protocol is not encrypted. 943 (5) Authentication tokens must have a sufficient length and 944 complexity to avoid successful brute force attacks, or the OID-IP 945 service must limit the number of requests per time. 947 (6) The OID-IP protocol itself has no mechanism for verifying the 948 integrity of data received. Due to this fact, the information should 949 not be trusted if it is transmitted through an untrusted network. If 950 integrity/authenticity is required, the OID-IP response can be 951 signed, as described in section 3.3 "Digital Signature". However, 952 this document does not describe a mechanism for detecting which 953 signature method was used. Therefore, no interoperability of 954 signature creation/validation is given at this time. 956 9 IANA Considerations 958 9.1 Port Numbers 960 This document requires the assignment of a TCP port number. 962 +--------------------+-----------------------------+ 963 | Service Name | oidip | 964 | Transport Protocol | TCP | 965 | Assignee | ... | 966 | Contact | ... | 967 | Description | OID Information Protocol | 968 | Reference | [RFCyyyy] | 969 | Port Number | XXX | 970 +--------------------+-----------------------------+ 972 [To RFC Editor: Please change "yyyy" to the RFC number allocated to 973 this document before publication.] 975 [To RFC Editor: Please change "XXX" placed at various locations in 976 this document to the port number allocated by IANA.] 978 10 References 980 10.1 Normative References 982 [E164] "The international public telecommunication numbering 983 plan", Recommendation ITU-T E.164 (2010), November 2010. 984 . 986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 987 Requirement Levels", BCP 14, RFC 2119, 988 DOI 10.17487/RFC2119, March 1997. 989 . 991 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 992 RFC 3061, DOI 10.17487/RFC3061, February 2001. 993 . 995 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 996 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 997 November 2003. 998 . 1000 [RFC3986] Berners-Lee, T., "Uniform Resource Identifier (URI): 1001 Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, 1002 January 2005. 1003 . 1005 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1006 Specifications: ABNF", STD 68, RFC 5234, 1007 DOI 10.17487/RFC5234, January 2008. 1008 . 1010 [RFC8141] Saint-Andre, P., "Uniform Resource Names (URNs)", 1011 RFC 8141, DOI 10.17487/RFC8141, April 2017. 1012 . 1014 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 1015 "Handling Long Lines in Content of Internet-Drafts and 1016 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020. 1017 . 1019 [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data 1020 Interchange Format", RFC 8259, DOI 10.17487/RFC8259, 1021 December 2017. 1022 . 1024 [X660] "Information technology - Procedures for the operation of 1025 object identifier registration authorities: General 1026 procedures and top arcs of the international object 1027 identifier tree", Recommendation ITU-T X.660 (2011) | 1028 ISO/IEC 9834-1:2012, July 2011. 1029 . 1031 [X680] "Information technology - Abstract Syntax Notation One 1032 (ASN.1): Specification of basic notation", Recommendation 1033 ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, August 2015. 1034 . 1036 [XML] "Extensible Markup Language (XML) 1.1 (Second Edition)" 1037 W3C Recommendation 16 August 2006, edited in place 29 1038 September 2006 1039 . 1041 [XSD] W3C XML Schema Definition Language (XSD) 1042 W3C Recommendation 5 April 2012 1043 . 1045 [JSONSch] JSON Schema Specification 1046 . 1048 10.2 Informative References 1050 [RFC1157] Case, J., Fedor, M., Schoffstall, M., Davin, J., "A Simple 1051 Network Management Protocol (SNMP)", RFC 1157, 1052 DOI 10.17487/RFC1157, May 1990. 1053 . 1055 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 1056 (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, 1057 June 2006. 1058 . 1060 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., Thayer, 1061 R., "OpenPGP Message Format", RFC 4880, 1062 DOI 10.17487/RFC4880, November 2007. 1063 . 1065 [X509] "Information technology - Open Systems Interconnection - 1066 The Directory: Public-key and attribute certificate 1067 frameworks", Recommendation ITU-T X.509 (2016) | 1068 ISO/IEC 9594-8:2017, October 2016. 1069 . 1071 [X667] "Information technology - Procedures for the operation of 1072 object identifier registration authorities: Generation of 1073 universally unique identifiers and their use in object 1074 identifiers", Recommendation ITU-T X.667 (2012) | 1075 ISO/IEC 9834-8:2014, October 2012. 1076 . 1078 [X672] "Information technology - Open systems interconnection - 1079 Object identifier resolution system", 1080 Recommendation ITU-T X.672 (2010) | ISO/IEC 29168-1:2011, 1081 August 2010. 1082 . 1084 Appendix A: JSON Schema 1086 A.1 Schema 1088 The following JSON Schema ([JSONSch]) defines the expected output the 1089 server sends if the server command "format" is set to "json". 1091 1092 # NOTE: '\' line wrapping per RFC 8792 1093 { 1094 "$schema":"http://json-schema.org/draft-07/schema#", 1095 "type":"object", 1096 "properties":{ 1097 "oidip":{ 1098 "type":"array", 1099 "items":[ 1100 { 1101 "type":"object", 1102 "properties":{ 1103 "query":{ 1104 "type":"string" 1105 }, 1106 "result":{ 1107 "type":"string", 1108 "enum":["Found", 1109 "Not found; superior object found", 1110 "Not found", 1111 "Service error"] 1112 }, 1113 "distance":{ 1114 "type":"string" 1115 }, 1116 "message":{ 1117 "type":"string" 1118 } 1119 }, 1120 "required":[ 1121 "query", 1122 "result" 1123 ] 1124 }, 1125 { 1126 "type":"object", 1127 "properties":{ 1128 "object":{ 1129 "type":"string" 1130 }, 1131 "status":{ 1132 "type":"string", 1133 "enum":["Information available", 1134 "Information partially available", 1135 "Information unavailable"] 1136 }, 1137 "name":{ 1138 "type":"string" 1139 }, 1140 "description":{ 1141 "type":"string" 1142 }, 1143 "information":{ 1144 "type":"string" 1145 }, 1146 "url":{ 1147 "type":"string" 1148 }, 1149 "asn1-notation":{ 1150 "oneOf":[ 1151 { 1152 "type":"string" 1153 }, 1154 { 1155 "type":"array", 1156 "items":{ 1157 "type":"string" 1158 } 1159 } 1160 ] 1161 }, 1162 "iri-notation":{ 1163 "oneOf":[ 1164 { 1165 "type":"string" 1166 }, 1167 { 1168 "type":"array", 1169 "items":{ 1170 "type":"string" 1171 } 1172 } 1173 ] 1174 }, 1175 "identifier":{ 1176 "oneOf":[ 1177 { 1178 "type":"string" 1179 }, 1180 { 1181 "type":"array", 1182 "items":{ 1183 "type":"string" 1184 } 1185 } 1186 ] 1187 }, 1188 "standardized-id":{ 1189 "oneOf":[ 1190 { 1191 "type":"string" 1192 }, 1193 { 1194 "type":"array", 1195 "items":{ 1196 "type":"string" 1197 } 1198 } 1199 ] 1200 }, 1201 "unicode-label":{ 1202 "oneOf":[ 1203 { 1204 "type":"string" 1205 }, 1206 { 1207 "type":"array", 1208 "items":{ 1209 "type":"string" 1210 } 1211 } 1212 ] 1213 }, 1214 "long-arc":{ 1215 "oneOf":[ 1216 { 1217 "type":"string" 1218 }, 1219 { 1220 "type":"array", 1221 "items":{ 1222 "type":"string" 1223 } 1224 } 1225 ] 1226 }, 1227 "oidip-service":{ 1228 "type":"string" 1229 }, 1230 "attribute":{ 1231 "oneOf":[ 1232 { 1233 "type":"string", 1234 "enum":["confidential", 1235 "draft", 1236 "frozen", 1237 "leaf", 1238 "no-identifiers", 1239 "no-unicode-labels", 1240 "retired"] 1241 }, 1242 { 1243 "type":"array", 1244 "items":{ 1245 "type":"string", 1246 "enum":["confidential", 1247 "draft", 1248 "frozen", 1249 "leaf", 1250 "no-identifiers", 1251 "no-unicode-labels", 1252 "retired"] 1253 } 1254 } 1255 ] 1256 }, 1257 "parent":{ 1258 "type":"string" 1259 }, 1260 "subordinate":{ 1261 "oneOf":[ 1262 { 1263 "type":"string" 1264 }, 1265 { 1266 "type":"array", 1267 "items":{ 1268 "type":"string" 1269 } 1270 } 1271 ] 1272 }, 1273 "created":{ 1274 "type":"string", 1275 "pattern":"^\d{4}(\-(0[1-9]|11|12)\ 1277 (\-(0[1-9]|1\d|2\d|30|31)( [0-5][0-9]:[0-5][0-9](:[0-5][0-9]){0,1}\ 1278 ( [\+\-][0-5][0-9][0-5][0-9]){0,1}){0,1}){0,1}){0,1}$" 1279 }, 1280 "updated":{ 1281 "type":"string", 1282 "pattern":"^\d{4}(\-(0[1-9]|11|12)\ 1283 (\-(0[1-9]|1\d|2\d|30|31)( [0-5][0-9]:[0-5][0-9](:[0-5][0-9]){0,1}\ 1284 ( [\+\-][0-5][0-9][0-5][0-9]){0,1}){0,1}){0,1}){0,1}$" 1285 } 1286 }, 1287 "required":[ 1288 "object", 1289 "status" 1290 ] 1291 }, 1292 { 1293 "type":"object", 1294 "properties":{ 1295 "ra":{ 1296 "type":"string" 1297 }, 1298 "ra-status":{ 1299 "type":"string", 1300 "enum":["Information available", 1301 "Information partially available", 1302 "Information unavailable"] 1303 }, 1304 "ra-contact-name":{ 1305 "type":"string" 1306 }, 1307 "ra-address":{ 1308 "type":"string" 1309 }, 1310 "ra-phone":{ 1311 "type":"string" 1312 }, 1313 "ra-mobile":{ 1314 "type":"string" 1315 }, 1316 "ra-fax":{ 1317 "type":"string" 1318 }, 1319 "ra-email":{ 1320 "type":"string" 1321 }, 1322 "ra-url":{ 1323 "type":"string" 1324 }, 1325 "ra-attribute":{ 1326 "oneOf":[ 1327 { 1328 "type":"string", 1329 "enum":["confidential", 1330 "retired"] 1331 }, 1332 { 1333 "type":"array", 1334 "items":{ 1335 "type":"string", 1336 "enum":["confidential", 1337 "retired"] 1338 } 1339 } 1340 ] 1341 }, 1342 "ra-created":{ 1343 "type":"string", 1344 "pattern":"^\d{4}(\-(0[1-9]|11|12)\ 1345 (\-(0[1-9]|1\d|2\d|30|31)( [0-5][0-9]:[0-5][0-9](:[0-5][0-9]){0,1}\ 1346 ( [\+\-][0-5][0-9][0-5][0-9]){0,1}){0,1}){0,1}){0,1}$" 1347 }, 1348 "ra-updated":{ 1349 "type":"string", 1350 "pattern":"^\d{4}(\-(0[1-9]|11|12)\ 1351 (\-(0[1-9]|1\d|2\d|30|31)( [0-5][0-9]:[0-5][0-9](:[0-5][0-9]){0,1}\ 1352 ( [\+\-][0-5][0-9][0-5][0-9]){0,1}){0,1}){0,1}){0,1}$" 1353 } 1354 }, 1355 "required":[ 1356 "ra", 1357 "ra-status" 1358 ] 1359 } 1360 ] 1361 }, 1362 "signature":{ 1363 "type":"object", 1364 "properties":{ 1365 "content":{ 1366 "type":"string" 1367 }, 1368 "signature":{ 1369 "type":"string" 1370 } 1371 }, 1372 "required":[ 1373 "content", 1374 "signature" 1375 ] 1376 } 1377 }, 1378 "required":[ 1379 "oidip" 1380 ] 1381 } 1382 1384 A.2 Example of output 1386 1387 # NOTE: '\' line wrapping per RFC 8792 1388 { 1389 "$schema":"http://.../oidip_schema.json", 1390 "oidip": [ 1391 { 1392 "query": "oid:2.999", 1393 "result": "Found" 1394 }, 1395 { 1396 "object": "oid:2.999", 1397 "status": "Information available", 1398 "name": "Example", 1399 "description": "This OID can be used by anyone, for the \ 1400 purposes of documenting examples of Object Identifiers.", 1401 "asn1-notation": "{joint-iso-itu-t(2) example(999)}", 1402 "iri-notation": "/Example", 1403 "identifier": "example", 1404 "unicode-label": [ 1405 "Beispiel", 1406 "Ejemplo", 1407 "Example", 1408 "Exemple", 1409 "(Korean characters are omitted in this example)", 1410 "(Arabian characters are omitted in this example)", 1411 "(Japanese characters are omitted in this example)", 1412 "(Chinese characters are omitted in this example)", 1413 "(Russian characters are omitted in this example)" 1414 ], 1415 "long-arc": [ 1416 "Beispiel", 1417 "Ejemplo", 1418 "Example", 1419 "Exemple", 1420 "(Korean characters are omitted in this example)", 1421 "(Arabian characters are omitted in this example)", 1422 "(Japanese characters are omitted in this example)", 1423 "(Chinese characters are omitted in this example)", 1424 "(Russian characters are omitted in this example)" 1425 ], 1426 "parent": "oid:2 (joint-iso-ccitt, joint-iso-itu-t)", 1427 "subordinate": [], 1428 "created": "2011-06", 1429 "updated": "2020-09" 1430 }, 1431 { 1432 "ra": "ITU-T SG 17 & ISO/IEC JTC 1/SC 6", 1433 "ra-status": "Information unavailable" 1434 } 1435 ], 1436 "signature": { 1437 "content": "{\"oidip\":[{...(The contents of the 'oidip'\ 1438 structure are repeated here; ideally minified)...}]}", 1439 "signature": "(Base36 signature here)" 1440 } 1441 } 1442 1444 Appendix B: XML Schema 1446 B.1 Schema 1448 [To RFC Editor: Please change "urn:ietf:id:viathinksoft-oidip-02" to 1449 "urn:ietf:rfc:yyyy" before publication.] 1451 The following XML Schema Definition ([XSD]) defines the expected output 1452 the server sends if the server command "format" is set to "xml". 1454 1455 # NOTE: '\' line wrapping per RFC 8792 1456 1457 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1528 1529 1530 1531 1535 1536 1537 1538 1539 1540 1541 1545 1546 1547 1548 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1587 1588 1589 1590 1591 1592 1593 1596 1597 1598 1599 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1614 1615 1616 1617 1618 1619 1620 1621 1623 B.2 Example of output 1625 [To RFC Editor: Please change "urn:ietf:id:viathinksoft-oidip-02" to 1626 "urn:ietf:rfc:yyyy" before publication.] 1628 1629 # NOTE: '\' line wrapping per RFC 8792 1630 1631 1635 1636 1637 oid:2.999 1638 Found 1639 1640 1641 oid:2.999 1642 Information available 1643 { joint-iso-itu-t(2) example(999) } 1644 /Example 1645 example 1646 Beispiel 1647 Ejemplo 1648 Example 1649 Exemple 1650 (Korean characters are omitted) 1651 (Arabian characters are omitted) 1652 (Japanese characters are omitted) 1653 (Chinese characters are omitted) 1654 (Russian characters are omitted) 1655 Beispiel 1656 Ejemplo 1657 Example 1658 Exemple 1659 (Korean characters are omitted) 1660 (Arabian characters are omitted) 1661 (Japanese characters are omitted) 1662 (Chinese characters are omitted) 1663 (Russian characters are omitted) 1664 oid:2 (joint-iso-ccitt, joint-iso-itu-t) 1665 1666 1667 ITU-T SG 17 & ISO/IEC JTC 1/SC 6 1668 Information unavailable 1669 1670 1671 1672 (The contents of the "oidip" structure are \ 1674 repeated here; ideally minified) 1675 ]]> 1676 (Base36 signature here) 1677 1678 1679 1681 Acknowledgements 1683 Olivier Dubuisson 1685 Authors' Addresses 1687 Daniel Marschall 1688 Postfach 11 53 1689 69243 Bammental 1690 Germany 1692 EMail: daniel-marschall@viathinksoft.de