Rules and Assignment Advisory

Go back to: Documents and resources

Last revision: 15 April 2019

Table of contents

Organization Root OID

Registration Authority

Assignment advisory

OIDs in members(1)

OIDs in products(2)

OIDs in specifications(3)

OIDs in experimental(4)

OIDs in arcs 10, 20, 30, 40, ...

OIDs in freeoid(9000)

OIDs in example(9999)

Recommended contents of an OID registration

Leaf OIDs, Multipurpose OIDs and VMD Object Containers

Necessity of OIDs


Retired and revoked OIDs

Organization Root OID


ASN.1 notation:

{iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 37476}

OID-IRI notation:


The Root OID of ViaThinkSoft is and was assigned by IANA in February 2011. These Private Enterprise Numbers (PEN) OIDs do not have an ASN.1 or IRI identifier. Therefore, no identifiers can be used for describing the ViaThinkSoft Root OID.

Registration Authority

The Registration Authority (RA) of the ViaThinkSoft Root OID is not assigned to a particular person. Instead, it is assigned to a function called "OID Registration Authority" with the redirection email address (Accepted E-Mail-Languages: German and English) to the currently occupied person, which is currently Daniel Marschall. The person behind this function can be exchanged if necessary. All communication should be with this function's email address rather than using the person's own address.

Currently, there is no clear rule about the postal address or phone/fax number of the OID Registration Authority, since ViaThinkSoft is a decentralized group of software developers and therefore the organisation does not have headquarters.

If an OID declaration does not explicitly state a deviating RA, the RA of the parent OID is used. This is called "inherited RA", and is the default behavior of the ViaThinkSoft OIDplus system.

Assignment advisory

OIDs in members(1)

Free arcs delegated to members, not necessarily all third party developers.

OIDs in products(2)

Product specific objects.

For example: ASN.1 modules used in products shall be added here only.

The RA of project arcs are usually assigned to the respective project owners. In case the project owner changes, the OID's RA will be transferred. A function like for the Organization's Root OID does not exist.

OIDs in specifications(3)

Objects, file formats etc. which are not necessarily product specific - especially objects which can be used for data exchange. The child arcs are defined as follows:

misc(0): Everything that does not fit into the other categories.

fileformat(1): Definition of generic (non product specific) data structures which are encoded into files.

algorithm(2): Generic algorithm definitions (not product or programming language specific).

interface(3): Definition of generic interfaces, e.g. COM+ interfaces.

script(4): Script languages.

communication(5): Definitions how systems and applications should communicate. For example, a JSON data structure embedded in another file or transferred inside a foreign protocol. If you want to define a data structure which is saved entirely in a file, then use the arc fileformat(1) instead. If you want to define a data structure which is sent entirely over a TCP/UDP connection, use the arg protocol(2) intead.

protocol(6): Definitions of data structures sent entirely via network, without usage of other protocols (e.g. HTTP).

OIDs in experimental(4)

This arc contains

-          temporary assignments for internal product developments (space holder)


-          permanent assignments for released product developments (betas etc.)

OIDs in arcs 10, 20, 30, 40, ...

Objects which do ONLY apply to ViaThinkSoft specific add-ons, modules, data etc.

Arc oidplus(30) is an exception: It is an automatically managed arc and does not only contain ViaThinkSoft specific objects.

The space between each of these OIDs is reserved for special purposes of the neighbor(s) at the left. For example, the arc 11 is reserved as special addition to the arc 10.

OIDs in freeoid(9000)

Arcs delegated to private persons or small workgroups. Companies should use other services like the Private Enterprise Numbers of IANA, which are also free.

The delegation is automatically done using the web service. The web service ensures that each validated email address only get one OID. The OIDs are numbered sequentially. Using a password, the OID owner can change details of the OID. The Registry is public and contains name and email address of all registered OIDs!

All assignments are permanent, and the authority is completely transferred to the new owner. In case the OID is not used anymore, the owner can simply stop using it. The superior RA (ViaThinkSoft) does not need to be informed about this. The OID will still be publicly listed in the registry.

ViaThinkSoft will only revoke an OID if the request is obviously spam or otherwise false information. In this case, the identifier will still be assigned, but will be listed as revoked OID. The requester loses control over the revoked OID and is not allowed using it.

OIDs in example(9999)

This OID can be used by anyone, without any permission, for the purpose of documenting examples of object identifiers (in the same way as "" is defined in IETF RFC 2606 as an example for web sites).

The arc example(9999) is obsolete and was replaced by 2.999.

Recommended contents of an OID registration

A registration request of an OID should contain:

1.       At least one ASN.1 identifier.
It is recommended to only use 1 identifier. A second identifier should be used only for backwards compatibility or special cases.

2.       An IRI identifier is recommended. Also here, only 1 identifier should be used.

3.       All human readable identifiers should be in English language only.
Additionally, their naming should be consistent.

4.       An English description and additional information.

5.       Deviating Registration Authority, if it is not inherited.

Registrations should be requested via email, and are valid once the request was approved.

Consider using arc 0 for special values only, and start "normal" OIDs with 1, in case you assign them in sequential order.

Registration procedure: The ViaThinkSoft Registration (OIDRA, currently Daniel Marschall) hands out Object Identifier allocations. New ViaThinkSoft Members automatically get an arc assigned under members(1). Project leaders can request an arc inside products(2) that is allocated to their project. The project leader gets then full access to this arc and can allocate OIDs in the OIDplus web interface.

Leaf OIDs, Multipurpose OIDs and VMD Object Containers

A Leaf OID is defined as an OID which shall not contain any subordinate OIDs. The RA should be very careful if they declare an OID as Leaf. However, the guidelines allow that this attribute can be removed afterwards. Beware that the OIDplus system does list available subordinate OIDs even if their parent has the Leaf attribute (the semantic of attributes is intentionally not handled).

Example for useful applications for Leaf OIDs:

-          OIDplus Information Objects

A Multipurpose OID is an OID which can be used for multiple purposes. The intention and main purpose is to use an OID as namespace as well as reference target at the same time. For example: the arc project-xyz(123) can be used as root for this project and will therefore contain OIDs belonging to this project. However, if an application or database like VMD wants to reference to this project using an OID datatype, this OID can be used for this purpose, too. A multipurpose OID has no specified attribute/declaration in the OIDplus system, since any existing OID can be used as reference target per se (and therefore, every existing non-leaf OID can be used as Multipurpose OID).

Example for useful applications for Multipurpose OIDs:

-          Modules

-          VMD Objects

-          Members

-          Projects

It is not recommended to create Leaf OIDs for enumeration purposes only. The creation of a Multipurpose OID is recommended to allow the definition of subordinate OIDs if needed in the future.

It is also not recommended to create Leaf OIDs for enumerations in definitively closed systems (see Necessity of OIDs), for example Lead OIDs that define a version number only.

A special case of Multipurpose OIDs are VMD Container Objects. An object in the VMD database schema consists of an OID data type and a value (for example a string). For example, a data type with OID prename(1) can have the value "John" and the object with the OID familyname(2) can have the value "Doe". It is recommended (but not necessary) to put both name components into one shared superior OID, for example { ... name(123) prename(1) } and { ... name(123) familyname(2) } . Although name(123) is used as Container Data Type, the container data type itself can have a value too. For example, "John Doe". This allows systems who do not know the individual component OIDs to show the name of the person, although they cannot parse the name in detail.

Like the Multipurpose OIDs, there is no declaration/attribute for VMD Container Objects necessary or available, because every existing VMD data type can be used as container for a more specific components or attributes.

Necessity of OIDs

An OID should be used for all extensible systems, but not for internal codes (e.g. Update IDs).

Exception: If the framework or database structure allows or requires an OID for internal codes, then an OID can be created.

OIDs can be defined for systems which do not currently use them. This allows a predefined identifier for future versions, backward compatibility and inclusion in OID based databases like VMD.


OIDs have to be published into the productive OIDplus system which is located at

OIDs can have the attribute "DRAFT". These OIDs are not officially assigned, but their arc value can be reserved for the ongoing implementation. This is an alternative to experimental OIDs.

OIDs are officially assigned if they are published in the productive OIDplus system without DRAFT attribute. They should be shortly posted to

Confidential or Draft OIDs should have the flag "Hidden" in OIDplus, and are therefore not published to the public.

Retired and revoked OIDs

Retired OIDs stay being listed, except for dynamically generated OIDplus Information Objects, and should not be re-allocated.

OIDs can be completely deleted (and therefore later re-allocated) if they are unused, or if all internal (inside ViaThinkSoft) references have been deleted.

Unused or mis-defined OIDs should be deleted/moved if possible.

Share Static link to this page

Object Identifier (OID)
Globally Unique Identifier (GUID)
IPv4 Network Blocks
IPv6 Network Blocks
Register a free OID
Documents and resources
Contact administrator