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
- Re: [Uri-review] draft-larmouth-oid-iri-00 John Larmouth
- Re: [Uri-review] draft-larmouth-oid-iri-00 Alfred Hönes