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

John Larmouth <j.larmouth@btinternet.com> Tue, 02 December 2008 20:58 UTC

Return-Path: <uri-review-bounces@ietf.org>
X-Original-To: uri-review-archive@megatron.ietf.org
Delivered-To: ietfarch-uri-review-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1923A6B58; Tue, 2 Dec 2008 12:58:33 -0800 (PST)
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1132B3A6B58 for <uri-review@core3.amsl.com>; Tue, 2 Dec 2008 12:58:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExKpkF0hAvHj for <uri-review@core3.amsl.com>; Tue, 2 Dec 2008 12:58:30 -0800 (PST)
Received: from smtp807.mail.ird.yahoo.com (smtp807.mail.ird.yahoo.com [217.146.188.67]) by core3.amsl.com (Postfix) with SMTP id 2D4563A6778 for <uri-review@ietf.org>; Tue, 2 Dec 2008 12:58:29 -0800 (PST)
Received: (qmail 37839 invoked from network); 2 Dec 2008 20:58:25 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fe3n5kd7D8fbntq60XlUmbtpb96fwfoeaftKnmjZkDucJaO+23au5fdV7eLrnrQw9XFEKh77rMWfPWPkQda4VNKSAjsUNQy6KgyT6hSYm6k5UT/WXyOGpL09CZvtbbDQmQyV6dHJKabmHYmhOHKInQzmyTkjvfG7CkKauPZUznQ= ;
Received: from unknown (HELO ?192.168.1.65?) (j.larmouth@86.160.155.70 with plain) by smtp807.mail.ird.yahoo.com with SMTP; 2 Dec 2008 20:58:24 -0000
X-YMail-OSG: 9GnPLywVM1lBixkEWGnIMBS2ejHU42YFVa0ioVVhp.9OpUL4XW9E96bUnHHHCXSF.lKftry_JoJWUffdLtnLz0Jj4ZbM37MWVVx1VkSPSrPy0hiL9v_GeRb4kB9TWoTd1tHGCXd6KHTpmcjhzFAOWHTDhLoxly4jgt2VdNrlOdFg7C_HFP6a1RRL7eE-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4935A170.7030107@btinternet.com>
Date: Tue, 02 Dec 2008 20:58:24 +0000
From: John Larmouth <j.larmouth@btinternet.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Alfred � <ah@tr-sys.de>
References: <200812020115.CAA06040@TR-Sys.de>
In-Reply-To: <200812020115.CAA06040@TR-Sys.de>
Cc: uri-review@ietf.org, j.larmouth@salford.ac.uk
Subject: Re: [Uri-review] draft-larmouth-oid-iri-00
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: j.larmouth@btinternet.com
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: uri-review-bounces@ietf.org
Errors-To: uri-review-bounces@ietf.org

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                               j.larmouth@btinternet.com
    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
Uri-review@ietf.org
https://www.ietf.org/mailman/listinfo/uri-review