Subject: Re: [Uri-review] draft-larmouth-oid-iri-00

From: John Larmouth <[email-masked]>
Date: Tue, 02 Dec 2008 20:58:24 +0000

Alfred,

Very many thanks for your full response.

We will dsicuss your comments and both post a new draft and send a "Resolution 
of comments" to Uri-review.

Thanks,

John L

Alfred � wrote:

> This is a review of draft-larmouth-oid-iri-00.
> 
> This draft gives some motivations for introducing a new URI
> scheme, 'oid' to allow ISO/ITU-T OIDs to be represented as
> Uniform Resource Identifiers in the Internet and elsewhere.
> 
> 
> (A)  Abstract and Section 1
> 
> The leading 'prose' part (Section 1) of the draft already
> seems to be in rather good shape.
> 
> There's only one detail requiring action, regarding references:
> 
> Since the Abstract will become part of the metadata of the
> intended RFC, it does not make sense to quote there a reference
> using an anchor defined in the References section of the document.
> Within the Abstract, (short) common language document titles
> should be used, where necessary; therefore I suggest to simply
> drop the square brackets around "ITU-T X.660" in the Abstract.
> 
> Within the Introduction, however, (more) precise formal references
> with anchors pointing to the References Section should be given.
> 
> There's another deficiency, which alternatively could be accredited
> to section 2: I could not deduce from the draft text the reasons to
> aim for an 'oid' URI scheme and not for a formal URN namespace 'oid'.
> The description of the resources is so vague that I am not sure
> that this decision has ever been considered based on the nature
> of the resources to be identified.  I might err here, but I see
> the need for elaborations.
> 
> 
> (B)  Section 2
> 
> (B.1)  'markup' style
> 
> Since the formal syntax definition makes use of ABNF, which
> devotes double-quotes to delineate case-insensitive string
> literals, it has proven useful to not overload double-quotes
> as a markup for other parts of the ABNF when they appear in the
> prose text.  The ABNF Standard, on its initial text pages
> describes the utility of the classical BNF style of enclosing
> syntax production (rule) names in angle brackets in this case.
> 
> To further offload the double-quote character, in the last years
> it has become common practice to enclose URI Scheme names in
> single quotes, within URI Scheme defining documents.
> 
> I therefore strongly recommend to perform the following
> substitutions troughout the running text:
> 
>         "oid"              -->   'oid'           (URI/IRI Scheme)
> 
>         "oidiri"           -->   <oidiri>        (ABNF rule names)
>         "firstarcod"       -->   <firstarcid>
>         "subsequentarcid"  -->   <subsequentarcid>
>         "unicodelabel"     -->   <unicodelabel>
> 
> (B.2)  Formal ABNF
> 
> One of the driving forces behind ABNF was the desire to remove
> the need for recursive productions, both for better intellegibility
> by human beings, and for efficiency in the code generated by some
> syntax analysis toolkits.
> Therefore, I suggest to replace the third production by an equivalent
> non-recursive form, using ABNF repetition indicators.
> 
> OLD:
> 
> |  subsequentarcid = "/" unicodelabel [susequentarcid]
> 
> NEW:
> 
> |  subsequentarcid = 1*("/" unicodelabel)
> 
> 
> The final ABNF rule makes use of the external rule name <iunreserved>:
> 
> |  unicodelabel = iunreserved
> 
> This external rule name itself deserves a precise reference, for
> instance by adding an explanatory sentence or an ABNF comment like
> 
>       "see Section 2.2 of [RFC3987]"
> or
>       "<iunreserved> is defined in Section 2.2 of [RFC3987]." .
> 
> Even worse, I strongly suspect that this rule is not what you want --
> it would only allow a single (restricted) character!
> Most probably you want to say:
> 
> |  unicodelabel = 1*iunreserved
> 
> (B.3)   Section 2.5, last paragraph
> 
> I diagnose an unexpected identification between the identifier
> of a resource and the resource itself, and suggest the following
> textual improvement in order to avoid that:
> 
>    NOTE - The last identified node is not necessarily a leaf of the
> |  tree, but is the identified resource.
> ---          ^^
>    NOTE - The last identified node is not necessarily a leaf of the
> |  tree, but it designates the identified resource.
>              ^^^^^^^^^^^^^
> 
> 
> (B.4)  issue with matching rule
> 
> It's a frequent flaw to ignore that RFC 3986 has specified that
> URI scheme names are case-insensitive.  Therefore, the following
> sentence contradicts STD 63:
> 
>    Matching rules are based on exact equality of the sequence of
>    abstract Unicode characters forming the IRI.
> 
> Perhaps all you want to state is that equality of 'oid' URIs/IRIs
> shall be based on exact equality of the slash-separated sequence
> of <unicodelabel>s building up the identifier.
> 
> 
> (B.9)  Security Considerations
> 
> The non-considerations presented here will be a show-stopper
> in the IESG, if not replaced by serious considerations.
> Please see the URI Scheme specifications published in the recent
> past (to locate these, please look up the IANA URI Scheme registry).
> 
> See also Section 2.7 of RFC 4395.
> 
> 
> (C)  IANA Considerations
> 
> The draft does not contain an "IANA Considerations" section,
> which is a MANDATORY part of each IETF document.
> Please see RFC 4395 (and RFC 5226, which recently has superseded
> RFC 4234) for more details.
> 
> You may either transform Section 2 into an expanded, filled-out
> registration template according to Section 5.4 of RFC 4395,
> or you may add an additional section whith a short form of the
> template that refers to the various subsections of Section 2
> where appropriate.
> 
> Either way, the text must contain clear instructions to the IANA
> that you want the following filled out template to be added to the
> URI Schemes registry, in the section entitled "IANA Considerations",
> because IANA should only need to look at that section (and follow
> pointers) for its work to be efficient.
> 
> 
> (D)  Rationale behind the URI Scheme, and its applicability
> 
> As already mentioned above, the draft does not show to sufficient
> extent the need for a new URI Scheme; it remains open why a formal
> URN Namespace would not have been sufficient.
> 
> Please consult RFC 4395, in particular Sections 2.1, 2.3, 2.4, 2.5,
> and 2.7 for a discussion of topics that should be elaborated upon
> more extensively in the draft.
> 
> The text needs to explain what kind of operations some software
> making use of 'oid' URIs is expected to perform, if any, etc.
> Absence of such operations needs to be stated expressly, not
> by omission of text, in order to properly delineate the
> expectations of potential applicants for 'oid' URIs, their
> consumers, and software developers.
> 
> The 'classical' (numerical) OIDs are well-known in the IETF
> as identifiers for (digital) information objects being of
> utility and interest mainly for use embedded in protocol
> software.  Does the recent extension leave this area behind
> or is it still constraint to this field?  These kinds of
> questions should be discussed, or at least sketched, with
> references to supporting documents (Informative References),
> if there are any beyond ITU-T X.660.
> 
> 
> (E)  References
> 
> The use of all entries currently listed in Section 4.2 seems to
> be rather Normative.  So please promote these entries into 4.1.
> 
> I also miss a (Normative) ref. for UTF-8 (STD 63).
> 
> 
> Kind regards,
>   Alfred H�nes.
> 

-- 
    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 (Business): +44 161 408 3695        Fax: +44 161 928 8069
    Tel (Private): +44 161 928 1605
_______________________________________________
Uri-review mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uri-review