[Uri-review] draft-larmouth-oid-iri-04

[Patrik Fältström <[e-mail]>]

Olivier have some problems posting to the list, and we do not know why. While investigating, I hereby forward his email to the list and hope I am more successful in doing the actual posting.

   Patrik - list administrator

Begin forwarded message:

> From: <[e-mail]>
> Date: 20 januari 2010 11.23.24 CET
> To: [e-mail]
> Cc: LARMOUTH John <[e-mail]>
> Subject: draft-larmouth-oid-iri-04
> 
> 
> Folks,
> 
> we have just posted -04 of the I-D.
> 
> The following text contains in Section B a copy of (hopefully all) previous comments from uri-review, and our response, with Section A summarizing the actions taken in preparation of version -04.
> 
> Thanks,
> O. Dubuisson and J. Larmouth
> 
> (Section A below contains a summary of the main points made in comments and their resolution.
> Section B below is a collection of comments made and a short statement of the changes made as
> a result of those comment.  The numbering of Section A is synchronized with the numbering of Section B.)
> 
> A.    Discussion of main points
> ======================
> 
> A1.   Review comments on 03 draft
> ========================== 
> 
> We are not providing a URL into the uri-review discussions, as these are all included in Section B below.
> 
> A2.    Editorial
> ===========
> 
> All proposed editorial changes have been applied in the production of the 04 version.
> 
> A3.    Comparison of OID-IRIs
>  ======================
> 
> The ITU-T | ISO/IEC group has discussed the various comments on comparison, and reaffirms that the Object Identifier Resolution System (ORS) text (using DNS lookup to convert the IRI into a canonical form) is fully satisfactory for all uses cases that are required.  Text has been added in 04 on the mapping performed in the ORS from an IRI expressed as a series of (abstract) Unicode characters into an ASCII form suitable for DNS lookup (this uses the transformation specified in IETF RFC 3490, clause 4 which references IETF RFC 3454 (case folding) and IETF RFC 3492 (punycode encoding).  It also
> uses the Compatibility Decomposition, followed by Canonical Composition (KFCD) specified by Unicode 5.2.
> 
> A4.    oid://xxx or oid:/xxx
> ===================
> 
> 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 has been no change for the 04 posting.
> 
> 
> A5.    Use of an http prefix instead
> =========================
> 
> There appears to be varied comments on used of "http://" compared with he proposed "oid:" IRI scheme, but the ITU-T |ISO/IEC group reaffirms that the "oid:" IRI scheme (as provisionally allocated by IANA) is what we require, and attempting to use "http://" would not satisfy our requirements.  There has been no change for the 04 posting.
> 
> B.   Raw comments and brief statement of  disposition
> ========================================
> 
> B1.    Review comments on 03 draft
> ==========================
> 
> Author:   Grahame Klyne
> 
> My response here is in two parts, the latter being technical comments for the 
> authors that strictly lie outside my role as reviewer.
> 
> Summary: I recommend provisional registration for now.
> 
> This has been done.
> ... 
> 1. Registration 
> 
> I think this is fine for provisional registration, with the intent that this may 
> eventually become a permanent registration. 
> 
> But, for the time being, there is no permanent stable reference for the scheme 
> description, which is a requirement for permanent registration.  The 
> registration can be updated to permanent on publication as an IESG-approved RFC.
> 
> Concerning public review of this proposed scheme, it would help if the proposers 
> could provide a reference, particularly as there are some matters that I think 
> would attract comment.  (A last call for RFC publication would itself probably 
> cause these debates to be reviewed, and having pointers to or summaries of 
> earlier discussions would help prevent rehashing old ground.) 
> 
> This e-mail is designed to answer that.
> ... 
> 2. Technical comments 
> 
> The following comments are for information, not part of my formal review. 
> 
> Reading through the draft, two main thoughts occur to me: 
> 
> (a) Concerning the argument that a new scheme is not needed for the purposes 
> stated.  E.g. use http://oid.itu.org/ in place of the scheme name.  It could 
> help if the requirements or reviewable debate indicate why this isn't 
> satisfactory.  In view of the costs of a URI scheme noted at 
> http://tools.ietf.org/html/rfc4395#section-2.1, I think it should be made clear 
> in the record that this aspect has been duly considered. 
> 
> This has, of course, been debated.  Referring to 
> http://www.ietf.org/mail-archive/web/uri-review/current/msg01053.html, I think 
> the telling point is that oid: is already embedded in a number of ITU-T 
> standards, many of (I guess) which pre-date the current URI registration 
> procedures.  Referring to implementations of those standards would reinforce 
> your case here. 
> 
> (b) Use of '/' in the scheme-specific part.  The hierarchical form of 
> scheme-specific part is invoked by having it start with '/'.  Do the authors 
> intend that relative form URIs can be used?  I draw their attention to 
> http://tools.ietf.org/html/rfc4395#section-2.2.
> 
> I also note that no mention is made of the authority component of the URI.  The 
> syntax given implies that an authority component is never present, but the 
> description of oid: suggests that the first path component serves a role very 
> similar to an authority. 
> 
> B2.    Editorial
> ===========
> 
> Author:  Alfred Hönes
> 
> (1)  Section 2.1 -- wrong internal reference
> 
> I very strongly suspect that in the 1st para of 2.1,
> "... semantics specified in 2.5)"  should refer to Section 2.2.
> You might add the word "Section" as well.
> 
> This has been done in 04
> 
> (2)  Section 4.1 -- Orphaned/outdated external reference
> 
> The third para of 4.1 still refers to the outdated RFC 2434,
> which had been obsoleted by RFC 5226.  The citation "[RFC2434]"
> is orphaned; there's no such entry in Section 6.
> Please   s/[RFC2434]/RFC5226]/ .
> 
> This has been done in 04
> 
> (3)  Section 6
> 
> [RFC3061] arguably isn't a Normative Reference.
> I suggest to add another Section, Informative References, (or split
> Section 6 in 2 subsections:  References; Normative References +
> Informative References) and demote the [RFC3061] entry.
> 
>   An informative references section has been added as Section 7 in 04
> 
> (4)  Section 1, penultimate para, and Section 2.1, last para
> 
> Citations of the form  "[RFCxxxx], Section y.z, ..."  are not
> appreciated by the RFC Editor; they prefer the variant
> "Section y.z of [RFCxxxx] ..." that arguably allows more fluent
> reading and indeed avoids the placement of quite a couple of
> commas, if used uniformly.
> 
> This has been done in 04
> 
> (5)  Section 2.4, last para
> 
> There's no trailing period at the end of the section.
> 
> This has been done in 04
> 
> (6)  Section 4.2 -- readability and completeness of reg. template
> 
> You have chosen a compact representation of the template,
> but did not provide any visual cue allowing to easily recognize
> continuation lines within clauses of the template.
> I would prefer seeing a bit of indentation applied there; for
> example (also changing line folding in one instance) this way:
> 
>       URI/IRI scheme name: oid
>       Status: permanent
>       URI/IRI scheme syntax: See Section 2.1
>       URI/IRI scheme semantics: See Section 2.2
>       Encoding considerations: See Section 2.3
>      Applications and/or protocols which use this scheme:
>         See Section 2.4
>       Operations on the 'oid' IRIs: See Section 2.5
>       Interoperability considerations: See Section 2.6
>       Security considerations: See Section 3
>       Contact: 
>          J. Larmouth
>          Rapporteur, ITU-T SG17 ASN.1 & OID
>          Convenor, ISO/IEC JTC 1/SC 6/WG 9
>          International Telecommunication Union (ITU)
>          Place des Nations
>          CH-1211 Geneva 20
>          Switzerland
>          E-mail: [e-mail]
> 
> This has been done in 04
> 
> (7)   For all instances of "See Section xxx", please consider adding
> "of this RFC" (or similar), because conceptually the registration
> template should be able to be used as a standalone document /
> database entry.
> 
> This has been done in 04
> 
> (8)   Also, if you compare with Section 5.4 of RFC 4395, you'll see that the mandatory clauses "Author/Change Controller" and "References"
> are missing at the end of your template.
> 
> This has been done in 04
> 
> (9)   Maybe you will name your organization/role as an abstract change
> controller ("ITU-T SG 17"), or you can simply state "same as
> Contact";
> 
> "Same as Contact" has been used for this in 04
> 
>  maybe a common, shared clause for Contact and Author/
> Change Controller will also be admitted, but that should you
> cross-check with the URI review Expert.  For the References,
> add "RFC xxxx" or "this document, RFC xxxx" (if you have chosen
> to use "this document" or "this RFC" above) and repeat the X.600
> 
> This remark incorrectly said X.600, but should have said X.660.
> 
> reference, and then append an RFC Editor Note like this one:
> 
> We have chosen to use RFC xxxx with an Editor's Note as below.
> 
> The action on this needs review
> 
>     "[[ RFC Editor: Please replace 'xxxx' above by the RFC number
>         assigned to this document. ]]
> 
> Author: John Larmouth
> 
> There are two other editorials that have been reported to us:
> 
> 1)    In the introduction, the paragraph beginning "There has been in existence
> for some time ..." appears twice.  The second copy will be deleted.
> 
> 2)   The ABNF syntax in section 2.1 will be changed from
> 
> <oidiri> = "oid:/" <firstarcid> <subsequentarcid>
>   <firstarcid> = <unicodelabel>
>   <subsequentarcid> = 0*("/" <unicodelabel&gt);
>   <unicodelabel> = 1*(<iunreserved>)
> 
> to
> 
>   oidiri = "oid:/" firstarcid subsequentarcid
>   firstarcid = unicodelabel
>   subsequentarcid = 0*("/" unicodelabel)
>   unicodelabel = 1*(iunreserved)
> 
> (The <xxxx> will be retained in the prose text.)
> 
> This has all been done in 04 
> 
> B3.    Comparison of OID-IRIs
> =======================
> 
> Author:  Lisa Dusseault
> 
> Although we have not carefully reviewed the document, some early
> concerns were raised about the ability to compare all forms of OIDs to
> see if they are in fact the same OID.  Also there were concerns about
> how the ongoing IRI work might affect OIDs, and I wondered if OID URIs
> need to be IRIs at all. 
> 
> Author:  Alison Mankin
> 
>    Is there any concern that the i-d won't speak for itself to
>    the IESG?  perhaps it would be good to add some of the
>    rationale that appears in this email in the i-d, either as
>    part of the introduction or as some appendix information.
>    I believe Olivier's email to Patrik and me gives more context than
>    the i-d does.  This is fine for a technical standard but 
>    going the other way is also fine, and it would mean that
>    less "help" is needed during the IESG's discussion - they'll
>    have the picture right in the draft.
> 
> Olvier text was:
> 
> This new IRI notation for OID is referenced in ITU-T X.660| ISO/IEC 
> 9834-1 (http://www.itu.int/rec/T-REC-X.660-200808-I/en) developed 
> jointly by JTC 1/SC 6 and ITU-T SG 17.
>  
> It doesn't affect existing OIDs as both the dot notation traditionally 
> used by the IETF is still allowed as is the ASN.1 notation with 
> identifiers beginning with a lowercase letter. the 'oid:' IRI scheme is a third notation that allows the use of Unicode characters, something that it considered important for some of our members (particularly from developing countries).
> 
> Another advantage of the 'oid:' IRI notation is that it provides for the use of "long arcs" allowing to overcome the 3 historical top-level arcs. 
> 
> IRI oid:\Internet could, for example, be allocated for OID {iso(1) 
> identified-organization(3) dod(6) internet(1)} which would hide the 
> historical dependence to the DoD that some consider as an issue.
> 
> Author:  Patrik Falstrom
> 
> One of the large issues immediately have to do with matching. You do  not explain the matching algorithm you will use, what you see as  important operations on the URI etc.
> 
> If you look at the International Domain Names standards, you see that  there are significant text about how to normalize the unicode string,  what codepoints to allow, how to handle versioning of the unicode  standard etc. And you MUST include text about that. Is there concern  over these IRIs have a lifespan that is long? If so, you have to  include text about stability of the charset encoding (encoding of  Unicode itself).
> 
> What does the spec that say an OID can have non-digits say, for  example on bidirectional scripts? Display and logical order of  characters, zero-space character etc.
> 
> Olivier Dubuisson:
> 
> Matching between what and what? If I understand what you're asking for, the matching algorithm is in fact specified in a standard under development called the OID resolution system. It looks like some of the content of that standard shall be copied in the I-D.
> 
> Taking the XMPP URI/IRI as an example of an already approved RFC (http://www.rfc-editor.org/rfc/rfc5122.txt), I searched for "operation" and can't find any occurrence of that word. What do you mean by "operations?"
> 
> Again I searched for "normalize", "codepoint" in http://www.rfc-editor.org/rfc/rfc5122.txt and didn't find any occurrence. Since we used some of approved IRI RFCs as example of what to put in the I-D we may have been misled.
> 
> I believe John can add any necessary such text to the I-D (AFAIC this tends to go beyond my expertise :-) ).
> 
> No more than http://www.rfc-editor.org/rfc/rfc5122.txt ;-)
> I suppose we can allow something like oid:/x/y/rrr/aaa where x and y are ASCII string, rrr is a left-to-right Russian string and aaa is a right-to-left Arabic string. 
> 
> We have the following restrictions in ITU-T X.660 | ISO/IEC 9834-1;
> 7.2.5    A non-integer Unicode label shall satisfy the following constraints.
> 7.2.5.1    It shall contain at least one character that is not in the range DIGIT ZERO character to the DIGIT NINE character.
> 7.2.5.2    It shall contain only the following characters, subject to 7.2.5.3:
>     HYPHEN-MINUS character
> FULL STOP character
> LOW LINE character
> TILDE character
> DIGIT ZERO to DIGIT NINE
> LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z
> LATIN SMALL LETTER A to LATIN SMALL LETTER Z
> U000000A0 to U0000DFFE
> U0000F900 to U0000FDCF
> U0000FDF0 to U0000FFEF
> U00010000 to U0001FFFD
> U00020000 to U0002FFFD
> U00030000 to U0003FFFD
> U00040000 to U0004FFFD
> U00050000 to U0005FFFD
> U00060000 to U0006FFFD
> U00070000 to U0007FFFD
> U00080000 to U0008FFFD
> U00090000 to U0009FFFD
> U000A0000 to U000AFFFD
> U000B0000 to U000BFFFD
> U000C0000 to U000CFFFD
> U000D0000 to U000DFFFD
> U000E1000 to U000EFFFD
> NOTE 1 - This allows all the characters that are not reserved in IETF RFC 3987.
> NOTE 2 - The forbidden characters arise from their use (or reservation) for special purposes in ISO/IEC 10646.
> 7.2.5.3    Characters within the above ranges that are identified by ISO/IEC 10646 as "(This position shall not be used)" are excluded from the range.
> NOTE - Tool implementers should note that this designation may be removed in future versions of ISO/IEC 10646 and may choose to be tolerant of violations of this constraint.
> 
> Author:  Lisa Dusseault
> 
> 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. 
> 
> Author:  Patrik Falstrom
> 
> If someone send in a URI to the resolution system, and the URI include unicode characters, then you have to have rules on what resources that URI matches. It is like a search in a database.
> 
> And that boils down to what unicode characters should be defined as being equal with other unicode characters.
> 
> A 1:1 mapping is not a good enough definition.
> 
>  In this context, the "node" and "resource" rules rely on distinct
>  profiles of stringprep [STRINGPREP], and the "domain" rule relies on
>  the concept of an internationalized domain name as described in
>  [IDNA].  (Note: There is no need to refer to punycode in the IRI
>  syntax itself, since any punycode representation would occur only
>  inside an XMPP application in order to represent internationalized
>  domain names.  However, it is the responsibility of the processing
>  application to convert IRI syntax [IRI] into IDNA syntax [IDNA]
>  before addressing XML stanzas to the specified entity on an XMPP
>  network.)
> 
> Author:  John Larmouth
> 
> The ORS provides the following text for the comversion of a Unicode label into DNS input:  "Each Unicode label shall be transformed as specified in IETF RFC 3490, clause 4 which references IETF RFC 3454 (case folding) and IETF RFC 3492 (punycode encoding).  It also
> uses the Compatibility Decomposition, followed by Canonical Composition (KFCD) specified by Unicode 5.2."
> 
> Author:  Larry Masinter
> 
> 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?
> 
> Author:  Lisa Dusseault
> 
> The current description for comparison seems to
> include a DNS lookup which might be problematic in many use cases.
> 
> Author:  Martin DUerst 
> 
> I agree that this (DNS lookup) 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 about 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.
> 
> This text has been reviewed, but it was felt that no change was needed.  Also, adding examples including non-ASCII characters in an RFC that is required to be in ASCII (perhaps with percent encoding) is not considered helpful as an example (because it would lack easy human readability).  No change has been made in this area in 04.
> 
> 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 ITU-T | ISO/IEC ASN.1 group is aware of the consequences, and believes that what we proposed in 03 is precisely what we want.  No change has been made in this area in 04.
> 
> Author:  John Larmouth
> 
> I am sure we understand the issues and implications of comparison, and for our purposes they are acceptable.  
> 
> B4.    oid://xxx or oid:/xxx
> ===================
> 
> Author:  John Larmouth
> 
> 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.
> 
> Author:  Grahame Klyne
> 
> 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.
> 
> (to) 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.
> 
> Author:  Larry Masinter
> 
> 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 translation 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. 
> 
> B5.    Use of an http prefix instead
> =========================
> 
> Author: David Booth
> 
> Why wouldn't an HTTP URI prefix be just as good or better for this
> purpose?  The use of HTTP URI prefixes is described here:
> http://dbooth.org/2006/urn2http/
> Note that HTTP URIs could dramatically improve the adoption rate for a
> new protocol, by resolving to a download of the protocol implementation
> software, as suggested by Graham Klyne:
> http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
> 
> Author:  John Larmouth
> 
> We  have been trying to get an 'oid' IRI scheme registered for a long time now, and the syntax is well embedded in ITU-T standards.  I am operating on behalf of the ASN.1 Group in ISO/IEC and in ITU-T, and we do not want to change horses now.  Moreover, we do not believe that an HTTP prefix would meet our requiremes for use with the Object Identifier Resolution process and for other purposes involving ASN.1-based protocols.
> 
> Author:  Graham Klyne 
> 
> 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. 
> 
> 
>  
> 
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees. 
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. 
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************