Details | Last modification | View Log | RSS feed
| Rev | Author | Line No. | Line |
|---|---|---|---|
| 226 | daniel-mar | 1 | <html> |
| 2 | |||
| 3 | <head> |
||
| 4 | <meta http-equiv="Content-Type" |
||
| 5 | content="text/html; charset=iso-8859-1"> |
||
| 6 | <meta name="GENERATOR" content="Microsoft FrontPage Express 2.0"> |
||
| 7 | <title>OIDDB Format</title> |
||
| 8 | </head> |
||
| 9 | |||
| 10 | <body> |
||
| 11 | |||
| 12 | <h1>"OIDDB/0.1" <font color="red">DRAFT</font> file format description and examples</h1> |
||
| 13 | |||
| 14 | <p>(C) 2012 ViaThinkSoft, Daniel Marschall</p> |
||
| 15 | |||
| 16 | <h2>Intended purpose</h2> |
||
| 17 | |||
| 18 | <ul> |
||
| 19 | <li>This format describes an OID tree resp. a part of an OID |
||
| 20 | tree</li> |
||
| 21 | <li>Main purpose: Format for the OID tree viewer "OID |
||
| 22 | Plus" by ViaThinkSoft, which is intended for smaller |
||
| 23 | registration authorities who need a simply way to manage |
||
| 24 | their OID allocations as well as present their tree to |
||
| 25 | the public</li> |
||
| 26 | <li>Another purpose can be to create a more simple |
||
| 27 | alternative to ORS</li> |
||
| 28 | <li>Maybe the format could be globally describe OIDs as an |
||
| 29 | open and human readable format, maybe also for |
||
| 30 | interchanging informations</li> |
||
| 31 | </ul> |
||
| 32 | |||
| 33 | <h2>Use cases</h2> |
||
| 34 | |||
| 35 | <ul> |
||
| 36 | <li>Easily administrate, delegate and display the tree for a |
||
| 37 | specific RA</li> |
||
| 38 | <li>Look up an OID by identifier, unicode label (like ORS) or |
||
| 39 | by numerical value => Alternative to ORS</li> |
||
| 40 | </ul> |
||
| 41 | |||
| 42 | <h2>Advantages</h2> |
||
| 43 | |||
| 44 | <ul> |
||
| 45 | <li>Highly scaleable: No database needed. The "zones" |
||
| 46 | are working fine just with textfiles, but dynamic |
||
| 47 | generated records are also OK!</li> |
||
| 48 | <li>Node can be delegated, which makes this format also |
||
| 49 | suitable as an alternative to the complex ORS</li> |
||
| 50 | <li>Format can be extended easily</li> |
||
| 51 | <li>No individual name server necessary for ORS functionality</li> |
||
| 52 | <li>HTTPS connections are no problem</li> |
||
| 53 | <li>File can be easily filtered by "grep" because |
||
| 54 | every line contains just 1 attribute and contains the OID |
||
| 55 | "zone"</li> |
||
| 56 | <li>Simplyness: The main format is simply: <root zone> |
||
| 57 | <attribute> <params></li> |
||
| 58 | </ul> |
||
| 59 | |||
| 60 | <h2>Disadvantages</h2> |
||
| 61 | |||
| 62 | <ul> |
||
| 63 | <li>The FORMAT itself allows also illegal labels etc. The OID |
||
| 64 | viewer has to check all data for validity</li> |
||
| 65 | </ul> |
||
| 66 | |||
| 67 | <h2>Format</h2> |
||
| 68 | |||
| 69 | <ul> |
||
| 70 | <li>Each zone file begins with "[OIDDB/0.1]" in the |
||
| 71 | first line.</li> |
||
| 72 | <li>Whitespaces at the beginning or end of every line (except |
||
| 73 | first line) are tolerated</li> |
||
| 74 | <li>Every line contains either '#' (comment line) or a <zone |
||
| 75 | record></li> |
||
| 76 | <li>Comments cannot be in the same line as a zone record! |
||
| 77 | They need an separate line.</li> |
||
| 78 | <li><zone record> is defined as <zone> <attribute> |
||
| 79 | <parameters></li> |
||
| 80 | <li><zone> is either an dot-notation OID or "root" |
||
| 81 | (root is the "zone" which delegates the OIDS 0, |
||
| 82 | 1 and 2).</li> |
||
| 83 | <li><attribute> is an attribute in uppercase (see below |
||
| 84 | for valid attributes and their <parameters>)</li> |
||
| 85 | <li>Between zone, attribute and parameters there are |
||
| 86 | whitespaces (but no line break)</li> |
||
| 87 | <li>If an attribute is unknown by the client, it will be |
||
| 88 | simply ignored</li> |
||
| 89 | </ul> |
||
| 90 | |||
| 91 | <h2>Current list of attributes</h2> |
||
| 92 | |||
| 93 | <table border="2"> |
||
| 94 | <tr> |
||
| 95 | <td><strong>Attribute</strong></td> |
||
| 96 | <td><strong>Inherited from parent</strong></td> |
||
| 97 | <td><strong>Scope [1]</strong></td> |
||
| 98 | <td><strong>Parameters</strong></td> |
||
| 99 | <td><strong>Comments</strong></td> |
||
| 100 | </tr> |
||
| 101 | <tr> |
||
| 102 | <td>SOA (valid for all NIDs)</td> |
||
| 103 | <td>No</td> |
||
| 104 | <td>LOCAL RA</td> |
||
| 105 | <td>None</td> |
||
| 106 | <td>Place holder if no delegations or attributes are available for this object.</td> |
||
| 107 | </tr> |
||
| 108 | <tr> |
||
| 109 | <td>RA</td> |
||
| 110 | <td>If not set [3]</td> |
||
| 111 | <td>LOCAL RA</td> |
||
| 112 | <td>"<RA contact information, human-readable, '\n' |
||
| 113 | allowed>"</td> |
||
| 114 | <td>[7]</td> |
||
| 115 | </tr> |
||
| 116 | <tr> |
||
| 117 | <td>NAME</td> |
||
| 118 | <td>No</td> |
||
| 119 | <td>LOCAL RA</td> |
||
| 120 | <td>"<Single line name resp very short |
||
| 121 | description>"</td> |
||
| 122 | <td> </td> |
||
| 123 | </tr> |
||
| 124 | <tr> |
||
| 125 | <td>DESCRIPTION</td> |
||
| 126 | <td>No</td> |
||
| 127 | <td>LOCAL RA</td> |
||
| 128 | <td>"<Description and additional information, |
||
| 129 | human-readable, '\n' allowed>"</td> |
||
| 130 | <td> </td> |
||
| 131 | </tr> |
||
| 132 | <tr> |
||
| 133 | <td>DELEGATION</td> |
||
| 134 | <td>No</td> |
||
| 135 | <td>LOCAL RA</td> |
||
| 136 | <td><numeric child identifier> <zone file |
||
| 137 | location [2]></td> |
||
| 138 | <td> </td> |
||
| 139 | </tr> |
||
| 140 | <tr> |
||
| 141 | <td>PRIVATECHILD</td> |
||
| 142 | <td>No</td> |
||
| 143 | <td>LOCAL RA</td> |
||
| 144 | <td><numeric child identifier></td> |
||
| 145 | <td> </td> |
||
| 146 | </tr> |
||
| 147 | <tr> |
||
| 148 | <td>NUMSECRETCHILDREN</td> |
||
| 149 | <td>No</td> |
||
| 150 | <td>LOCAL RA</td> |
||
| 151 | <td><number of childnodes which are NOT listed as |
||
| 152 | CHILD or PRIVATECHILD (i.e. their numerical values are |
||
| 153 | secret)></td> |
||
| 154 | <td> </td> |
||
| 155 | </tr> |
||
| 156 | <tr> |
||
| 157 | <td>IDENTIFIER</td> |
||
| 158 | <td>No</td> |
||
| 159 | <td>SUPERIOR RA</td> |
||
| 160 | <td><identifier value, e.g. example> <numeric |
||
| 161 | child identifier, e.g. 999></td> |
||
| 162 | <td> </td> |
||
| 163 | </tr> |
||
| 164 | <tr> |
||
| 165 | <td>UNICODELABEL</td> |
||
| 166 | <td>No</td> |
||
| 167 | <td>SUPERIOR RA</td> |
||
| 168 | <td><Unicode label, e.g. ViaThinkSoft> <numeric |
||
| 169 | child identifier, e.g. 12345></td> |
||
| 170 | <td>[4]</td> |
||
| 171 | </tr> |
||
| 172 | <tr> |
||
| 173 | <td>FLAG-DRAFT</td> |
||
| 174 | <td>Yes, cannot be unset</td> |
||
| 175 | <td>SUPERIOR RA</td> |
||
| 176 | <td><numeric child identifier></td> |
||
| 177 | <td>[5]</td> |
||
| 178 | </tr> |
||
| 179 | <tr> |
||
| 180 | <td>FLAG-LEAF</td> |
||
| 181 | <td>Yes, cannot be unset</td> |
||
| 182 | <td>SUPERIOR RA</td> |
||
| 183 | <td><numeric child identifier></td> |
||
| 184 | <td>[6]</td> |
||
| 185 | </tr> |
||
| 186 | </table> |
||
| 187 | |||
| 188 | <p>Remarks:</p> |
||
| 189 | |||
| 190 | <ol> |
||
| 191 | <li>Defines who may change the attribute for a given OID<br> |
||
| 192 | LOCAL = (Attributes the local RA can change by itself)<br> |
||
| 193 | SUPERIOR RA = (Attributes only the superior RA can change)</li> |
||
| 194 | <li>Zone location. There are 3 possibilities:<br> |
||
| 195 | A) URL where the zone informations of the child are |
||
| 196 | stored.<br> |
||
| 197 | <font color="#FF8000">?? should local file references be |
||
| 198 | accepted ???</font><br> |
||
| 199 | Relative urls shall be accepted.<br> |
||
| 200 | Please note: IDNs (Unicode domain name which needs to be |
||
| 201 | translated into punycode first) shall be accepted by the |
||
| 202 | client.<br> |
||
| 203 | FTP URLs shall be accepted.<br> |
||
| 204 | HTTPS MUST be accepted by the client. Only with HTTPS, |
||
| 205 | informations can be ensured authorative.<br> |
||
| 206 | Also note that the URL can be a simple TXT file or a PHP |
||
| 207 | script which generates the record files from a database |
||
| 208 | etc. This makes delegation pretty flexible.<br> |
||
| 209 | B) "<here>" (without quotes), if the zone |
||
| 210 | informations are stored in the same file<br> |
||
| 211 | C) "<none>" (without quotes) if no zone |
||
| 212 | exists yet resp. if the child is a leaf node. But if you want to set a RA, description or name, you have to create a zone for this OID, since the superior OID cannot define these attributes.</li> |
||
| 213 | <li>If the RA attribute is NOT set locally, it will be |
||
| 214 | INHERITED from the superior OID! This makes it very easy |
||
| 215 | for companies who have many OIDs. They only need to |
||
| 216 | change the RA for children they delegate to another |
||
| 217 | person/department.</li> |
||
| 218 | <li>It could be also an longarc definition, e.g. "root |
||
| 219 | UNICODELABEL Example 2.999"</li> |
||
| 220 | <li>(Idea by Daniel Marschall) This indicates that the OID is |
||
| 221 | a draft resp reserved. It can be removed or changed at |
||
| 222 | ANY TIME. An OID viewer/resolver SHOULD NOT DISPLAY DRAFT-OIDS. |
||
| 223 | THESE ENTRIES ARE USUALLY PRIVATE FOR THE OID RA, e.g. |
||
| 224 | when they draft some new software which is needing an |
||
| 225 | amount of OIDs. An draft OID usually just reserves the |
||
| 226 | OID from accidently getting overwritten by another OID.</li> |
||
| 227 | <li>(Like seen at oid-info.com) This indicates that the OID |
||
| 228 | is a leaf. A parser will stop searching for children, |
||
| 229 | resp. children are locked</li> |
||
| 230 | <li>Note that since the TXT file is publicly available |
||
| 231 | through HTTP(S), the RA contact information cannot be |
||
| 232 | made private. If you'd like to be private, just don't |
||
| 233 | enter your address. You can also e.g. publish a handle |
||
| 234 | number which can be used to contact you resp. a URL to an |
||
| 235 | online contact form.</li> |
||
| 236 | </ol> |
||
| 237 | |||
| 238 | <h2>EXAMPLE 1: USING OID PLUS FOR MANAGING THE WHOLE OID TREE AS |
||
| 239 | AN ALTERNATIVE FOR ORS</h2> |
||
| 240 | |||
| 241 | <p>Making ORS easier would mean:</p> |
||
| 242 | |||
| 243 | <ul> |
||
| 244 | <li>People without an own nameserver could implement ORS (note |
||
| 245 | that nearly no public available DNS hosting company |
||
| 246 | allows customers to create NAPTR records!)</li> |
||
| 247 | <li>The easier, the faster it is implemented world wide</li> |
||
| 248 | </ul> |
||
| 249 | |||
| 250 | <p>In our example of an ORS-alternative, the resolution would start at https://root.ors.example.com/ with the entry "root". It does not matter if the first arc you want to resolve is an numeric identifier, or an alpha identifier or an non-numeric Unicode label.</p> |
||
| 251 | |||
| 252 | <pre><strong>[OIDDB/0.1]</strong> |
||
| 253 | |||
| 254 | <font color="#000080"># ------------------------- |
||
| 255 | # ROOT ZONE FILE WHICH DEFINES THE ATTRIBUTES OF THE OIDS 0, 1 AND 2 AS WELL AS LONGARCS |
||
| 256 | # -------------------------</font> |
||
| 257 | |||
| 258 | oid: UNICODELABEL ISO 0 |
||
| 259 | oid: IDENTIFIER iso 0 |
||
| 260 | oid: DELEGATION 0 https://iso.example.com/zone_record.php?oid=0 |
||
| 261 | |||
| 262 | oid: IDENTIFIER itu-t 1 |
||
| 263 | oid: IDENTIFIER itu-r 1 |
||
| 264 | oid: IDENTIFIER ccitt 1 |
||
| 265 | oid: DELEGATION 1 https://itu.example.com/zone_1.txt |
||
| 266 | |||
| 267 | oid: IDENTIFIER joint-iso-itu-t 2 |
||
| 268 | oid: IDENTIFIER joint-iso-ccitt 2 |
||
| 269 | oid: DELEGATION 2 <here> |
||
| 270 | |||
| 271 | <font color="#000080"># Longarcs</font> |
||
| 272 | oid: UNICODELABEL Example 2.999 |
||
| 273 | |||
| 274 | <font color="#000080"># ------------------------- |
||
| 275 | # ZONE FILE FOR OID "2" |
||
| 276 | # -------------------------</font> |
||
| 277 | |||
| 278 | oid:2 RA "RA information about Joint ISO/ITU-T" |
||
| 279 | oid:2 DELEGATION 999 <here> |
||
| 280 | oid:2 FLAG-LEAF 999 |
||
| 281 | |||
| 282 | <font color="#000080"># ------------------------- |
||
| 283 | # ZONE FILE FOR OID "2.999" |
||
| 284 | # -------------------------</font> |
||
| 285 | |||
| 286 | oid:2.999 RA "None" |
||
| 287 | oid:2.999 NAME "Example OID" |
||
| 288 | oid:2.999 DESCRIPTION "This OID is used as example"</pre> |
||
| 289 | |||
| 290 | <h2>EXAMPLE 2: HOW A SMALL COMPANY WHICH OWNS THE OID 2.999.1.2.3 |
||
| 291 | COULD MANAGE ITS OID TREE WITH A SINGLE TXT FILE</h2> |
||
| 292 | |||
| 293 | <p>They simply create this text file and tell "OID Plus" |
||
| 294 | to use this textfile as root for displaying/querying everything. |
||
| 295 | Also, the root OIDs have to be specified (2.999.1.2.3)</p> |
||
| 296 | |||
| 297 | <pre><strong>[OIDDB/0.1]</strong> |
||
| 298 | |||
| 299 | <font color="#000080"># ------------------------- |
||
| 300 | # ZONE 2.999.1.2.3</font> |
||
| 301 | <font color="#000080"># ------------------------- |
||
| 302 | </font> |
||
| 303 | oid:2.999.1.2.3 RA "My company" |
||
| 304 | oid:2.999.1.2.3 NAME "My company Root OID" |
||
| 305 | oid:2.999.1.2.3 DESCRIPTION "This is the OID 2.999.1.2.3 owned by My Company!" |
||
| 306 | oid:2.999.1.2.3 IDENTIFIER four 4 |
||
| 307 | oid:2.999.1.2.3 IDENTIFIER vier 4 |
||
| 308 | oid:2.999.1.2.3 IDENTIFIER quattro 4 |
||
| 309 | oid:2.999.1.2.3 UNICODELABEL FOUR 4 |
||
| 310 | oid:2.999.1.2.3 UNICODELABEL VIER 4 |
||
| 311 | oid:2.999.1.2.3 UNICODELABEL QUATTRO 4 |
||
| 312 | oid:2.999.1.2.3 DELEGATION 4 <here> |
||
| 313 | oid:2.999.1.2.3 FLAG-LEAF 4 |
||
| 314 | oid:2.999.1.2.3 FLAG-DRAFT 4 |
||
| 315 | |||
| 316 | oid:2.999.1.2.3 PRIVATECHILD 5 |
||
| 317 | oid:2.999.1.2.3 PRIVATECHILD 6 |
||
| 318 | oid:2.999.1.2.3 PRIVATECHILD 7 |
||
| 319 | |||
| 320 | <font color="#000080"># There are 100 secret children, 3 private children (id 5, 6 and 7) and 1 public child (id 4), so 2.999.1.2.3 has 104 child nodes in total</font> |
||
| 321 | oid:2.999.1.2.3 NUMSECRETCHILDREN 100 |
||
| 322 | |||
| 323 | <font color="#000080"># ------------------------- |
||
| 324 | # ZONE 2.999.1.2.3.4</font> |
||
| 325 | <font color="#000080"># ------------------------- |
||
| 326 | </font> |
||
| 327 | oid:2.999.1.2.3.4 NAME "Cup of tea" |
||
| 328 | oid:2.999.1.2.3.4 DESCRIPTION "This is the OID 2.999.1.2.3.4!"</pre> |
||
| 329 | |||
| 330 | <p>Beside "oid" there could be also other NIDs like e.g. "clsid" or "doi" which can be also delegated. |
||
| 331 | Note that the attribute IDs, e.g. unicodelabel are dependent to the NID oid, e.g. the attribute "unicodelabel" |
||
| 332 | should behave different on a oid than for a clsid.</p> |
||
| 333 | |||
| 334 | <h2>More ideas / TODO</h2> |
||
| 335 | |||
| 336 | <ul> |
||
| 337 | <li>Add more attributes. Research more use cases</li> |
||
| 338 | <li>Implement client "OID Plus" with real-world |
||
| 339 | example "ViaThinkSoft RA"</li> |
||
| 340 | <li>Attribute: Information how to obtain a child</li> |
||
| 341 | <li>Erweiterung um java-packagenamen auf die selbe weise zu |
||
| 342 | verwalten</li> |
||
| 343 | <li>Attributes as OIDs: vmd attribute? identified by attr-oid. |
||
| 344 | "X" am anfang bei fremden herstellern</li> |
||
| 345 | <li>Tool that checks the validity of everything (identifier, leaf status etc)</li> |
||
| 346 | </ul> |
||
| 347 | </body> |
||
| 348 | </html> |