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

[John Larmouth <[e-mail]>]

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:

[e-mail]" type="cite">

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" rel="nofollow">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" rel="nofollow">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]


    

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