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

From: Lisa Dusseault <[email-masked]>
Date: Wed, 18 Nov 2009 11:37:59 -0800

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.  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.

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 -- again providing problems for a comparison
function.

Next, if these are intended to be more human-friendly than the numerical
representations, how are bidi characters to be displayed?

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 <[email-masked]>
Date: Tue, Oct 20, 2009 at 9:44 AM
Subject: [Fwd: Registration of 'oid:' as a URI/IRI scheme]
To: [email-masked], [email-masked]

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 <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]

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

-- 
  Prof John Larmouth
  Larmouth T&PDS Ltd
  (Training and Protocol Design Services Ltd)
  1 Blueberry Road
  Bowdon                               [email-masked]
  Altrincham
  Cheshire
  WA14 3LS
  England
  Tel: +44 161 928 1605

---

From: Graham Klyne <[email-masked]>
Date: Thu, 19 Nov 2009 12:33:13 +0000

Lisa,

As I recall, I didn't respond on URI-Review, but to a request from IANA (ticket 
IANA #273718), which I copied to John Larmouth as there were some additional 
points I wanted to raise.

I did raise the issue of new URI scheme vs other - see below.

I didn't attempt a detailed technical review, though I did notice some aspects 
of '/' usage and authority that seemed a little unusual to me.

For ease of reference, my final summary was:
[[
(a) the registration goes as provisional for now - no further action needed from 
you, I think.

(b) I believe you plan to take the proposal to IETF standards track, in which 
case I expect the issues will all come up again in last call.  When you have a 
standards track RFC, then that will be a sound indication of sufficient 
consensus for permanent registration - so nothing further required.

When you request last-call for your RFC, it might be worth noting those 
references to debate (as a URI into the discussion list archive indicating the 
start of the relevant discussion) and mentioning in your request to IESG about 
the existing ITU standards using oid:, and underscore that this is documenting 
an existing practice - whatever the merits of the arguments about new scheme vs 
http:, it's not reasonable IMO to retrofit that debate to past work.
]]

#g
--

Lisa Dusseault wrote:
> Graham, I haven't seen your response to John Larmouth's request for 
> review on the 'uri-review' list.  Did I miss it?
> 
> 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.
> 
> 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 -- again providing problems 
> for a comparison function. 
> 
> John, Is there any requirement to compare OID URNs (urn:oid:*) to OID 
> IRIs?  If not, this should be mentioned as being not desired.
> 
> 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
> 
> From: *John Larmouth* <[email-masked] 
> <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>, 
> [email-masked] <mailto:[email-masked]>
> 
> 
> 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,
> 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
> 
> 
> From: John Larmouth <[email-masked] 
> <mailto:[email-masked]>>
> Reply-To: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> 
> 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
> that have not been addressed, but I understand that you will appoint 
> your own
> <mailto:[email-masked]>
>   Altrincham
>   Cheshire
>   WA14 3LS
>   England
>   Tel: +44 161 928 1605
>

---

From: Larry Masinter <[email-masked]>
Date: Fri, 20 Nov 2009 20:44:29 -0800

I think this registration is a good example of some of the difficulties in IRI scheme registration we'll have to face.

Requiring a DNS normalization to do comparison seems completely out of line.

I don't understand why this wasn't done as an extension to the "urn:oid" scheme.

   Consideration was given to extending the "urn:oid" scheme to allow
   names as well as numbers, but this was considered complicated and
   confusing for existing uses of "urn:oid".  A separate new 'oid' IRI
   scheme was considered far preferable.

How is it less complicated and confusing to have two kinds of OID URIs instead of one?

Larry
--
http://larry.masinter.net

From: Lisa Dusseault [mailto:[email-masked]]
Sent: Wednesday, November 18, 2009 11:38 AM
To: Larry Masinter; [email-masked]; [email-masked]; Martin Duerst; [email-masked]
Subject: Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

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.  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.

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 -- again providing problems for a comparison function.

Next, if these are intended to be more human-friendly than the numerical representations, how are bidi characters to be displayed?

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 <[email-masked]<mailto:[email-masked]>>
Date: Tue, Oct 20, 2009 at 9:44 AM
Subject: [Fwd: Registration of 'oid:' as a URI/IRI scheme]
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

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 <[email-masked]<mailto:[email-masked]>>
Reply-To: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>

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.

Thank you.

John L

--
  Prof John Larmouth
  Larmouth T&PDS Ltd
  (Training and Protocol Design Services Ltd)
  1 Blueberry Road
  Bowdon                               [email-masked]<mailto:[email-masked]>
  Altrincham
  Cheshire
  WA14 3LS
  England
  Tel: +44 161 928 1605

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 25 Nov 2009 20:08:47 +0900

Hello Lisa,

I have looked at that draft.

On 2009/11/19 4:37, Lisa Dusseault wrote:
> Larry&  Martin, since this particularly involves IRI syntax, I would
> 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

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.

> 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".

> 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.

> From: John Larmouth<[email-masked]>
> From: John Larmouth<[email-masked]>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: John Larmouth <[email-masked]>
Date: Wed, 25 Nov 2009 15:42:50 +0000

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:

> 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 
>> more
>> probably
> 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".
>
>
> 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.
>
>
>> IRIs?
>> similar
>> this
>> could
>> until
>> your

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 25 Nov 2009 09:21:57 -0800

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
<[email-masked]> 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 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.
>
> 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,
>>
>> 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
>> examples, including (with appropriate circumscription) some non-ASCII ones,
>> both in the draft and e.g. at places such as
>> 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
>> 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".
>>
>>
>> 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.
>>
>>
>>> give
>>> 9
>>> (so
>  1 Blueberry Road                      Bowdon
> [email-masked]
>  Altrincham
>  Cheshire
>  WA14 3LS                  England
>  Tel: +44 161 928 1605
>
>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 26 Nov 2009 07:18:14 +0000

> relative OID/IRI is more difficult than in a controlled protocol 

(Scheme reviewer hat OFF...)

I would say that if you use a URI form with '/'s, you cannot prevent others from 
using relative forms in ways defined generally for URIs, which may or may not be 
the same as (or isomorphic with) relative forms defined by the OID 
Recommendations.  I think it could be confusing if two different ways of doing 
relative OIDs were potentially available (even if not actually blessed by the 
specification).

The URI spec provides some guidelines for establishing the context for relative 
URIs, but these are necessarily partial for the reasons you indicate.

My comment about using '//' was because the first path-segment of your OID URI 
seemed to perform the same function as the "authority" in a URI.  I can't tell 
if it truly does.

Martin:  from my recollection of when I looked into this previously, I think 
it's OK for a URI scheme using the relative path constructs to *not* have an 
authority component, hence is not *required* to start with '//'.  My take would 
be that the leading '//' should be used if[f] the following element is an 
authority in the (loosely defined) sense of RDF 3986.

#g

---

From: John Larmouth <[email-masked]>
Date: Thu, 26 Nov 2009 12:08:59 +0000

Thanks Lisa.

I am doing two things - producing a summary of comments made and of our
resolution of  them, plus a 04 which implements our resolutoin of the
comments.

I will post the summary of comments and our resolution as a simple
e-mail to URI-REVIEW, and the 04 will be posted as a new I-D in the
usual way.

I need to finalise both these with colleagues, so I think the
middle/end of next week is a reasonable expectation for this all to
happen, then I will contact you again.

(No reply needed at this stage.)

John L

Lisa Dusseault wrote:

Hi John,

Thanks,
Lisa

All,

John L

Martin J. Dürst wrote:

Hello Lisa,

review

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.

A URI is

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

Regards,    Martin.

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<[email-masked]>
Date: Tue, Oct 20, 2009 at 9:44 AM
Subject: [Fwd: Registration of 'oid:' as a URI/IRI scheme]
To: [email-masked], [email-masked]

Lisa and Alexey,

earlier

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<[email-masked]>
Reply-To: [email-masked]
To: [email-masked]

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.

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.

Thank you.

John L

---

From: Larry Masinter <[email-masked]>
Date: Thu, 26 Nov 2009 11:25:20 -0800

The new IRI-bis draft proposes reserving the "authority" field in IRIs for internationalized domain names, and using punicode (rather than hex-encoded UTF8) in the transation of IRIs to URIs. This is to prevent alternative paths which sometimes would wind up presenting percent-encoded UTF8 of original host names to DNS.

 A review of existing registered URI schemes didn't find any where this would be a problem, but if "oid:" were to use "//" for a non-DNS "authority" field (which it does not currently) it would cause problems.

(Discussion of policy on [email-masked], please)

Larry

-----Original Message-----
From: Graham Klyne [mailto:[email-masked]] 
Sent: Wednesday, November 25, 2009 11:18 PM
To: [email-masked]
Cc: "Martin J. Dürst"; Lisa Dusseault; Martin Duerst; [email-masked]; [email-masked]; Larry Masinter
Subject: Re: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

#g