Gehe zu deutscher Webseite

Information about the ViaThinkSoft OIDs

Click here to open the ViaThinkSoft OID Database

Legacy system (outdated)

Last revision: 14 September 2018

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 oidplus(30) genroot(3)

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.

You can view a list of allocated subsequent OIDs in the OID database.

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 OID+ 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.

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 oidplus(30) genroot(3)

Automatically generated OIDs as references to OID+ information objects, preferable queried by whois.

The OIDs generated in this arc should be considered as temporary only. During version upgrades of the OID+ system, or by changing the information objects, the arc values may change. All OIDs are generated dynamically on-the-fly, using the OID+ information objects. OIDs give the opportunity of linking OID+ Information Objects into the OID tree - this is also necessary, because OID+ is mainly designed to handle OIDs.

The OID+ system only saves the current status of the Information Objects. Deleted, moved or changed Information Objects are not shown or archived anymore - their OID has been revoked.

ViaThinkSoft OID+ is designed to generate OIDs which are worldwide unique, and each generated arc's authority should be absolute. This means that only arcs are generated, where the current system has the full authority of it. There are no arcs which are shared between independent OID+ systems.

"Absolute" does also mean, that the listing of subordinate OIDs has to be complete. This is the reason why e.g. the OID 2.25 (UUID root) or (IANA PEN root) should not be used as shared root for organizations who have multiple PEN's or UUID OIDs, because OID+ cannot list all 2.25 or OIDs - therefore the listing of subordinate OIDs would be incomplete. Also, the OID+ system's owner has not the authority of 2.25 or .


genroot(3) was manually assigned by ViaThinkSoft and is automatically managed by OID+. It should only be used for ViaThinkSoft's OID+ system. Other OID+ systems should use the arc {joint-iso-itu-t(2) uuid(25) <systemid>} or an OID in their own authority, which is only dedicated OID+. They may not use ViaThinkSoft's genroot(3), otherwise, ViaThinkSoft's OID+ listing would not be complete anymore. All automatically generated OIDs intentionally don't have an ASN.1 or IRI identifier, because OID+ cannot ensure that no brother OID (e.g. inside 2.25) has the same identifiers.


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.

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 OID+ 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:

-          OID+ 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 OID+ 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 OID+ 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 OID+ system without DRAFT attribute. They should be shortly posted to

All OIDs are published. Confidential information objects should at least be visible by their numeric ID, if technically possible by OID+.

Retired and revoked OIDs

Retired OIDs stay being listed, except for dynamically generated OID+ 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.