An IRI/URI Namespace for International Object Identifiers (OIDs)
draft-larmouth-oid-iri-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 5, 2010.

Abstract

This internet draft defines the IRI/URI scheme for International Object Identifiers. The syntax and semantics of the IRI is specified below using the International Object Identifier tree specified in ITU-T X.660 International Object Identifiers.

Table of Contents

1.  Introduction
2.  URI/IRI scheme syntax and semantics for 'oid'
    2.1.  URI/IRI scheme syntax
    2.2.  URI/IRI scheme semantics
    2.3.  Encoding considerations
    2.4.  Applications and/or protocols that use this scheme
    2.5.  Operations on the 'oid' IRIs
    2.6.  Interoperability considerations
3.  Security considerations
    3.1.  General
    3.2.  Reliability and Consistency
    3.3.  Spoofing
4.  IANA Considerations
    4.1.  General
    4.2.  IANA Registration Template
5.  Acknowledgements
6.  Normative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The International Object Identifier tree [ITU-T X.660] provides a hierarchically based identification scheme for objects/resources, using almost all Unicode/ISO 10646 characters to identify arcs in the tree. The OID tree has been in existence since about 1984 in a numerical form, but the ability to have arcs identified by Unicode labels to identify arcs of the International Object Identifier tree was only standardized in 2008. The first identifier in the sequence can be the name of any standards body or any other organization that requests an unambiguous identification of that organization, with subsequent identifications in the hierarchy being allocated by that organization.

There are just under 100,000 allocated Object Identifiers that are recorded in the OID Repository at http://www.oid-info.com

There has been in existence for some time a URN scheme of "urn:oid", but this is based entirely on numeric identification of each arc. For ITU-T purposes, it is essential to be able to use names in any language as well as numbers, without resort to any % encoding or restriction to numeric values where an IRI can be used. This form of URI/IRI provides that facility for communications that accept an IRI. In other circumstances there is a well-specified mapping to a URI. Consideration was given to extending the "urn:oid" scheme to allow names as well as numbers, but this was considered complicated and confusing for existing uses of "urn:oid". A separate new 'oid' IRI scheme was considered far preferable.

This form of URI/IRI commences with "oid:/" and is followed by a series of Unicode labels separated by the SOLIDUS '/' character, identifying a node in the hierarchical International Object Identifier tree.

NOTE - The SOLIDUS '/' character is not permitted in Unicode labels.

An IRI can contain most of the Unicode characters, and in particular can contain all the characters allowed in a Unicode label. A URI is restricted to the ASCII character set, but [RFC3987], Section 3.1 specifies the conversion of the characters allowed in an IRI into the characters allowed in a URI, enabling both an IRI and a URI to carry the same semantics for the identification. This mapping is an integral part of the "oid" URI/IRI scheme. This enables names based on the Unicode labels in the International OID tree to be used wherever an IRI or a URI is required.

There has been in existence for some time a URN scheme of "urn:oid", but this is based entirely on numeric identification of each arc. For ITU-T purposes, it is essential to be able to use names in any language as well as numbers, without resort to any % encoding or restriction to numeric values where an IRI can be used. This form of URI/IRI provides that facility for communications that accept an IRI. In other circumstances there is a well-specified mapping to a URI. Consideration was given to extending the "urn:oid" scheme to allow names as well as numbers, but this was considered complicated and confusing for existing uses of "urn:oid" (of which there are many). A separate new 'oid' IRI scheme was considered far preferable.

The resource designated by an 'oid' IRI is a set of URLs for multi-media information associated with the node of the International OID Tree, and returned by the OID Resolution System [ORS] when given that IRI.

2.  URI/IRI scheme syntax and semantics for 'oid'

2.1.  URI/IRI scheme syntax

This Section uses the ABNF notation commonly used in IETF RFCs (see [RFC 5234]). An IRI in the 'oid' scheme is syntactically the ABNF construct <oidiri> defined as follows (with the semantics specified in 2.5), and with no white-space between lexical items:

<oidiri> = "oid:/" <firstarcid> <subsequentarcid>

<firstarcid> = <unicodelabel>

<subsequentarcid> = 0*("/" <unicodelabel>);

<unicodelabel> = 1*(<iunreserved>)

The external rule name <iunreserved> is defined in Section 2.2 of [RFC3987].

When used as a URI, the transformations specified in [RFC 3987], Section 3.1 are applied.

2.2.  URI/IRI scheme semantics

The <firstarcid> is required to be a Unicode label assigned to one of the arcs from the root of the International OID tree specified in [ITU-T X.660] (including long arcs) that identifies a node in the International OID tree.

The next <unicodelabel> in the <subsequentarcid> (if there is one) is required to be a Unicode label that identifies an arc from that node to a lower level node.

This repeats until the final <unicodelabel> identifies an arc, and hence a node of the International OID tree, that is the referenced resource.

NOTE - The last identified node is not necessarily a leaf of the tree, but it identifies the designated resource.

2.3.  Encoding considerations

The internationalized resource identifier is specified as an abstract sequence of Unicode characters. The encoding of those characters depends on the specification of the protocol in which they are carried, but will normally be UTF-8 [RFC3629].

2.4.  Applications and/or protocols that use this scheme

This scheme can be used by any specification requiring an IRI or URI based on the international OID tree to identify an object or to retrieve information associated with that object.

The 'oid' IRIs are used for two purposes.

The first is identification of objects such as XSD or ASN.1 specifications, where the only operation is obtaining the identified object from a repository, known by context. In this case, there will normally be only a single 'oid' IRI value that will identify the object in the repository.

The second is the retrieval of information associated with any node of the object identifier tree using the OID Resolution System [ORS]

2.5.  Operations on the 'oid' IRIs

Operations are transformation to a canonical form (using the [ORS]), and comparison of the canonical forms (where exact equality is required for a match) and retrieval of information identified by the 'oid' IRI.

These operations are expected to be used by applications specifically related to the object in question, and are not expected to be supported by general-purpose software.

2.6.  Interoperability considerations

Equality of 'oid' URIs/IRIs shall be based on exact equality of the slash-separated sequence of <unicodelabel>s building up the canonical form of the IRI, obtainable by the [ORS] DNS look-up. The IRI scheme name itself ('oid') is not case sensitive.

There are no other known interoperability issues.

3.  Security considerations

3.1.  General

An 'oid' IRI does not in itself pose a security threat. However, care must be taken to properly interpret the data referenced by an 'oid' IRI, to prevent that data from causing unintended access, and to avoid including data that should not be revealed in plain text. These security considerations are addressed by [ORS] through availability of DNSSEC in the resolution process, and optional return of encrypted data, with an established trust anchor.

3.2.  Reliability and Consistency

There is no guarantee that once an OID IRI has been used to retrieve information, the same information will be retrievable by that IRI in the future. Nor is there any guarantee that the information retrievable via that IRI in the future will be observably similar to that retrieved in the past.

3.3.  Spoofing

The ability to include effectively the full range of Unicode characters in an OID IRI may make it easier to execute certain forms of address mimicking (also called "spoofing"). However, OID IRIs are no different from other IRIs in this regard, and applications that will present OID IRIs to human users must adhere to best practices regarding address mimicking in order to help prevent attacks that result from spoofed addresses (e.g., the phenomenon known as "phishing"). For details, refer to the Security Considerations of [RFC3987].

4.  IANA Considerations

4.1.  General

(The IANA Registration Template is in 4.2)

Having the 'oid' IRI scheme registered with IANA ensures that there is no duplication of the 'oid' IRI scheme.

The introduction to [RFC 2434] (para 4) states that "Object Identifiers (OIDs) as defined by the ITU are also delegated. When a name space can be delegated, the IANA only deals with assignments at the top level."

Thus the only IANA responsibility is the registration of the scheme name, except that it has a long-standing registration responsibility for the sub-tree 1.3.6.1 (oid:/ISO/org/dod/internet), and has made many sub-allocations. This is not affected by this provision of an 'oid' IRI scheme.

4.2.  IANA Registration Template

This filled-out template should be added to the URI Schemes registry

URI/IRI scheme name: oid

Status: permanent

URI/IRI scheme syntax: See Section 2.1

URI/IRI scheme semantics: See Section 2.2

Encoding considerations: See Section 2.3

Applications and/or protocols

which use this scheme: See Section 2.4

Operations on the 'oid' IRIs: See Section 2.5

Interoperability considerations: See Section 2.6

Security considerations: See Section 3

Contact:

J. Larmouth

Rapporteur, ITU-T SG17 ASN.1 & OID

Convenor, ISO/IEC JTC 1/SC 6/WG 9

International Telecommunication Union (ITU)

Place des Nations

CH-1211 Geneva 20

Switzerland

E-mail: tsbmail@itu.int

5.  Acknowledgements

This document is a product of the joint ISO/IEC and ITU-T ASN.1 & OID group. All members of the group are thanked for their efforts in this work.

6. Normative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2009).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.