"OIDDB/0.1" DRAFT file format description and examples
(C) 2012 ViaThinkSoft, Daniel Marschall
Intended purpose
- This format describes an OID tree resp. a part of an OID
tree
- Main purpose: Format for the OID tree viewer "OID
Plus" by ViaThinkSoft, which is intended for smaller
registration authorities who need a simply way to manage
their OID allocations as well as present their tree to
the public
- Another purpose can be to create a more simple
alternative to ORS
- Maybe the format could be globally describe OIDs as an
open and human readable format, maybe also for
interchanging informations
Use cases
- Easily administrate, delegate and display the tree for a
specific RA
- Look up an OID by identifier, unicode label (like ORS) or
by numerical value => Alternative to ORS
Advantages
- Highly scaleable: No database needed. The "zones"
are working fine just with textfiles, but dynamic
generated records are also OK!
- Node can be delegated, which makes this format also
suitable as an alternative to the complex ORS
- Format can be extended easily
- No individual name server necessary for ORS functionality
- HTTPS connections are no problem
- File can be easily filtered by "grep" because
every line contains just 1 attribute and contains the OID
"zone"
- Simplyness: The main format is simply: <root zone>
<attribute> <params>
Disadvantages
- The FORMAT itself allows also illegal labels etc. The OID
viewer has to check all data for validity
Format
- Each zone file begins with "[OIDDB/0.1]" in the
first line.
- Whitespaces at the beginning or end of every line (except
first line) are tolerated
- Every line contains either '#' (comment line) or a <zone
record>
- Comments cannot be in the same line as a zone record!
They need an separate line.
- <zone record> is defined as <zone> <attribute>
<parameters>
- <zone> is either an dot-notation OID or "root"
(root is the "zone" which delegates the OIDS 0,
1 and 2).
- <attribute> is an attribute in uppercase (see below
for valid attributes and their <parameters>)
- Between zone, attribute and parameters there are
whitespaces (but no line break)
- If an attribute is unknown by the client, it will be
simply ignored
Current list of attributes
| Attribute |
Inherited from parent |
Scope [1] |
Parameters |
Comments |
| SOA (valid for all NIDs) |
No |
LOCAL RA |
None |
Place holder if no delegations or attributes are available for this object. |
| RA |
If not set [3] |
LOCAL RA |
"<RA contact information, human-readable, '\n'
allowed>" |
[7] |
| NAME |
No |
LOCAL RA |
"<Single line name resp very short
description>" |
|
| DESCRIPTION |
No |
LOCAL RA |
"<Description and additional information,
human-readable, '\n' allowed>" |
|
| DELEGATION |
No |
LOCAL RA |
<numeric child identifier> <zone file
location [2]> |
|
| PRIVATECHILD |
No |
LOCAL RA |
<numeric child identifier> |
|
| NUMSECRETCHILDREN |
No |
LOCAL RA |
<number of childnodes which are NOT listed as
CHILD or PRIVATECHILD (i.e. their numerical values are
secret)> |
|
| IDENTIFIER |
No |
SUPERIOR RA |
<identifier value, e.g. example> <numeric
child identifier, e.g. 999> |
|
| UNICODELABEL |
No |
SUPERIOR RA |
<Unicode label, e.g. ViaThinkSoft> <numeric
child identifier, e.g. 12345> |
[4] |
| FLAG-DRAFT |
Yes, cannot be unset |
SUPERIOR RA |
<numeric child identifier> |
[5] |
| FLAG-LEAF |
Yes, cannot be unset |
SUPERIOR RA |
<numeric child identifier> |
[6] |
Remarks:
- Defines who may change the attribute for a given OID
LOCAL = (Attributes the local RA can change by itself)
SUPERIOR RA = (Attributes only the superior RA can change)
- Zone location. There are 3 possibilities:
A) URL where the zone informations of the child are
stored.
?? should local file references be
accepted ???
Relative urls shall be accepted.
Please note: IDNs (Unicode domain name which needs to be
translated into punycode first) shall be accepted by the
client.
FTP URLs shall be accepted.
HTTPS MUST be accepted by the client. Only with HTTPS,
informations can be ensured authorative.
Also note that the URL can be a simple TXT file or a PHP
script which generates the record files from a database
etc. This makes delegation pretty flexible.
B) "<here>" (without quotes), if the zone
informations are stored in the same file
C) "<none>" (without quotes) if no zone
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.
- If the RA attribute is NOT set locally, it will be
INHERITED from the superior OID! This makes it very easy
for companies who have many OIDs. They only need to
change the RA for children they delegate to another
person/department.
- It could be also an longarc definition, e.g. "root
UNICODELABEL Example 2.999"
- (Idea by Daniel Marschall) This indicates that the OID is
a draft resp reserved. It can be removed or changed at
ANY TIME. An OID viewer/resolver SHOULD NOT DISPLAY DRAFT-OIDS.
THESE ENTRIES ARE USUALLY PRIVATE FOR THE OID RA, e.g.
when they draft some new software which is needing an
amount of OIDs. An draft OID usually just reserves the
OID from accidently getting overwritten by another OID.
- (Like seen at oid-info.com) This indicates that the OID
is a leaf. A parser will stop searching for children,
resp. children are locked
- Note that since the TXT file is publicly available
through HTTP(S), the RA contact information cannot be
made private. If you'd like to be private, just don't
enter your address. You can also e.g. publish a handle
number which can be used to contact you resp. a URL to an
online contact form.
EXAMPLE 1: USING OID PLUS FOR MANAGING THE WHOLE OID TREE AS
AN ALTERNATIVE FOR ORS
Making ORS easier would mean:
- People without an own nameserver could implement ORS (note
that nearly no public available DNS hosting company
allows customers to create NAPTR records!)
- The easier, the faster it is implemented world wide
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.
[OIDDB/0.1]
# -------------------------
# ROOT ZONE FILE WHICH DEFINES THE ATTRIBUTES OF THE OIDS 0, 1 AND 2 AS WELL AS LONGARCS
# -------------------------
oid: UNICODELABEL ISO 0
oid: IDENTIFIER iso 0
oid: DELEGATION 0 https://iso.example.com/zone_record.php?oid=0
oid: IDENTIFIER itu-t 1
oid: IDENTIFIER itu-r 1
oid: IDENTIFIER ccitt 1
oid: DELEGATION 1 https://itu.example.com/zone_1.txt
oid: IDENTIFIER joint-iso-itu-t 2
oid: IDENTIFIER joint-iso-ccitt 2
oid: DELEGATION 2 <here>
# Longarcs
oid: UNICODELABEL Example 2.999
# -------------------------
# ZONE FILE FOR OID "2"
# -------------------------
oid:2 RA "RA information about Joint ISO/ITU-T"
oid:2 DELEGATION 999 <here>
oid:2 FLAG-LEAF 999
# -------------------------
# ZONE FILE FOR OID "2.999"
# -------------------------
oid:2.999 RA "None"
oid:2.999 NAME "Example OID"
oid:2.999 DESCRIPTION "This OID is used as example"
EXAMPLE 2: HOW A SMALL COMPANY WHICH OWNS THE OID 2.999.1.2.3
COULD MANAGE ITS OID TREE WITH A SINGLE TXT FILE
They simply create this text file and tell "OID Plus"
to use this textfile as root for displaying/querying everything.
Also, the root OIDs have to be specified (2.999.1.2.3)
[OIDDB/0.1]
# -------------------------
# ZONE 2.999.1.2.3
# -------------------------
oid:2.999.1.2.3 RA "My company"
oid:2.999.1.2.3 NAME "My company Root OID"
oid:2.999.1.2.3 DESCRIPTION "This is the OID 2.999.1.2.3 owned by My Company!"
oid:2.999.1.2.3 IDENTIFIER four 4
oid:2.999.1.2.3 IDENTIFIER vier 4
oid:2.999.1.2.3 IDENTIFIER quattro 4
oid:2.999.1.2.3 UNICODELABEL FOUR 4
oid:2.999.1.2.3 UNICODELABEL VIER 4
oid:2.999.1.2.3 UNICODELABEL QUATTRO 4
oid:2.999.1.2.3 DELEGATION 4 <here>
oid:2.999.1.2.3 FLAG-LEAF 4
oid:2.999.1.2.3 FLAG-DRAFT 4
oid:2.999.1.2.3 PRIVATECHILD 5
oid:2.999.1.2.3 PRIVATECHILD 6
oid:2.999.1.2.3 PRIVATECHILD 7
# 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
oid:2.999.1.2.3 NUMSECRETCHILDREN 100
# -------------------------
# ZONE 2.999.1.2.3.4
# -------------------------
oid:2.999.1.2.3.4 NAME "Cup of tea"
oid:2.999.1.2.3.4 DESCRIPTION "This is the OID 2.999.1.2.3.4!"
Beside "oid" there could be also other NIDs like e.g. "clsid" or "doi" which can be also delegated.
Note that the attribute IDs, e.g. unicodelabel are dependent to the NID oid, e.g. the attribute "unicodelabel"
should behave different on a oid than for a clsid.
More ideas / TODO
- Add more attributes. Research more use cases
- Implement client "OID Plus" with real-world
example "ViaThinkSoft RA"
- Attribute: Information how to obtain a child
- Erweiterung um java-packagenamen auf die selbe weise zu
verwalten
- Attributes as OIDs: vmd attribute? identified by attr-oid.
"X" am anfang bei fremden herstellern
- Tool that checks the validity of everything (identifier, leaf status etc)