Liaison statement regarding ITU-T ASN.1 Project leader: Withdrawn object identifier arc in ISO/IEC 10036







September 2003


Yushi Komachi

Panasonic Communications Co., Ltd.

2-3-8 Shimomeguro, Meguro-ku, Tokyo  153-8687 Japan

Tel.:         +81 3 5434 7053

Fax:         +81 3 5445 3663





Please find below an e-mail correspondence dated 27 January 2003 on the above-mentioned subject.


Dear Sir,


Please accept my apology for not corresponding with you sooner.


> We would appreciate your providing us with any information or

> comments on why this arc 10036 was created under the registration

> -authority arc and whether we should remove the note on the

> withdrawal of the that arc from the ASN.1 standard.


Thank you for your liaison information. Here I reply to your liaison as an editor of ISO/IEC 10036. Formal liaison response to ITU-T SG17 from JTC1/SC34 will be forwarded after the next SC34 Plenary meeting to be held in May 2003.


Actually ISO/IEC 10036 defines that its object identifiers shall be {1 1 10036 ....}.


It is based on the definition specified by the clause 5.2.2 in ISO/IEC 9070:1991 (Information technology - SGML support facilities - Registration procedures for public text owner identifers):


[8] ISO registration authority prefix =

    full registration authority prefix | ISBN prefix

    | ISO 2375 prefix

[9] full registration authority prefix = "ISO",("/",

    "aaa")?, SPACE, "nnnn",("-", "pp")?, "/",


The equivalent ASN.1 object identifier is

    ISO(1) Registration-Authority(1) nnnn pp


    nnnn is replaced by the number of an ISO

         registration standard.

    pp   is replaced by the part number (if any).



Note: The editor of ISO/IEC 9070 is Dr. Charles Goldfarb



The notation specified in ISO/IEC 9070 are today widely applied to SGML/XML related standards and applications.


If the note on subclause D.3.1 of ISO/IEC 8824-1 (the use of arc registration-authority(1) under iso(1) has been withdrawn) should be absolutely valid, we have to amend ISO/IEC 10036, ISO/IEC 9070 and their related standards/applications.


The SGML/XML are so much widely implemented that I expect the note of ISO/IEC 8824 will be removed. If the removal is impossible, could you suggest me an appropriate arc for a registration authority?




Yushi Komachi



Temporary answer from the ASN.1 Rapporteur:

Date: Thu, 27 Feb 2003 11:12:30 +0000

From: John Larmouth <>

To: SG17 Q12 <>,



It seems clear to me that there has at some stage in the past been a typo made (maybe a long time in the past!) somewhere.


The OID used by this group would be a perfectly normal and legal allocation under arc {1  0 10036 ...... },  that is  {iso standard 10036 part(ppp) etc}.


If all other allocations under arc 1  1 (which should certainly NOT have been used) turn out to be of the same form as this (that is, followed by a standards number, and perhaps stemming from the same SGML base?????), then the easiest solution is going to be to declare arc 1  1 as a synonym for arc 1  0, that is, allocated to an ISO Standard,  but to deprecate (forbid?) any future use of 1  1 by new Standards.


To suggest that SC34 change their OID at this stage would be silly.


We need to rationalise the situation.  However, it is important to look at any other allocations under arc {1  1 ....} before a decision is taken.



Date: Thu, 27 Feb 2003 11:42:44 +0000

From: John Larmouth <>


CC: SG17 Q12 <>,


DUBUISSON Olivier wrote:

> It is not the case for subarc 2:



This one is certainly out of line, and does not stem from the same source.   I believe this should have been under the FTAM Standard arc, and I am (fairly) sure it originally was.  We need to discuss this one separately.


>>and perhaps stemming from the same SGML

>>base?????), then the easiest solution is going to be to declare arc 1  1

>>as a synonym for arc 1  0, that is, allocated to an ISO Standard,  but

>>to deprecate (forbid?) any future use of 1  1 by new Standards.


The other arcs you list clearly stem from the same SGML base, and can be covered by the same solution.


> How to be sure to avoid any potential clash?


Arc {1 1 2...} is the only problem.  The other subarcs beneath {1 1} all have a standards number as the next arc, which is unique.


> See

> for all subsequent arcs to the knowledge of the ITU-T ASN.1 Project.


These all seem to stem from the SGML "typo".


We just need to investigate and to discuss what to do with the document type case a bit more.  I expect there *is* an ISO Standard ISO 2, but I am pretty sure it does not use any OIDs!  So we can probably say that one is a synonym for {1 0 2...} as well.  I suspect there have only ever been allocations under {1 1 2 } within the ISPs for FTAM.

These really need checking.



Subject: Re arc 1 1 2

Date: Thu, 27 Feb 2003 11:58:18 +0000

From: John Larmouth <>

To:, SG17 Q12 <>


This is apparently allocated in 9834-2, which is one of the parts of 9834 that I do not have a copy of (although I think I may have originally written it in 1984ish!), as it is not one of the parts we are due to be revising, nor is it joint work with ITU-T.


I am slightly surprised it is using arc {1 1 2},  and would like to look at the text.  We may also need to find a raft of ISPs (plus the FTAM Standard itself) to see what allocations there are beneath that arc, and whether these really *are* using arc 1 1 2.


It may be we will have to declare {1  1 2} as a synonym for {1  0  9834  2}


It is messy, but it will probably work.


Actually, rather than declaring synonyms, we can probably just make specific allocations under {1 1} to the relevant standards, perhaps with a note saying that no further allocations are intended under this arc.

This would be done as part of the revision of the 9834 and X.660 series.


But I would like to see the text of 9834-2 first.


I would have expected Virtual Terminal Profiles to have been done

similarly to FTAM Document Types.  I am wondering if there are problems

lurking there as well????



Subject: Re: Re arc 1 1 2

Date:  Thu, 27 Feb 2003 13:27:36 +0000

From: John Larmouth <>



I recognise most of this text as my own, but I think the clause using {1 1 2} was added by Brian Wood when the text moved from FTAM to 9834.


There is no mention of who is the International Registration Authority for this arc (I don't think one was ever created - this Standard came late in the day, when OSI was dying), but I think if we really want to follow this up, we need to look at the FTAM and JTM Standards, and the ISPs for FTAM Document Types, of which there were several, I think. (Ditto VT Terminal Profiles and Control Objects).


But most of this stuff is defunct, and I am not sure it is worth putting time and effort into it.


If 9834 parts 2, 4, and 5 have used arcs 2, 4, and 5 (under {1 1}), then I guess we just allocate those arcs to them, and leave it at that.  They are "mature" standards.