[Ltru] Re: gen-art review and response...

Ted Hardie <hardie@qualcomm.com> Fri, 30 June 2006 18:33 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwNo1-0007QQ-GP; Fri, 30 Jun 2006 14:33:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwNo0-0007QL-CE for ltru@ietf.org; Fri, 30 Jun 2006 14:33:28 -0400
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwNnx-0004ET-TN for ltru@ietf.org; Fri, 30 Jun 2006 14:33:28 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5UIXOxx004424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Jun 2006 11:33:24 -0700
Received: from [10.0.1.5] (dhcp-campbell-28.qualcomm.com [129.46.225.24]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k5UIXLDv010131; Fri, 30 Jun 2006 11:33:23 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230901c0cb1e48ef6e@[10.0.1.5]>
In-Reply-To: <000001c69c65$c1d37ad0$650a0a0a@ds.corp.yahoo.com>
References: <000001c69c65$c1d37ad0$650a0a0a@ds.corp.yahoo.com>
Date: Fri, 30 Jun 2006 11:33:19 -0700
To: Addison Phillips <addison@yahoo-inc.com>, 'LTRU Working Group' <ltru@ietf.org>
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by numenor.qualcomm.com id k5UIXOxx004424
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Cc:
Subject: [Ltru] Re: gen-art review and response...
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org

At 9:53 AM -0700 6/30/06, Addison Phillips wrote:
>All,
>
>Following this note is a copy of the Gen-Art review of draft-matching. I have placed my responses to it into the note with appropriate markup.
>
>Ted: your guidance please?
>
>Addison

As you did with the private reply from Brian, send a copy of this directly to him
(brc@zurich.ibm.com)  While he is on the gen-art list, a direct note is
best.

I believe these two issues:

>s2, para 3: s/%2A/%x2A/
>s3.3.2, para 2 (Item 1.): s/%2D/%x2D/


should be fixed with an RFC Editor note.  Please let me know if you or the chairs
disagree.  I believe the other issues are adequately explained by your exchange
with Elwyn (and later with Brian) and so do not require text updates.
			regards,
				Ted Hardie






>========
>
>I am the assigned Gen-ART reviewer for
>draft-ietf-ltru-matching-15.txt. For background on Gen-ART, please see the FAQ at
><http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
>This set of comments should have reached you during IETF Last Call but due to holidays I didn't receive the commission till after the last call ended.Since I see that the authors have already updated the document since the end of last call, please consult your AD as regards what action to take on these comments.
>
>Summary
>=======
>This document is almost ready for BCP.  I have one issue with it (noted below) which IMO needs to be considered. There are also two 'bugs' in the specification of character codes and a number of suggested editorial changes which could be passed to the RFC Editor
>
>Bugs:
>Assuming we are supposed to be using RFC4234 conventions:
>s2, para 3: s/%2A/%x2A/
>s3.3.2, para 2 (Item 1.): s/%2D/%x2D/
>
>[Addison] Good catch.
>
>Comment/Issue:
>I find the whole use of wildcards in extended language ranges counter-intuitive.  The idea that de-de and de-*-de provide the same matches but the * in *-de is meaningful makes my brain hurt, however I see some of the reasoning which has lead to this unpleasant result.
>
>Be that as it may, if I understand the intention of this document correctly, the syntactical specification of extended language ranges in s2.2 is intended to allow for a number of matching algorithms, not necessarily defined in the draft.  It therefore seems inappropriate to partially specify the semantics in s2.2 as they are used in the extended filtering algorithm defined in s3.3.2 when some other matching algorithm might apply different semantics. Any semantics that are specified in s2.2 should be those that are intended to apply for any matching algorithm - there may not be any!
>
>[Addison] That is the intention: other algorithms that use extended language ranges must interpret wildcards in the same way. Other range syntaxes are possible: the WG considered other such for "extended language ranges".
>
>My initial response to s2.2 before reading s3.3.2 was as follows:
>s2.2: Sequences of wildcards and empty subtag sequences:  This section probably needs to be more explicit in a number of ways:
>a) Does 'any sequence of subtags' include 'an empty sequence of subtags'?
>
>[Addison] Yes. Intentionally.
>
>b) The ABNF allows forms such as aa-*-*-zz:  Is this intended?  If so is it equivalent to aa-*-zz or not?
>
>[Addison] Yes. And Yes.
>
>c) As a particular case of (b) is *-*-zz equivalent to *-zz or is the wildcard on the primary language tag special?
>
>[Addison] They are equivalent. The primary "*" is special in that it cannot be removed, but it still matches a *sequence* of subtags.
>
>d) Is it necessary to add a trailing wildcard to soak up subtags after the last match (this might become obvious in the matching algorithms but a comment here might help)?
>
>[Addison] No. The trailing wildcard is implied.
>
>To summarize, I suggest:
>- Removing the last paragraph of s2.2 and replacing it with a summary of any general semantics expected to apply to an Extended Language Range (e.g., any sequence of wildcards is equivalent to one wildcard, final wildcards can be omitted, a wildcard matches any sequence (might be empty or non-empty) of subtags)
>- Reordering s3.3.2 to describe the intention and give the examples before specifying the algorithm - this would considerably aid understanding IMO.  Maybe clarify that -*-* is equivalent to -* etc.
>
>[Addison] The problem here is that extended langauge ranges (and language ranges in general) do not have a way to specify negation. The WG went round-and-about that topic for awhile. While such a syntax is possible, it wasn't necessary to the matching schemes described in the draft.
>
>Editorial:
>s1, para 4: Presentation might be clearer as a bulleted list.
>
>[Addison] Possibly, but not necessary.
>
>s1, para 5: s/-14/(actual version number)/
>
>[Addison] That is the actual version number of draft-registry aka RFC 3066bis.
>
>s2, para 1:  Make it clearer that  '(section 14.4)' applies to RFC2616 and not the current document.
>
>[Addison] Okay.
>
>s2, para 3: A cross-reference to Section 2.1 of [RFC3066bis] where the syntax of language tags is defined would be helpful. s2, para 3: For consistency, "hyphen" should be given as a hex value also as in [RFC3066bis] - hyphen ("-",    ABNF [RFC4234] %x2D).
>
>[Addison] Okay.
>
>s2.1, para 1: The phrase 'has the same syntax as an [RFC3066] language tag' is undesirable since this specification obsoletes RFC3066.  Something like 'has either a syntax which reflects the overall structure of [RFC3066bis] language tags or ...' would be better.
>
>[Addison] ... but would be wrong. RFC 3066's syntax was different and more general. The language ranges presented here have the same syntax as RFC 3066 tags, i.e.:
>
>   Tag = 1*8alphanum *["-" 1*8alphanum]
>
>s2.1, para 3: s/Such ill-formed ranges/Any ranges that are not well-formed/
>
>[Addison] I don't care for this edit.
>
>s2.3, para 1: Transliteration/Internationalization issue: Many of the Sámi using peoples transliterate Sámi as Saami  rather than Sami.
>
>[Addison] Noted. This is a side effect of not having I-Ds use UTF-8 as their encoding. Perhaps someday I-Ds will join the modern world in this respect :-).
>
>
>
>
>
>Addison Phillips
>Internationalization Architect - Yahoo! Inc.
>
>Internationalization is an architecture.
>It is not a feature.


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru