Subject: [Ltru] Comments on draft-matching-07

From: "Doug Ewell" <[email-masked]>
Date: Sun, 20 Nov 2005 19:45:51 -0800

Here are my comments on draft-matching-07.  Most of these are editorial.

Section 2.1: "It can get more complex: a speaker may wish to fallback 
from Skolt Sami to Northern Sami to Finnish."

-> This should be "fall back," two words when used as a verb like this, 
but one word as a noun ("a fallback mechanism").  Please use 
search-and-replace for this.

Section 2.2:  "by adapting the ABNF[RFC4234] from HTTP/1.1 [RFC2616] :"
and later "Basic language ranges were originally described in [RFC3066] 
and HTTP 1.1 [RFC2616]"

-> Please call it either "HTTP 1.1" without the slash or "HTTP/1.1" with 
the slash, consistently.

Section 2.4:  "because the vast majority English documents are written 
in the Latin script"

-> Add "of "after "majority."

Section 2.4:  "note that extensions and most private use subtags are 
orthogonal"

-> "Private-use" should be hyphenated when used before the noun it 
modifies, like this.  It would not be hyphenated as part of a phrase, 
like "these subtags are for private use."  This occurs in various 
places, so please use search-and-replace here too.

Section 3.1:  "content labeled "zh-CN" is morely likely to match"

-> "more" likely

Section 3.2:  "Filtering can produce either ordered or unordered set of 
results."

-> Add "an" before "ordered," and optionally after "unordered" as well.

Section 3.2:  "measurment"

-> Spelling error (typo) still not corrected.

Section 3.2.2:  "zh-Latn-CN-boont"

-> "boont" is not a variant subtag.  I would much prefer not to use it 
in an example.  Try a real variant like "1901" or "nedis."

Section 3.2.3:  "Missing end subtags are expanded as the empty 
string..."

-> Originally (based on draft-matching-06) I was going to complain that 
this section contradicted itself.  In some places it appeared to say 
that all "missing" subtags were expanded as asterisk.  Addison has 
rewritten this passage to clarify the different treatment of tags and 
ranges, and I'll have to read the new text carefully to see whether it 
de-confused me.

Section 3.2.3:  "Examples of various tag's distances from the range 
"en-US":... "fr-FR"          384 (language & region mismatch)"

-> If language counts as 256 and region as 32, then this score should be 
256 + 32 = 288, not 384.  Again I need to read the revised text to see 
if the examples make more sense now.

"en-Latn-US"       0 (all fields match)

-> In reading this, it appears that "en-Brai-US" would also give a 
perfect 0 score, and for that matter so would "en-Egyp-US".  Is that 
correct?  We aren't looking at Suppress-Script here, so that doesn't 
factor into anything (unless we are one of the "implementations or 
protocols" that customize things).

Section 7:  "might be used to track specific individual's activities."

-> This is not grammatical.  It should be "track a specific individual's 
activities" if we are talking about one individual, or "track specific 
individuals' activities" (notice the apostrophe) if we are talking about 
multiple individuals.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Mon, 21 Nov 2005 18:04:48 +0900

>Here are my comments on draft-matching-07.  Most of these are editorial.

Thanks, great. I'm picking out one (maybe the only one,
apart from the fact that in some places, you planned
to look at the new version of the document anyway)
issue that doesn't look editorial.

perfect 0 score, and for that matter so would "en-Egyp-US".  Is that 
correct?  We aren't looking at Suppress-Script here, so that doesn't factor 
into anything (unless we are one of the "implementations or protocols" that 
customize things).

I got the same impression. It doesn't look like that would make sense.
I was thinking that maybe how this should be handled is as follows:

- In a range, a '*' in script position stays a '*'; an absent
   script field gets converted into the 'suppress-script' value
   for that lanugage if such a value is available. Otherwise, this
   expands into a '*'.

- The corresponding content tags are also expanded by suppress-script
   information where available.

- The matching is done on the resulting expanded tags, with a '*'
   matching anything.

This would give the following:

Range: en-US -> en-Latn-US
Tag: en-Brai-US -> en-Brai-US
-> match on language and region, but not on script

Range: en-*-US -> en-*-US
Tag: en-Brai-US -> en-Brai-US
-> match on all fields

Range: en-US -> en-Latn-US
Tag: en-US -> en-Latn-US
-> match on all fields

I'm rather sure somebody will find a hair in this soup,
if not some bigger obstacle, but at least for the cases
above, it would work reasonably as expected.

Regards,    Martin

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 21 Nov 2005 06:48:34 -0800

>   information where available.

This would seem to work.  Distance metric filtering (still referred to 
as "scored filtering" in Section 3.1) is already listed as the only type 
of filtering that requires access to the registry.  As long as we have 
to go there to resolve grandfathered and obsolete (sub)tags, we may as 
well resolve Suppress-Script at the same time.