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 ======== 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. _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
