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

[John Larmouth <[e-mail]>]

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]