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")?, "/",
("R"|"r"),("A"|"a")
The equivalent ASN.1 object identifier is
ISO(1)
Registration-Authority(1) nnnn pp
where
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
(Charles@XMLHandbook.com).
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?
Regards,
------------------------------------------------------------------
Yushi Komachi
Temporary answer from the ASN.1 Rapporteur:
Date:
Thu, 27 Feb 2003 11:12:30 +0000
From:
John Larmouth <j.larmouth@salford.ac.uk>
To:
SG17 Q12 <tsg17q12@ties.itu.ch>, asn1dev@oss.com
CC:
komachi@y-adagio.com
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 <j.larmouth@salford.ac.uk>
To:
asn1dev@oss.com
CC: SG17 Q12 <tsg17q12@ties.itu.ch>,
komachi@y-adagio.com
DUBUISSON
Olivier wrote:
>
It is not the case for subarc 2:
>
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.1.2&action=display
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 http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1+1&action=display
>
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 <j.larmouth@salford.ac.uk>
To:
asn1dev@oss.com, SG17 Q12 <tsg17q12@ties.itu.ch>
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 <j.larmouth@salford.ac.uk>
To:
asn1dev@oss.com
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.