Re: [Uri-review] draft-larmouth-oid-iri-00

[Alfred Hönes <[e-mail]>]

John,
thanks for your detailed feedback.
It contains a lot of very important information.

See a couple of comments inline.

> Thanks again Alfred.
>
> Your efforts are much appreciated.
>
> We expect to get something to you, either as an interim set of
> comments, or together with a newly posted I-D, by the end of
> next week at the latest.

Don't hurry up too much, I now see the need for even more
substantial work to be carried out on the draft, as will be
explained below.


> As an initial remark to you:
> We strongly want an oid: IRI scheme, and not a urn:oid scheme,
> not least because the latter already exists, and is purely
> numerical.

I am aware of the 'oid' URN Namespace, and I'm sure
the question of why not extending it will certainly
arise in the IESG when it comes to document approval.

Thus, that indeed should be explained in the draft.

The overlap with the existing 'oid' URN namespace is rather
detrimental to the rationale you must provide for the choice
of a new 'oid' URI scheme.
A very careful analysis needs to be carried out in the
document to justify that.  Without very hard arguments
at hand, I fear that this collision might arguably be
considered a violation of RFC 4395.


> We also want to be able to use an IRI for handling all the
> Unicode characters without having to do % encodings.

That already was implicit from the -00 draft.

Since URNs are specific URIs, yet RFC 3987 isn't very
explicit on that either, for me, it is unclear whether
the IRI --> URI transformation of RFC 3987 would also
be applicable for a specific URN namespace.


> Note that there is now an ASN.1 "OID-IRI" type that enables an
> oid: IRI to be carried in (any ASN.1-defined) protocol.
>
> On the question of whether this is different from the old OID
> tree:  it is not.  It is an extension of it that allows names
> as well as numbers for arcs, but it also allows named long arcs.
>
> So, for example, the current IANA root oid of:
>
> 1.3.6.1x.y.z
>
> for the internet could form an IRI of oid:/INTERNET/....
>
> with the same meaning.
>
> All the old numbers are also stil there.
> So the IRI oid:/1/3/6/1/..... would be synonymous with
> oid:/INTERNET/.... or with oid:/ISO/ORGANISATION/DOD/INTERNET/....
>
> I am not sure whether any of the above material would be worth
> adding to the draft as additional explanation or as examples,
> or whether it just all adds more confusion?

Admittedly, I did not take the time to look into the new edition
of X.660 -- it is in "pre-published" state and not yet openly
available -- and that non-uniqueness you have indicated above
is rather surprising!!!!

This makes it even more important that these complications
be detailed properly in the registration document, with all
ensuing consequences.

As I understand you, there will be multiple URIs for the same
resource, which should be recognized as equivalent.
This fundamentally invalidates the discussion of
equality/equivalence of 'oid' URIs/IRIs in the draft.

Is there some normalized `canonical form` of 'oid' URIs/IRIs
(like DER for ASN.1) that might be a candidate for restricting
that potentially confusing explosion of identifiers ?

Will any software using these identifiers have to be able to
recognize/identify all equivalent forms?
The advantage of 'classical' OIDs was that the encoding to
be used in protocols is in 1:1 relation to the resources
identified.
Apparently that fundamental property is going to be lost.

For comparison: In the case of the upcoming revised registration
for ISBN, the document will explain the formal rules a consumer
can follow to establish equivalence or non-equivalence of
ISBN-13 and ISBN-10 instances, which both will be covered
by the revised scheme.  In the case of 'oid', I fear that it
will not be possible to algorithmically decide on equivalence
of two 'oid' IRIs without actually making use of the URI
resolution process / lookup in registration databases.

I fear that these unfortunate properties might become show-
stoppers for the approval of the document and the registration.

From your explanations, I conclude that the new X.660 is dependent
on the approval of the 'oid' URI/IRI Scheme.
To further that registration and the discussion needed for it to
succeed, it might be very advantageous if ITU-T could make the pre-
published document available to the IETF, unless the registration
draft itself is getting expanded to contain all relevant details.


> John L
>
> --
>     Prof John Larmouth
>     Larmouth T&PDS Ltd
>     (Training and Protocol Design Services Ltd)
>     1 Blueberry Road
>     Bowdon                               [e-mail]
>     Altrincham
>     Cheshire
>     WA14 3LS
>     England
>     Tel (Business): [phone]        Fax: [phone]
>     Tel (Private): [phone]


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+

_______________________________________________
Uri-review mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/uri-review