Subject: [Ltru] Minor editorial nits in -matching-10-var1

From: John Cowan <[email-masked]>
Date: Wed, 22 Feb 2006 15:48:18 -0500

In 2.3, for "semi-colons" read "semicolons", and for "Chinese as written"
read "Chinese written".

The last graf in 3.3 is not specific to lookup and should be hoisted to
section 3 (properly generalized)

The two penultimate grafs in 3.3 are also not specific to lookup and should
be moved to 2.3 (properly generalized)

The bullet points in 4.1 are not functionally any different from any
of the other grafs in 4.1 and should be made normal grafs, deleting
"When working with" etc. from just before the bullets as well as the 
preceding paragraph.

I don't understand what 4.2 is doing in -matching at all; it seems to
belong in 3066bis only.

In 4.4 it still says that removing "*" from the end of a range can 
change the meaning: this is false in -var1.

Also in 4.4: for "truncate a tag" read "truncate a tag or range".

-- 
Real FORTRAN programmers can program FORTRAN    John Cowan
in any language.  --Allen Brown                 [email-masked]

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

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 22 Feb 2006 13:11:38 -0800

See below.

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: John Cowan [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2006 12:48 PM
> To: [email-masked]
> Subject: [Ltru] Minor editorial nits in -matching-10-var1
> 

Yes for the bad hyphen. The "as" formulation we've used elsewhere.
> section 3 (properly generalized)

Caught that today. Used this rewrite:

<t> Implementations or protocols MAY use different matching schemes
than the ones described in this document, as long as those mechanisms are
clearly specified.</t>
> be moved to 2.3 (properly generalized)

Not quite. The latter para is concerned with Q weights and goes in section
2.3. The former para goes in the section on extended language ranges,
mutated as follows:

<t>Implementations that specify basic ranges MAY map extended language
ranges to basic language ranges: if the first subtag is a "*" then the
entire range is treated as "*" (which matches the default content),
otherwise each wildcard subtag is removed. For example, if the language
were "en-*-US", then the range would be mapped to "en-US".</t>
> "When working with" etc. from just before the bullets as well as the

DONE.
> I don't understand what 4.2 is doing in -matching at all; it seems to

I agree, but we've kept it until now. We'd be better off to point to the
text in 3066bis and add this note:

<t>Selecting content using language ranges requires some understanding by
users of what they are selecting. The meaning of the various subtags in a
language range are identical to their meaning in a language tag (see Section
x.x in RFC 3066bis), with the addition that the wildcard "*" represents any
matching sequence of values.</t>
> change the meaning: this is false in -var1.

DONE. I'd be happier still if we just referred to the otherwise identical
text in 3066bis.
> Also in 4.4: for "truncate a tag" read "truncate a tag or range".

See my last comment.