TOC 
Network Working GroupJ. Larmouth
Internet-DraftISO/IEC JTC 1/SC 6/WG 9
Intended status: Standards TrackO. Dubuisson
Expires: July 5, 2010ITU-T SG17 ASN.1 & OID
 January 2010


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

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".

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 5, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.



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.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses




 TOC 

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

The URN namespace "urn:oid" as defined in [RFC3061] 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 Section 3.1 of [RFC3987] 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 for [ORS] look-up via the Domain Name System (DNS). This enables names based on the Unicode labels in the International OID tree to be used wherever an IRI or a URI is required.

The ORS specifies how an IRI expressed as a series of (abstract) Unicode characters is to be mapped into an ASCII form suitable for DNS lookup and transformation to the canonical numeric form. The mapping performed in the ORS uses the transformation specified in Section 4 of [RFC 3490] which references [RFC 3454] (case folding) and [RFC 3492] (punycode encoding). It also uses the Compatibility Decomposition, followed by Canonical Composition (KFCD) specified by Unicode 5.2.

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.



 TOC 

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



 TOC 

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 Section 2.2), 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 Section 3.1 of [RFC 3987] are applied.



 TOC 

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.



 TOC 

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].



 TOC 

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].



 TOC 

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.



 TOC 

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.



 TOC 

3.  Security considerations



 TOC 

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.



 TOC 

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.



 TOC 

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].



 TOC 

4.  IANA Considerations



 TOC 

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 5226] (para 4) states that "Object Identifiers (OIDs) as defined by the ITU are also delegated. When a name space is delegated, the scope of IANA is limited to the parts of the namespace where IANA has authority"

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.



 TOC 

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 of RFC xxxx
URI/IRI scheme semantics: See Section 2.2 of RFC xxxx
Encoding considerations: See Section 2.3 of RFC xxxx
Applications and/or protocols which use this scheme:
See Section 2.4 of RFC xxxx
Operations on the 'oid' IRIs: See Section 2.5 of RFC xxxx
Interoperability considerations: See Section 2.6 of RFC xxxx
Security considerations: See Section 3 of RFC xxxx
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
Author/Change controller: Same as Contact
References: See Section 6 of RFC xxxx
[[ RFC Editor: Please replace 'xxxx' in all the above IANA Registration Template entries by the RFC number assigned to this document. ]]


 TOC 

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.



 TOC 

6.  References



 TOC 

6.1. Normative References

[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, November 2003 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC3987] Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” RFC 3987, January 2005 (TXT).
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes,” BCP 35, RFC 4395, February 2006 (TXT).
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
[RFC5234] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT).
[ITU-T X.660] “ITU-T X.660 | ISO/IEC 9834-1: Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the International Object Identifier tree (http://www.itu.int/rec/T-REC-X-660/en).”
[ORS] “ISO/IEC 29168: Information Technology - Object Identifier Resolution System.”


 TOC 

6.2. Informative References

[RFC3061] Mealling, M., “A URN Namespace of Object Identifiers,” RFC 3061, February 2001 (TXT).
[RFC3454] Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” RFC 3454, December 2002 (TXT).
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” RFC 3490, March 2003 (TXT).
[RFC3492] Costello, A., “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” RFC 3492, March 2003 (TXT).


 TOC 

Authors' Addresses

  John Larmouth
  ISO/IEC JTC 1/SC 6/WG 9
Email:  j.larmouth@btinternet.com
  
  Olivier Dubuisson
  ITU-T SG17 ASN.1 & OID
Email:  olivier.dubuisson@orange-ftgroup.com