-
Notifications
You must be signed in to change notification settings - Fork 0
/
viathinksoft-std-0002-oidip.html
3505 lines (2427 loc) · 175 KB
/
viathinksoft-std-0002-oidip.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>OID Information Protocol (OID-IP)</title>
<style>
/** === DESKTOP === */
@media (min-width: 601px) {
a, a:visited, a:link, a:active, a:hover {
color: #046D95 !important;
}
body {
color: black !important;
background-color: #f5f5f5 !important;
padding: 20px;
display: flex;
flex-direction: column;
align-items: center;
margin: 0;
}
.page {
width: 100%;
max-width: 700px; /* 72 Zeichen Breite in Pixel (bei Desktop-Ansicht) */
margin-bottom: 20px;
padding: 20px;
background-color: white;
box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
font-family: monospace;
white-space: pre-wrap;
overflow: hidden;
border: 1px solid #ccc;
box-sizing: border-box;
}
}
/** === MOBILE === */
@media (max-width: 600px) {
a, a:visited, a:link, a:active, a:hover {
color: #046D95 !important;
}
body {
color: black !important;
background-color: #f5f5f5 !important;
padding: 0;
margin: 0;
display: flex;
flex-direction: column;
align-items: center;
}
.container {
width: 100%;
padding: 10px;
box-sizing: border-box;
}
.page {
width: 100%;
max-width: 100%; /* Ensures the page takes up full width on mobile */
margin-bottom: 20px;
padding: 10px;
background-color: white;
box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
font-family: monospace;
white-space: pre-wrap;
overflow: auto; /* Ensures overflow is handled */
border: 1px solid #ccc;
box-sizing: border-box;
font-size: 8.7px; /* Smaller font size for mobile */
}
}
</style>
</head>
<body>
<span style="font-family:Verdana">← <a href="index.html">Back to Standards index</a></span><br><br>
<div id="content">
<div class="container"><div class="page"><pre>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: <a href="https://datatracker.ietf.org/doc/html/draft-viathinksoft-oidip-10">draft-viathinksoft-oidip-10</a>
Attachments
XML Schema:
<a href="https://github.com/ViaThinkSoft/standards/blob/main/viathinksoft-std-0002-oidip.xsd">https://github.com/ViaThinkSoft/standards/blob/main/viathinksoft-std-</a>
<a href="https://github.com/ViaThinkSoft/standards/blob/main/viathinksoft-std-0002-oidip.xsd">0002-oidip.xsd</a>
JSON Schema:
<a href="https://github.com/ViaThinkSoft/standards/blob/main/viathinksoft-std-0002-oidip.json">https://github.com/ViaThinkSoft/standards/blob/main/viathinksoft-std-</a>
<a href="https://github.com/ViaThinkSoft/standards/blob/main/viathinksoft-std-0002-oidip.json">0002-oidip.json</a>
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.
<span class="grey">Marschall [Page 1]</span></pre>
</div><div class="page"><span class="noprint" id="page-2"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
Table of Contents
<a href="#section-1">1</a> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-1.1">1.1</a> Terminology . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2">2</a> Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.1">2.1</a> Request via HTTP(S) Protocol (Recommended) . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.1.1">2.1.1</a> Request Method and Path . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.1.2">2.1.2</a> Formats and Content-Types . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-2.1.3">2.1.3</a> Authentication . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-2.1.4">2.1.4</a> Preferred Language . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-2.1.5">2.1.5</a> Custom Input Parameters . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-2.1.6">2.1.6</a> Cookies . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-2.2">2.2</a> Request via WHOIS Protocol (Backwards Compatibility) . . . <a href="#page-11">11</a>
<a href="#section-2.2.1">2.2.1</a> Request Method . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-2.2.1.1">2.2.1.1</a> Basic Query String . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-2.2.1.2">2.2.1.2</a> Input Parameters . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-2.2.1.3">2.2.1.3</a> Request ABNF Notation . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-2.2.2">2.2.2</a> Format ("format" Argument) . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-2.2.3">2.2.3</a> Authentication Tokens ("auth" Argument) . . . . . . . . <a href="#page-14">14</a>
<a href="#section-2.2.4">2.2.4</a> Preferred Language ("lang" Argument) . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-2.2.5">2.2.5</a> Custom Input Parameters . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-3">3</a> Response . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-3.1">3.1</a> Format and Encoding . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-3.1.1">3.1.1</a> "text" Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-3.1.2">3.1.2</a> "json" Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-3.1.3">3.1.3</a> "xml" Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-3.2">3.2</a> Sections . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-3.2.1">3.2.1</a> Query-Section (Information about Query and Result) . . <a href="#page-18">18</a>
<a href="#section-3.2.1.1">3.2.1.1</a> Query-Section "query" Field . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-3.2.1.2">3.2.1.2</a> Query-Section "result" Field . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-3.2.1.3">3.2.1.3</a> Query-Section "distance" Field . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-3.2.1.4">3.2.1.4</a> Query-Section "message" Field . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-3.2.1.5">3.2.1.5</a> Query-Section "lang" Field . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-3.2.1.6">3.2.1.6</a> Query-Section Other Fields . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-3.2.2">3.2.2</a> Object-Section (Information about the OID) . . . . . . <a href="#page-19">19</a>
<a href="#section-3.2.2.1">3.2.2.1</a> Object-Section "object" Field . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-3.2.2.2">3.2.2.2</a> Object-Section "status" Field . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-3.2.2.3">3.2.2.3</a> Object-Section "lang" Field . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-3.2.2.4">3.2.2.4</a> Object-Section "name" Field . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-3.2.2.5">3.2.2.5</a> Object-Section "description" Field . . . . . . . . <a href="#page-20">20</a>
<a href="#section-3.2.2.6">3.2.2.6</a> Object-Section "information" Field . . . . . . . . <a href="#page-20">20</a>
<a href="#section-3.2.2.7">3.2.2.7</a> Object-Section "url" Field . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-3.2.2.8">3.2.2.8</a> Object-Section "asn1-notation" Field . . . . . . . <a href="#page-20">20</a>
<a href="#section-3.2.2.9">3.2.2.9</a> Object-Section "iri-notation" Field . . . . . . . . <a href="#page-21">21</a>
<a href="#section-3.2.2.10">3.2.2.10</a> Object-Section "identifier" Field . . . . . . . . <a href="#page-21">21</a>
<a href="#section-3.2.2.11">3.2.2.11</a> Object-Section "standardized-id" Field . . . . . . <a href="#page-21">21</a>
<a href="#section-3.2.2.12">3.2.2.12</a> Object-Section "unicode-label" Field . . . . . . . <a href="#page-21">21</a>
<a href="#section-3.2.2.13">3.2.2.13</a> Object-Section "long-arc" Field . . . . . . . . . <a href="#page-21">21</a>
<span class="grey">Marschall [Page 2]</span></pre>
</div><div class="page"><span class="noprint" id="page-3"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<a href="#section-3.2.2.14">3.2.2.14</a> Object-Section "oidip-service" Field . . . . . . . <a href="#page-22">22</a>
<a href="#section-3.2.2.15">3.2.2.15</a> Object-Section "oidip-pubkey" Field . . . . . . . <a href="#page-22">22</a>
<a href="#section-3.2.2.16">3.2.2.16</a> Object-Section "attribute" Field . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-3.2.2.17">3.2.2.17</a> Object-Section "parent" Field . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-3.2.2.18">3.2.2.18</a> Object-Section "subordinate" Field . . . . . . . . <a href="#page-23">23</a>
<a href="#section-3.2.2.19">3.2.2.19</a> Object-Section "created" Field . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-3.2.2.20">3.2.2.20</a> Object-Section "updated" Field . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-3.2.2.21">3.2.2.21</a> Object-Section Other Fields . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-3.2.3">3.2.3</a> RA-Section (Information about the Current RA) . . . . . <a href="#page-24">24</a>
<a href="#section-3.2.3.1">3.2.3.1</a> RA-Section "ra" Field . . . . . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-3.2.3.2">3.2.3.2</a> RA-Section "ra-status" Field . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-3.2.3.3">3.2.3.3</a> RA-Section "ra-lang" Field . . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-3.2.3.4">3.2.3.4</a> RA-Section "ra-contact-name" Field . . . . . . . . <a href="#page-24">24</a>
<a href="#section-3.2.3.5">3.2.3.5</a> RA-Section "ra-address" Field . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-3.2.3.6">3.2.3.6</a> RA-Section "ra-phone" Field . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-3.2.3.7">3.2.3.7</a> RA-Section "ra-mobile" Field . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-3.2.3.8">3.2.3.8</a> RA-Section "ra-fax" Field . . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-3.2.3.9">3.2.3.9</a> RA-Section "ra-email" Field . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-3.2.3.10">3.2.3.10</a> RA-Section "ra-url" Field . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-3.2.3.11">3.2.3.11</a> RA-Section "ra-attribute" Field . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-3.2.3.12">3.2.3.12</a> RA-Section "ra-created" Field . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-3.2.3.13">3.2.3.13</a> RA-Section "ra-updated" Field . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-3.2.3.14">3.2.3.14</a> RA-Section Other Fields . . . . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-3.2.4">3.2.4</a> Sections for Previous Registration Authorities . . . . <a href="#page-26">26</a>
<a href="#section-3.3">3.3</a> Digital Signature . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-3.3.1">3.3.1</a> "text" Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-3.3.2">3.3.2</a> "json" Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-3.3.3">3.3.3</a> "xml" Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#section-3.4">3.4</a> Date/Time Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#section-3.4.1">3.4.1</a> Date/Time Format ABNF Notation . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#section-3.4.2">3.4.2</a> Date/Time Format Examples . . . . . . . . . . . . . . . <a href="#page-29">29</a>
<a href="#section-3.5">3.5</a> HTTP Response Status Codes . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
<a href="#section-4">4</a> Referral . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-31">31</a>
<a href="#section-5">5</a> Full Example ("text" Format) . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
<a href="#section-5.1">5.1</a> Request . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
<a href="#section-5.2">5.2</a> Response . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
<a href="#section-6">6</a> Alternative Namespaces . . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
<a href="#section-6.1">6.1</a> Example: UUID Namespace . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
<a href="#section-6.1.1">6.1.1</a> Request . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
<a href="#section-6.1.2">6.1.2</a> Response . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
<a href="#section-7">7</a> Internationalization Considerations . . . . . . . . . . . . . . <a href="#page-34">34</a>
<a href="#section-8">8</a> Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-35">35</a>
<a href="#section-9">9</a> RA Considerations . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-36">36</a>
<a href="#section-10">10</a> References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-36">36</a>
<a href="#section-10.1">10.1</a> Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-36">36</a>
<a href="#section-10.2">10.2</a> Informative References . . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>
<a href="#appendix-A">Appendix A</a>. JSON Format Schema and Example . . . . . . . . . . . <a href="#page-40">40</a>
<a href="#appendix-A.1">Appendix A.1</a>. JSON Format Schema . . . . . . . . . . . . . . . . <a href="#page-40">40</a>
<span class="grey">Marschall [Page 3]</span></pre>
</div><div class="page"><span class="noprint" id="page-4"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<a href="#appendix-A.2">Appendix A.2</a>. JSON Format Example of Output . . . . . . . . . . . <a href="#page-49">49</a>
<a href="#appendix-B">Appendix B</a>. XML Format Schema and Example . . . . . . . . . . . . <a href="#page-51">51</a>
<a href="#appendix-B.1">Appendix B.1</a>. XML Format Schema . . . . . . . . . . . . . . . . . <a href="#page-51">51</a>
<a href="#appendix-B.2">Appendix B.2</a>. XML Format Example of Output . . . . . . . . . . . <a href="#page-60">60</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-62">62</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-62">62</a>
<span class="grey">Marschall [Page 4]</span></pre>
</div><div class="page"><span class="noprint" id="page-5"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<h2><a class="selflink" id="section-1" href="#section-1">1</a> Introduction</h2>
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 [<a href="#ref-X660" title=""Information technology - Procedures for the operation of object identifier registration authorities: General procedures and top arcs of the international object identifier tree"">X660</a>].
There are a few methods of retrieving information about an OID, like:
(A) Searching through web repositories like <<a href="http://www.oid-info.com">http://www.oid-info.com</a>>
or <<a href="http://www.alvestrand.no/objectid/">http://www.alvestrand.no/objectid/</a>>. 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 [<a href="#ref-X672" title=""Information technology - Open systems interconnection - Object identifier resolution system"">X672</a>]. 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 [<a href="#ref-X509" title=""Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks"">X509</a>] 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) [<a href="https://datatracker.ietf.org/doc/html/rfc1157" title=""Simple Network Management Protocol (SNMP)"">RFC1157</a>] 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) [<a href="https://datatracker.ietf.org/doc/html/rfc4511" title=""Lightweight Directory Access Protocol (LDAP): The Protocol"">RFC4511</a>], applications could query the name of
attributes that are described by an OID the application doesn't
know.
<span class="grey">Marschall [Page 5]</span></pre>
</div><div class="page"><span class="noprint" id="page-6"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<h3><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> Terminology</h3>
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
<a href="https://datatracker.ietf.org/doc/html/bcp14">BCP 14</a> [<a href="https://datatracker.ietf.org/doc/html/rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="https://datatracker.ietf.org/doc/html/rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] 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 [<a href="https://datatracker.ietf.org/doc/html/rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>].
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
[<a href="https://datatracker.ietf.org/doc/html/rfc9112">RFC9112</a>].
JSON JavaScript Object Notation, an open standard file
format and data interchange format, as defined in
[<a href="https://datatracker.ietf.org/doc/html/rfc8259" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC8259</a>].
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
[<a href="https://datatracker.ietf.org/doc/html/rfc3629" title=""UTF-8, a transformation format of ISO 10646"">RFC3629</a>].
XML Extensible Markup Language, a markup language and file
format for storing, transmitting, and reconstructing
arbitrary data ([<a href="#ref-XML" title=""Extensible Markup Language (XML) 1.1 (Second Edition)"">XML</a>]).
<span class="grey">Marschall [Page 6]</span></pre>
</div><div class="page"><span class="noprint" id="page-7"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<h2><a class="selflink" id="section-2" href="#section-2">2</a> Request</h2>
OID Information Protocol (OID-IP) is a text-based protocol that is
built on top of the Hypertext Transfer Protocol [<a href="https://datatracker.ietf.org/doc/html/rfc9112">RFC9112</a>] as defined
in <a href="#section-2.1">section 2.1</a> and/or the WHOIS protocol [<a href="https://datatracker.ietf.org/doc/html/rfc3912" title=""WHOIS Protocol Specification"">RFC3912</a>] as defined in
<a href="#section-2.2">section 2.2</a>. (The concept of OID-IP was established in 2011 and is
already implemented by several vendors, hence WHOIS is part of this
specification.)
<h3><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Request via HTTP(S) Protocol (Recommended)</h3>
<h4><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a> Request Method and Path</h4>
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 <a href="#section-6">section 6</a>).
<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 <a href="https://datatracker.ietf.org/doc/html/rfc3061#section-2">RFC 3061, section 2</a> [<a href="https://datatracker.ietf.org/doc/html/rfc3061" title=""A URN Namespace of Object Identifiers"">RFC3061</a>], 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 <a href="#section-2.1.2">section 2.1.2</a>.
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.
<span class="grey">Marschall [Page 7]</span></pre>
</div><div class="page"><span class="noprint" id="page-8"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
This document describes the following additional GET/POST parameters:
(1) Authentication tokens ("auth" parameter), which is described in
<a href="#section-2.1.3">section 2.1.3</a>.
(2) Preferred language ("lang" parameter), which is described in
<a href="#section-2.1.4">section 2.1.4</a>.
Constraints for custom input parameters are described in
<a href="#section-2.1.5">section 2.1.5</a>.
<h4><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a> Formats and Content-Types</h4>
This document defines 3 formats:
(1) "text": A text representation as defined in <a href="#section-3.1.1">section 3.1.1</a>
(MANDATORY). The "Content-Type" response header MUST be
"text/vnd.viathinksoft.oidip".
(2) "json": The JavaScript Object Notation (JSON, [<a href="https://datatracker.ietf.org/doc/html/rfc8259" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC8259</a>])
representation as defined in <a href="#section-3.1.2">section 3.1.2</a> (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, [<a href="#ref-XML" title=""Extensible Markup Language (XML) 1.1 (Second Edition)"">XML</a>]) representation as
defined in <a href="#section-3.1.3">section 3.1.3</a> (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 <a href="#section-3.2.1">section 3.2.1</a>), and MUST be sending
the HTTP response code "400 Bad Request".
<span class="grey">Marschall [Page 8]</span></pre>
</div><div class="page"><span class="noprint" id="page-9"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<h4><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a> Authentication</h4>
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 <a href="https://datatracker.ietf.org/doc/html/rfc9110">RFC 9110</a> 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 <a href="#section-8">section 8</a>
"Security Considerations".
The usage of authentication is OPTIONAL.
<span class="grey">Marschall [Page 9]</span></pre>
</div><div class="page"><span class="noprint" id="page-10"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<h4><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a> Preferred Language</h4>
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 [<a href="https://datatracker.ietf.org/doc/html/rfc5646" title=""Tags for Identifying Languages"">RFC5646</a>], 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.
<h4><a class="selflink" id="section-2.1.5" href="#section-2.1.5">2.1.5</a> Custom Input Parameters</h4>
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.
<span class="grey">Marschall [Page 10]</span></pre>
</div><div class="page"><span class="noprint" id="page-11"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<h4><a class="selflink" id="section-2.1.6" href="#section-2.1.6">2.1.6</a> Cookies</h4>
The presence (or absence) of cookies MUST NOT make any difference to
the OID-IP output. Cookies MUST NOT be used for authentication.
<h3><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Request via WHOIS Protocol (Backwards Compatibility)</h3>
<h4><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a> Request Method</h4>
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.
<h5><a class="selflink" id="section-2.2.1.1" href="#section-2.2.1.1">2.2.1.1</a> Basic Query String</h5>
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 <a href="#section-6">section 6</a>), 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 <a href="https://datatracker.ietf.org/doc/html/rfc3061#section-2">RFC 3061, section 2</a>
[<a href="https://datatracker.ietf.org/doc/html/rfc3061" title=""A URN Namespace of Object Identifiers"">RFC3061</a>], 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
<span class="grey">Marschall [Page 11]</span></pre>
</div><div class="page"><span class="noprint" id="page-12"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
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.
<h5><a class="selflink" id="section-2.2.1.2" href="#section-2.2.1.2">2.2.1.2</a> Input Parameters</h5>
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 <a href="#section-2.2.2">section 2.2.2</a>.
(2) Authentication tokens ("auth" argument), which is described in
<a href="#section-2.2.3">section 2.2.3</a>.
(3) Preferred language ("lang" argument), which is described in
<a href="#section-2.2.4">section 2.2.4</a>.
Constraints for custom input parameters are described in
<a href="#section-2.2.5">section 2.2.5</a>.
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
<h5><a class="selflink" id="section-2.2.1.3" href="#section-2.2.1.3">2.2.1.3</a> Request ABNF Notation</h5>
To define the query string, the following Augmented BNF definitions
will be used. They are based on the ABNF styles of <a href="https://datatracker.ietf.org/doc/html/rfc5234">RFC 5234</a>
[<a href="https://datatracker.ietf.org/doc/html/rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>].
query = object optional-args
object = ( str-oid ":" optional-oid ) /
( other-ns-name ":" other-ns-val )
str-oid = %x6F.69.64 ; %s"oid" in <a href="https://datatracker.ietf.org/doc/html/rfc7405">RFC 7405</a>
<span class="grey">Marschall [Page 12]</span></pre>
</div><div class="page"><span class="noprint" id="page-13"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
; 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 <a href="https://datatracker.ietf.org/doc/html/rfc7405">RFC 7405</a>
str-auth = %x61.75.74.68 ; %s"auth" in <a href="https://datatracker.ietf.org/doc/html/rfc7405">RFC 7405</a>
str-lang = %x6C.61.6E.67 ; %s"lang" in <a href="https://datatracker.ietf.org/doc/html/rfc7405">RFC 7405</a>
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 <a href="https://datatracker.ietf.org/doc/html/rfc7405">RFC 7405</a>
str-json = %x6A.73.6F.6E ; %s"json" in <a href="https://datatracker.ietf.org/doc/html/rfc7405">RFC 7405</a>
str-xml = %x78.6D.6C ; %s"xml" in <a href="https://datatracker.ietf.org/doc/html/rfc7405">RFC 7405</a>
; Language-Tag is defined in <a href="https://datatracker.ietf.org/doc/html/rfc5646">RFC 5646</a>
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 )
<span class="grey">Marschall [Page 13]</span></pre>
</div><div class="page"><span class="noprint" id="page-14"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
unsigned-number = "0" / ( nonzero-digit *digit )
digit = %x30-39 ; 0-9
nonzero-digit = %x31-39 ; 1-9
lowercase-char = %x61-7A ; a-z
<h4><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a> Format ("format" Argument)</h4>
The "format" argument defines the desired output format.
This document defines 3 formats:
(1) "text": A text representation as defined in <a href="#section-3.1.1">section 3.1.1</a>
(MANDATORY).
(2) "json": The JavaScript Object Notation (JSON, [<a href="https://datatracker.ietf.org/doc/html/rfc8259" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC8259</a>])
representation as defined in <a href="#section-3.1.2">section 3.1.2</a> (RECOMMENDED).
(3) "xml": Extensible Markup Language (XML, [<a href="#ref-XML" title=""Extensible Markup Language (XML) 1.1 (Second Edition)"">XML</a>]) representation as
defined in <a href="#section-3.1.3">section 3.1.3</a> (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 <a href="#section-3.2.1">section 3.2.1</a>).
The usage of the argument "format" is OPTIONAL.
<h4><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a> Authentication Tokens ("auth" Argument)</h4>
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
(",").
<span class="grey">Marschall [Page 14]</span></pre>
</div><div class="page"><span class="noprint" id="page-15"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
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 <a href="#section-8">section 8</a> "Security Considerations".
The usage of the argument "auth" is OPTIONAL.
<h4><a class="selflink" id="section-2.2.4" href="#section-2.2.4">2.2.4</a> Preferred Language ("lang" Argument)</h4>
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 [<a href="https://datatracker.ietf.org/doc/html/rfc5646" title=""Tags for Identifying Languages"">RFC5646</a>], 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.
<span class="grey">Marschall [Page 15]</span></pre>
</div><div class="page"><span class="noprint" id="page-16"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
<h4><a class="selflink" id="section-2.2.5" href="#section-2.2.5">2.2.5</a> Custom Input Parameters</h4>
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.
<h2><a class="selflink" id="section-3" href="#section-3">3</a> Response</h2>
<h3><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Format and Encoding</h3>
<h4><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a> "text" Format</h4>
(1) The response MUST be UTF-8 encoded (as defined in <a href="https://datatracker.ietf.org/doc/html/rfc3629">RFC 3629</a>
[<a href="https://datatracker.ietf.org/doc/html/rfc3629" title=""UTF-8, a transformation format of ISO 10646"">RFC3629</a>]), 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 <a href="#section-3.3">section 3.3</a> "Digital Signature").
<span class="grey">Marschall [Page 16]</span></pre>
</div><div class="page"><span class="noprint" id="page-17"><span class="grey">VTS/WF STD. 2 OID Information Protocol 2 September 2024</span>
(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.
<h4><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a> "json" Format</h4>
(1) The response MUST be UTF-8 encoded (as defined in <a href="https://datatracker.ietf.org/doc/html/rfc3629">RFC 3629</a>
[<a href="https://datatracker.ietf.org/doc/html/rfc3629" title=""UTF-8, a transformation format of ISO 10646"">RFC3629</a>]), 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, [<a href="https://datatracker.ietf.org/doc/html/rfc8259" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC8259</a>]) output MUST
match the schema defined in <a href="#appendix-A.1">Appendix A.1</a> of this document.
<h4><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a> "xml" Format</h4>
(1) The response MUST be UTF-8 encoded (as defined in <a href="https://datatracker.ietf.org/doc/html/rfc3629">RFC 3629</a>
[<a href="https://datatracker.ietf.org/doc/html/rfc3629" title=""UTF-8, a transformation format of ISO 10646"">RFC3629</a>]), without Byte-Order-Mark (BOM).