Re: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

[Lisa Dusseault <[e-mail]>]

Hi John,

Please do a -04 as soon as you like.  I suspect this round of feedback
is about finishing up and reviewers don't yet understand what you
intend to do about the feedback.

Thanks,
Lisa

On Wed, Nov 25, 2009 at 7:42 AM, John Larmouth
<[e-mail]> wrote:
> All,
>
> As I was cc:ed, let me just say that I appreciate Martin's comments, and I
> believe them be largely accurate.
>
> I am collecting all the comments on this stuff, and will produce a 04
> version when it seems appropriate and comments have died down!
>
> I am sure we understand the issues and implications of comparison, and for
> our purposes they are acceptable.  On the // issue, we have oscillated on
> that over the production process, and our latest advice is as recorded in 03
> - we use only "oid:/Alerting/....." for example.   There *is* a use for
> relative OIDs (and they *are* defined in the Recommendations | International
> Standards), but we were *not* planning on allowing those in the IRI scheme,
> as establishing the context for the relative OID/IRI is more difficult than
> in a controlled protocol environment.
>
> I am not wanting any reply to this, unless someone wants to - I will await
> Lisa telling me it is time to do a 04 (addressing known comments as best we
> can) for a couple of weeks review, and then to request her to initiate an
> IETF-wide Last Call.
>
> The co-authors (representing the ASN.1 group in ITU-T and ISO/IEC) feel
> themselves in waiting and observing mode, but very happy to respond
> positively to any suggestions.  We just want to get this stuff sewn up and
> in place as soon as possible!
>
> John L
>
> Martin J. Dürst wrote:
>
>> Hello Lisa,
>>
>> I have looked at that draft.
>>
>> On 2009/11/19 4:37, Lisa Dusseault wrote:
>>
>>> Hi Larry, Martin, Graham,
>>>
>>> Graham, I haven't seen your response to John Larmouth's request for
>>> review
>>> on the 'uri-review' list.  Did I miss it?
>>>
>>> Larry&  Martin, since this particularly involves IRI syntax, I would
>>> appreciate a review from one of you, particularly with an eye to the
>>> comparison function.  The current description for comparison seems to
>>> include a DNS lookup which might be problematic in many use cases.
>>
>>
>> I agree that this locks out many use cases. My guess is that this is
>> necessary because there is a proliferation of representations, first there
>> are numeric and alpha(numeric) ways to identify arcs, and second, if I
>> understand correctly, it may be possible to give more than one
>> alpha(numeric) arc, e.g. for different scripts/languages which are like
>> translations. At that point, there's virtually no other way than to use
>> lookup for comparison.
>>
>> I think there should be a clearer explanation abouth this and some real
>> examples, including (with appropriate circumscription) some non-ASCII ones,
>> both in the draft and e.g. at places such as
>> http://www.oid-info.com/faq.htm#iri.
>>
>> If my understanding is correct, then this is not exactly the way that IRIs
>> are intended to be used, but it's not something we need to forbid if the
>> proponents are aware of the consequences.
>>
>>> The
>>> encoding is also "normally" UTF-8, but I believe that requires a bit more
>>> explanation for when an agent gets a OID IRI in one encoding, and needs
>>> to
>>> compare it to an IRI in another encoding.
>>
>>
>> In my eyes, the following:
>>
>> >>>>
>>                                                               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.
>> >>>>
>>
>> is sufficient, but this may be because I'm too familiar with all this
>> encoding stuff.
>>
>>> It's also not clear to me in what cases a oid IRI might use numbers in
>>> arcids, and where it might use strings with unicode characters.  I
>>> probably
>>> don't understand OIDs well enough, but the description so far makes me
>>> think
>>> that these are substitutable
>>
>>
>> I agree that this needs to be explained better.
>>
>>> -- again providing problems for a comparison function.
>>
>>
>> If the proponents understand the implications, both of having both URI/IRI
>> and URN, and of having various forms that need network activity for
>> comparison, then in my view, it's their business to decide whether they are
>> okay with that or not. There are limits to how far we can force people to
>> design good URI/IRI schemes, after that, it is "natural selection".
>>
>>
>>> Next, if these are intended to be more human-friendly than the numerical
>>> representations, how are bidi characters to be displayed?
>>
>>
>> The display of bidi characters should follow whatever RFC 3987 (and it's
>> successor) say. There is absolutely no point in having special rules for
>> displaying bidi "oid:" IRIs.
>>
>> In addition, I agree with Graham that the use of slashes in this scheme
>> should be carefully checked against RFC 3986, and potentially be fixed. In
>> my understanding, slashes are only appropriate if relative URIs/IRIs are
>> potentially used, and in that case, the whole thing has to start with '//'
>> (which wouldn't be a problem because indeed the first part of an OID is an
>> authority). But I may as well have some details wrong here, the best person
>> to answer this is Roy.
>>
>> Regards,    Martin.
>>
>>
>>> John, Is there any requirement to compare OID URNs (urn:oid:*) to OID
>>> IRIs?
>>> If not, this should be mentioned as being not desired.
>>>
>>> If these questions have already been answered in the discussion on
>>> uri-review,  I must have missed that.  I believe Alfred raised very
>>> similar
>>> questions in Dec 2008 and I did not see answers in the spec or on the
>>> list.
>>>
>>> Thanks,
>>> Lisa
>>>
>>> ---------- Forwarded message ----------
>>> From: John Larmouth<[e-mail]>
>>> Date: Tue, Oct 20, 2009 at 9:44 AM
>>> Subject: [Fwd: Registration of 'oid:' as a URI/IRI scheme]
>>> To: [e-mail], [e-mail]
>>>
>>>
>>> Lisa and Alexey,
>>>
>>> The following request for IANA registration has been made following
>>> earlier
>>> discussions in uri-review.
>>>
>>> It was originally intended to request "permanent", but Ira said that this
>>> was not normal and that we should request "provisional". Alred HÎnes
>>> responded saying that as it is based on an existing ITU-T Rec. X.660 |
>>> ISO/IEC 9834-1,
>>> an immediate request for "permanent" might be better.
>>>
>>> The current request to IANA is for "provisional", but presumably this
>>> could
>>> be upgraded if you were to recommend that?
>>>
>>> Whether "provisional" or "permanent", it would be helpful if you could
>>> give
>>> the proposed IANA registration your support for rapid progression.
>>>
>>> Thank you.
>>>
>>> John L
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Registration of 'oid:' as a URI/IRI scheme
>>> Date: Tue, 20 Oct 2009 18:08:18 +0100
>>> From: John Larmouth<[e-mail]>
>>> Reply-To: [e-mail]
>>> To: [e-mail]
>>>
>>> I refer to the Internet Draft draft-larmouth-oid-iri-03.
>>>
>>> I would like IANA to register 'oid:' as a "permanent" URI scheme,  with
>>> the
>>> registration template given in the 'IANA considerations' section
>>> of the Internet Draft draft-larmouth-oid-iri-03.
>>>
>>> This request is on behalf of the ASN.1 group, which is collaborative work
>>> between ITU-T SG 17 Q.12 (I am the Rapporteur) and ISO/IEC JTC 1/SC 6 WG
>>> 9
>>> (I am
>>> the Convenor).
>>>
>>> I understand that a "provisional" registration would be approptiate until
>>> the
>>> I-D reaches a certain stage of processing, but the target is "permanent"
>>> (so
>>> an
>>> early progression to "permanent" would be good), as the scheme is based
>>> on
>>> existing ITU-T Recommendations and ISO Standards that are stable.
>>>
>>> There has been review of earlier drafts by uri-review, with no adverse
>>> comments
>>> that have not been addressed, but I understand that you will appoint your
>>> own
>>> expert for a further review.
>>>
>>> I will contact the Area Director shortly to alert her to this request.
>>>
>>> Thank you.
>>>
>>> John L
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Uri-review mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/uri-review
>>
>>
>
> --
>  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: [phone]
>
>