Subject: [Ltru] Martin's comments on draft-10

From: Martin Duerst <[email-masked]>
Date: Thu, 02 Mar 2006 18:30:05 +0900

Here are my technical comments on draft-ietf-ltru-matching-10:

Abstract, first sentence: Remove "evaluating", no idea what that
           means or where the matching draft makes this possible.

2.2, first para: "all language tags that constrains" ->
                  "all language tags that constrain"

2.2, second-to-last para: "However wildcards" ->
                           "However, wildcards"

2.3, last para: A complicated dance between things with weight and
      without weight is going on. It is unclear why. My guess is that
      this description was choosen because it is a reasonably simple
      way of describing the results we want. If that's the case,
      please add a sentence or so saying something like "The following
      procedure describes a way to do things, any other procedure that
      achieves the same results is okay, too."

      Low-level editorial:
      "with language ranges ... remain" ->
      "with language ranges ... remaining"

3.1, first para: "Sometimes, different styles of matching might be suited"
               -> "Sometimes, different styles of matching are suited"

General: There are way too many "might"s, "would"s, "could"s, and so on
          in the document. If something is labeled as an example, it's
          clear that it's just an example, so no need for these.
          Similar if there is a qualifier such as "Sometimes".
          Please go through the document and eliminate these as much
          as possible. (changing "might" to "may" is somewhat problematic,
          but often "can" works well)

3.1, nubered list item 3: "language tags find the _exactly_" ->
                           "language tags to find _exactly_"

following para: "They might also be used" ->
                 "Documents can also be used"

following para: "no content's lanugage tag" ->
                 "no language tag"
                 (simpler to read)

following para: "and speeds the performance" ->
                 "and speeds up the performance"
                 (or "and improves the performance")

following para: "into modern equivalents" ->
                 "into their newer equivalents"
                 ('modern' may sound very outdated in a little while)

last para: I was expecting something (e.g. an example) using
            suppress-script here. Can you add one?

3.2, first para: "large number of matching items: as many items"
               -> "large number of matching items, as many items"
                  (I'd be fine with the colon if there wasn't
                   another comma later)

following para: "In filtering, the language range represents the _least_
                  specific (that is, the fewest number of subtags)
                  language tag" ->
                 "In filtering, the language range represents the _least_
                  specific language tag (that is, language tag with
                  the fewest number of subtags)"

following para: This paragraph says virtually the same as the para
                 following the bullet list. Please move them together
                 and merge them as appropriate.

                 Maybe we should also say that even if an item matches
                 two language ranges in the language priority list, it
                 is still only returned once (for the language range
                 with the higher priority).

3.2.1: This doesn't mention case-insensitivity, whereas 3.2.2 does.
        Please make very sure that case-insensitivity is either mentioned
        always or never (except for the very general principle), otherwise
        some careful readers will get confused.

3.2.2: This seems underspecified or unclear. For example, does
        de-DE also match de-Latn-DE, or not? The way I read the
        description, it does, but then the wildcard is somewhat
        pointless. (I have seen that Addison started to discuss
        this, so I'll try to follow that discussion and chime in
        there).

3.3: The sentences in the following para are just too long.
      Please try to split. If you can't, please ask for help.

    This scheme allows some flexibility in finding a match.  For example,
    lookup provides better results for cases in which content is not
    available that exactly matches the user request than if the default
    language for the system or content were returned immediately.  Not
    every specific level of tag granularity is usually available or
    language content may be sparsely populated, so "falling back" through
    the subtag sequence provides more opportunity to find a match between
    available language tags and the user's request.

3.3, example "fr-FR; zh-Hant": I don't see the reason for having
      a sublist in point 5. Either have sublists for fr-FR and
      zh-Hant, too, or just a single list (preferred).

     Btw, I thought that at some point, we adopted the policy of
     writing what all these abbreviations mean. In many places,
     that information is now missing.

two paras later: What if the "*" is not the only one, but the last one?

following 2 paras: Too much could and might. I'd propose that we just
     say "This document doesn't describe how to do lookup with
     extended language ranges. If a protocol thinks it needs
     to use that, it has to define it on its own."

4.1., first para: "for a given user" -> "for a user"

4.1., 2nd para: "is usually compared" -> "is compared"
       (there is already the qualifier "Most" at the start of the para)

4.1., 3rd para: Yes for filtering, NO for lookup, please say so
       (a lot of 4.1 reads as if there were no lookup at all)

4.1., 4th para: "Thus the language range "en-Latn" is probably
       inappropriate in most cases" -> "Thus the language range "en-Latn" is
       inappropriate in most cases"
       ('in most cases' already qualifies)

same para: please don't assume too much knowledge of the registry stuff,
and explain that the suppress-script field means that english using
Latin is tagged en, not en-Latn.

next para, "When used in language tags (as opposed to ranges) ..."
      Again, true for filtering, but reverse for lookup!

next para: "filtering (Section 3.2) matching schemes described below"
      leftover from previous edit?

      last sentence: again, Yes for filtering, but NO for lookup

next para, last sentence: "on the other end of the protocol that
      would make use of that information." -> "on the other end of
      the protocol."

4.4 Change title to "Length Considerations for Language Ranges"
     or so.

     "The same types of restrictions ... could also apply"
     Well, do they, or do they not? Better to reword as follows:
     "Some of the length restrictions for language ranges described
     in Section 4.3 (Length Considerations) of [RFC3066bis] also apply
     to language ranges. Please check [RFC3066bis] to understand
     the restrictions and implications.

     (I think that some of the thoughest restrictions on language
      tags DO NOT apply to language ranges, in particular those
      in the case of adding language information to email headers
      (which I always considered overengineering, but that's a
       separate issue).)

General: There was a matching scheme in RFC 3066. Our document
     should say which of our schemes corresponds (or comes closest)
     to that.

5. IANA Considerations: Should we add a notice to the RFC Editor
    to remove this section for the final publication?

6.: Completely out of date, please remove.

Regards,    Martin. 

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

---

From: Mark Davis <[email-masked]>
Date: Thu, 02 Mar 2006 08:00:14 -0800

Martin Duerst wrote:
> ...
I suggest the following, using a bulleted list, and changing the order 
to be more logical.

Where a language priority list provides "quality weights" for the 
language ranges, such as the use of Q weights in the syntax of the 
"Accept-Language" header (defined in [RFC2616]) 
<http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.html#RFC2616>, 
Section 14.4, and [RFC3282] 
<http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.html#RFC3282>), 
they are handled in the following way. This is a logical  description of 
the process -- implementations may provide the same results in different 
ways. Each example shows progressively what happens to the following 
initial example:

     Example: "fr, ar;q=0.0, en;q=0.5, fr, de, it;q=0.8".

* If the first language range has no weight, it is given a weight of 1.0.

     Example: "fr<b>;q=1.0</b>, ar;q=0.0, en;q=0.5, fr, de, it;q=0.8".

* Language ranges without a weight are given weights equal to the 
weights of the previous language range (processing from first to last).

     Example: "fr;q=1.0, ar;q=0.0, en;q=0.5, fr<b>;q=0.5<b>, 
de<b>;q=0.5</b>, it;q=0.8".

* The language priority list is then sorted from highest priority to 
lowest, with language ranges that share the same weights remaining in 
the same order as in the original language priority list.

     Example: "fr;q=1.0, <b>it;q=0.8, </b>en;q=0.5, fr;q=0.5, 
de;q=0.5<b>, ar;q=0.0</b>".

* Finally, language ranges are removed if they have zero weights or are 
duplicates of previous language ranges.

     Example: "fr;q=1.0, it;q=0.8, en;q=0.5, de;q=0.5".

[ed note: didn't show the strikeout; that probably wouldn't show in the 
text version.]

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 2 Mar 2006 09:49:36 -0800

Comments follow, some substantive.

Addison

Addison Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature. 

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]]
> Sent: 2006?3?2? 1:30
> To: LTRU Working Group
> Subject: [Ltru] Martin's comments on draft-10
> 

Done.
>                   "all language tags that constrain"

Done.
> 2.2, second-to-last para: "However wildcards" ->

Done.
>       achieves the same results is okay, too."

First, an observation: this text was necessary for scoring and has no
bearing on any of the remaining matching schemes (although we might mention
it in lookup).

As such, it is now too specific. Instead I propose this deeper rewrite:

--
<t>Some language priority lists provide "quality weights" for the language
ranges in order to specify the relative priority of the user's language
preferences. An example of this would be the use of "q" values in the syntax
of the "Accept-Language" header (defined in <xref target="RFC2616"></xref>,
Section 14.4, and <xref target="RFC3282"></xref>). If a protocol,
application, or specification needs to assign a weight to a language range
which lacks one in a list, one possible process for assigning the weight
might be to assign the range the same value as that of the preceeding
language range. If the first language range has no weight, it is given the
highest possible value (which would, for example, be "1.0" for
Accept-Language). Language ranges with zero weights might be removed or they
might be treated as meaning "do not return any tags that match this range".
For example, "fr, en;q=0.5, de, it" becomes "fr;q=1.0, en;q=0.5, de;q=0.5,
it;q=0.5". The language priority list SHOULD be sorted from highest priority
to lowest. If weight values have been assigned to items in the list,
language ranges that share the same weights SHOULD remain in the same order
as in the original language priority list. </t>
--
>       "with language ranges ... remaining"

Text changed.
>                -> "Sometimes, different styles of matching are suited"

"are suited to"

Done.
>           but often "can" works well)

I don't have time right now. I might get to that this weekend. The use of
fudge words was to avoid 2119 keywords in another massive edit in the past.
>                            "language tags to find _exactly_"

"language tags to find the one <spanx>exact</spanx> language tag"
>                  "Documents can also be used"

I don't see this sentence?
> following para: "no content's lanugage tag" ->

It is simpler to read, but it is reminder readers of a subtle point: there
is a difference between the tag and content. I modified slightly to read:

--
Since the process can return only one item, it must choose a single item and
it must return some item, even if none of the content's language tags match
the language priority list supplied by the user.
--
>                  (or "and improves the performance")

"Speeds" is already removed, since performance enhancement has never been
measured and this claim is merely "advertising".
>                  ('modern' may sound very outdated in a little while)

No. "Modern" is an ever-changing target. We could add the weasel word "more
modern".
>             suppress-script here. Can you add one?

Arg. No. We deal with that at length in section 4.1 and I feel it is out of
place here. We *permit* an implementation to use the registry for whatever
nefarious purposes but an example would just clutter up the text. If we
needed to have one, I suppose we could take one of the
grandfathered-and-obsolete tags:

  For example, an implementation might replace the range "art-lojban" with
its Preferred-Value "jbo".
>                   (I'd be fine with the colon if there wasn't

No, this is proper use of a colon: it points to an important point, not
merely another phrase. It could be split into two sentences, but that would
reduce the impact.
>                   the fewest number of subtags)"

Done.
>                  with the higher priority).

They were merged and rewritten in last night's edit for John Cowan's
comments.
>         some careful readers will get confused.

Agreed. Changed the main sentence to read:

--
A particular language tag matches a language range  if, in a
case-insensitive comparison, it exactly equals the tag, or 
if it exactly equals a prefix of the tag such that the first character
following the prefix is "-".
--
>         this, so I'll try to follow that discussion and chime in

Already dealt with in draft-11. See other thread as noted.
>     available language tags and the user's request.

I'm not a big fan of this para, but the thoughts it contains are somewhat
difficult to do very much with. I was able to split one sentence:

--
<t>This scheme allows some flexibility
in finding a match. For example, lookup provides better 
results for cases in which content is not available that exactly matches the
user request than if the default language for the system or content
were returned immediately. Not every specific level of tag granularity is
usually available or language content may be 
sparsely populated. "Falling back" through the subtag sequence provides more
opportunity to find a match between available language tags and the user's
request.</t>
--

>       zh-Hant, too, or just a single list (preferred).

The point is that number five is the implementation inserting the range
"ja-JP" into the search sequence and the finding its implementation defined
default. It calls out the fact that you are switching modes and where you do
it (*after* the user's list is exhausted).
>      that information is now missing.

Point them out, although I note that in these examples the meaning of the
tags adds little to the understanding of the reader.
> two paras later: What if the "*" is not the only one, but the last one?

Also fixed last night:

--
If the language range "*" is the only one in the language priority list or
if no other language range follows, the default content SHOULD be returned.
--
>      to use that, it has to define it on its own."

We could do that. But this is only here because someone else felt it
important and I don't see an overriding reason to remove it at the moment.
> 4.1., first para: "for a given user" -> "for a user"

Done.
>        (there is already the qualifier "Most" at the start of the para)

Done, although this para also has picked up a normative statement in
response to my previous question:

--
<t>Most matching schemes make no attempt to process the semantic meaning of
the subtags and the language range is compared, in a case-insensitive
manner, to each language tag being matched, using basic string processing.
Users SHOULD select language ranges that are well-formed, valid language
tags according to <xref target="RFC3066bis"></xref> (substituting wildcards
as appropriate in extended language ranges).</t>
--

I also followed it with this para:

--
<t>Users SHOULD replace tags or subtags which have been deprecated with the
Preferred-Value from the IANA Language Subtag Registry. If the user is
working with content that might use the older form, the user might include
both the new and old forms in a language priority list. For example, the tag
"art-lojban" is deprecated. The subtag "jbo" is supposed to be used instead
or the user might include both in a language priority list: "jbo;
art-lojban".</t>
--
>        (a lot of 4.1 reads as if there were no lookup at all)

Already done.
>        ('in most cases' already qualifies)

Done.
> Latin is tagged en, not en-Latn.

Para read:

--
Most notably, script subtags SHOULD NOT be used to form a language range in
combination with language subtags that have a matching Suppress-Script field
in their registry entry. Thus the language range "en-Latn" is probably
inappropriate in most cases (because the vast majority of English documents
are written in the Latin script and thus the 'en' language subtag has a
Suppress-Script field for 'Latn' in the registry).
--

Para changed to:

--
<t>Many languages are written predominantly in a single script. This is
usually recorded in the Suppress-Script field in that language subtag's
registry entry. For these languages, script subtags SHOULD NOT be used to
form a language range. Thus the language range "en-Latn" is inappropriate in
most cases (because the vast majority of English documents are written in
the Latin script and thus the 'en' language subtag has a Suppress-Script
field for 'Latn' in the registry).
</t>
--
>       Again, true for filtering, but reverse for lookup!

It says this. 

--
When used in language tags (as opposed to ranges), these subtags normally do
not interfere with <xref target="types">filtering</xref>, since they appear
at the end of the tag and will match all prefixes.
--
>       leftover from previous edit?

Since we have essentially the same requirement twice, I merged paras to
read:

--
<t>When working with tags and ranges, note that extensions and most
private-use subtags are orthogonal to language tag matching, in that they
specify additional attributes of the text not related to the goals of most
matching schemes. Users SHOULD avoid using these subtags in language ranges,
since they interfere with the selection of available content. When used in
language tags (as opposed to ranges), these subtags normally do not
interfere with <xref target="types">filtering</xref>, since they appear at
the end of the tag and will match all prefixes. <xref
target="lookup">Lookup</xref> implementations often ignore 
   unrecognized private-use and extension subtags when performing language
tag fallback.</t>
--
>       last sentence: again, Yes for filtering, but NO for lookup

All gone in merge above.
>       would make use of that information." -> "on the other end of

Changed " to services on the other end of the protocol" to "elsewhere"
> 4.4 Change title to "Length Considerations for Language Ranges"

Done.
>      "The same types of restrictions ... could also apply"

Changed "could" => "can"

>      the restrictions and implications.

They might apply: it depends on the context (the protocol, application, or
specification). Changed para to:

--
<t>Language ranges are very similar to language tags in terms of content and
usage. The same types of restrictions on length that apply to language tags
can also apply to language ranges. See <xref target="RFC3066bis"></xref>
Section 4.3 (Length Considerations).</t>
--
>       (which I always considered overengineering, but that's a

Yes, which is why we dumped all this text in favor of a reference to the
Sternly Worded section 4.3 in 3066bis.
>      should say which of our schemes corresponds (or comes closest)

Done. Added this to the end of 3.2.1 (Basic Filtering):

<t>Basic filtering is identical to the type of matching described in <xref
target="RFC3066"></xref>, Section 2.5 (Language-range).</t>
>     to remove this section for the final publication?

Currently this is a placeholder.
> 6.: Completely out of date, please remove.

Placeholding for now.

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 2 Mar 2006 09:51:58 -0800

I'd rather have *less* text about this process than more. This mostly fed and cared for scoring (where the weight values themselves were important). It's only importance in this document is the last step--reordering the list for the convenience of lookup implementers.

Addison Phillips

> From: Mark Davis [mailto:[email-masked]]
> Sent: 2006年3月2日 8:00
> To: Martin Duerst
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Martin's comments on draft-10
> 
> 
> 
> Martin Duerst wrote:
> > ...

---

From: Mark Davis <[email-masked]>
Date: Thu, 02 Mar 2006 10:30:31 -0800

That's not true; if you are using it for plain lookup, the items have to 
be in the right order; and this is what tells you what that order *is*, 
when there are weights, since otherwise it is completely underspecified.

Mark

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 2 Mar 2006 11:22:46 -0800

You're right that lookup relies on the list being ordered. But the assignment of weights isn't strictly necessary: only the ordering of the list is strictly necessary. A list with no weights but in priority order (hence, one suspects "language PRIORITY list") serves just as well.

I agree that the current text does a good job and I'm not in favor or removing it. But I'm also not in favor of scads more text about it, since we don't use the weights for anything and we don't say anything normative about weighting lists. For that matter, we don't even define q-weighting here. It is an artifact of RFC 2616. If we prescribed weight values we might run afoul of existing implementations that assign weights... to no good purpose.

All that said, I agree that the current bulky paragraphs leave a lot to be desired. I've split them up like this:

--
<t>The various matching operations described in this document include considerations for using a language priority list. This document does not define the syntax for a language priority list; defining such a syntax is the responsibility of the protocol, application, or specification that uses it. When given as examples in this document, language priority lists will be shown as a quoted sequence of ranges separated by commas, like this: "en, fr, zh-Hant" (which would be read as "English before French before Chinese as written in the Traditional script").</t>

<t>Some language priority lists provide "quality weights" for the language ranges in order to specify the relative priority of the user's language preferences. An example of this would be the use of "q" values in the syntax of the "Accept-Language" header (defined in <xref target="RFC2616"></xref>, Section 14.4, and <xref target="RFC3282"></xref>). </t>

<t>If a protocol, application, or specification needs to assign a weight to a language range which lacks one in a list, a good strategy would be to assign the range the same value as that of the preceding language range. If the first language range has no weight, it is given the highest possible value (which would, for example, be "1.0" for Accept-Language). Language ranges with zero weights might be removed or they might be treated as meaning "do not return content for any tags that match this range". For example, the list "fr, en;q=0.5, de, it" might become "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". </t>

<t>Regardless of whether weights are assigned or not, the language priority list SHOULD be sorted from highest priority to lowest. If weight values have been assigned to some items in the list, language ranges that share the same weights SHOULD remain in the same order as in the original language priority list, since the order of the list carries meaning for some matching schemes (such as <xref target="lookup">lookup</xref>). </t>
--

I've dithered about saying "the language priority list SHOULD always be sorted" (i.e. insert "always").

NB> I've changed the language priority list examples in the text to use comma separators, since that's what accept-language actually uses. This allowed me to keep the Accept-language example just quoted above intact without immediately following the statement "all examples of LPLs in this document...use semi-colon" with something else!

Addison

Addison Phillips

> Sent: 2006年3月2日 10:31
> To: Addison Phillips
> Cc: 'Martin Duerst'; 'LTRU Working Group'
> > I'd rather have *less* text about this process than more. This mostly
> fed and cared for scoring (where the weight values themselves were
> important). It's only importance in this document is the last step--
> reordering the list for the convenience of lookup implementers.
> >
> > Addison Phillips

---

From: John Cowan <[email-masked]>
Date: Thu, 2 Mar 2006 15:06:11 -0500

Addison Phillips scripsit:

> <t>If a protocol, application, or specification needs to assign a
> weight to a language range which lacks one in a list, a good strategy
> would be to assign the range the same value as that of the preceding
> language range. If the first language range has no weight, it is given
> the highest possible value (which would, for example, be "1.0" for
> Accept-Language). Language ranges with zero weights might be removed
> or they might be treated as meaning "do not return content for any
> tags that match this range". For example, the list "fr, en;q=0.5, de,
> it" might become "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". </t>

I think all these "might"s could legitimately become RFC 2119 MAYs; they say
what the implementation is free to do or not do.

-- 
I don't know half of you half as well           John Cowan
as I should like, and I like less than half     [email-masked]
of you half as well as you deserve.             http://www.ccil.org/~cowan
        --Bilbo                                 http://www.ap.org

---

From: "Addison Phillips" <[email-masked]>
Date: Thu, 2 Mar 2006 12:22:52 -0800

Done.

Addison Phillips

> From: John Cowan [mailto:[email-masked]]
> Sent: 2006?3?2? 12:06
> To: Addison Phillips
> Cc: [email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Fri, 03 Mar 2006 14:58:54 +0900

Hello Addison,

At 04:22 06/03/03, Addison Phillips wrote:
 >You're right that lookup relies on the list being ordered. But the
 >assignment of weights isn't strictly necessary: only the ordering of the
 >list is strictly necessary.

Yes, that's the point that was confusing when I read that part:
There is a dance with q-values, and in the end, they aren't used.
Therefore, I'd a priory prefer a description that gets rid of the
weights as early as possible. But I have to admit that it's difficult
to improve on the current description.

 >A list with no weights but in priority order
 >(hence, one suspects "language PRIORITY list") serves just as well.
 >
 >I agree that the current text does a good job and I'm not in favor or
 >removing it.

Well, except that it's one of these paragaphs with a lot of if's and
would's. In this sense, things actually became worse.

 >But I'm also not in favor of scads more text about it,

Agreed.

 >since
 >we don't use the weights for anything and we don't say anything normative
 >about weighting lists. For that matter, we don't even define q-weighting
 >here. It is an artifact of RFC 2616. If we prescribed weight values we
 >might run afoul of existing implementations that assign weights... to no
 >good purpose.

Yes. HTTP says that the default weight is 1.0, which would mean that
"fr, en;q=0.5, de, it" becomes "fr;q=1.0, de;q=1.0, it;q=1.0, en;q=0.5",
rather than "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". As far as I understand,
at least Apache implements that correctly.

This would also make the algorithm easier to describe :-).

 ><t>The various matching operations described in this document include
 >considerations for using a language priority list. This document does not
 >define the syntax for a language priority list; defining such a syntax is
 >the responsibility of the protocol, application, or specification that uses
 >it. When given as examples in this document, language priority lists will
 >be shown as a quoted sequence of ranges separated by commas, like this:
 >"en, fr, zh-Hant" (which would be read as "English before French before
 >Chinese as written in the Traditional script").</t>
 >
 >preferences. An example of this would be the use of "q" values in the
 >syntax of the "Accept-Language" header (defined in <xref
 >target="RFC2616"></xref>, Section 14.4, and <xref 
target="RFC3282"></xref>). </t>
 >
 ><t>If a protocol, application, or specification needs to assign a weight to
 >a language range which lacks one in a list, a good strategy would be to
 >assign the range the same value as that of the preceding language range. If
 >the first language range has no weight, it is given the highest possible
 >value (which would, for example, be "1.0" for Accept-Language). Language
 >ranges with zero weights might be removed or they might be treated as
 >meaning "do not return content for any tags that match this range". For
 >example, the list "fr, en;q=0.5, de, it" might become "fr;q=1.0, en;q=0.5,
 >de;q=0.5, it;q=0.5". </t>
 >
 ><t>Regardless of whether weights are assigned or not, the language priority
 >list SHOULD be sorted from highest priority to lowest. If weight values
 >have been assigned to some items in the list, language ranges that share
 >the same weights SHOULD remain in the same order as in the original
 >language priority list, since the order of the list carries meaning for
 >some matching schemes (such as <xref target="lookup">lookup</xref>). </t>
 >--
 >
 >NB> I've changed the language priority list examples in the text to use
 >comma separators, since that's what accept-language actually uses. This
 >allowed me to keep the Accept-language example just quoted above intact
 >without immediately following the statement "all examples of LPLs in this
 >document...use semi-colon" with something else!

Good.

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 03 Mar 2006 14:51:27 +0900

>what the implementation is free to do or not do.

I'm quite a bit wary of too many MAYs in the spec (not the words are
the problem, the problem is the content). The previous wording actually
was much more direct.

I'm saying this both as a technical contributor (immagining myself
being in a position to write a spec for a specific protocol) as well
as in my position as a co-chair (where I think it will be easier
to move this spec forward if it is clearer and simpler).

Regards,     Martin.

---

From: Mark Davis <[email-masked]>
Date: Fri, 03 Mar 2006 09:59:33 -0800

I'm ok with simplifying the text, but the current proposal is a bit 
broken. It says "Regardless of whether weights are assigned or not, the 
language priority list SHOULD be sorted from highest priority to 
lowest." But that CAN'T be done unless it is known what the weights are. 
So unless the previous strategy is followed, there is no determinate 
weighting that can be applied in the SHOULD. One would have to do 
something really gummy like say that the language ranges that had 
explicit weights SHOULD be ...

Also, this neglects the duplicate issue. Not a big issue, but some 
people always wonder what you do when you have fr;q=0.5 ... fr;q=0.8. 
Maximum? Geometric mean? And saying "MAY be treated as meaning "do not 
return content for any tags that match this range"" is not relevant for 
this document, since the only thing that matters in any of the 
descriptions herein just care about the ordering.

And it doesn't need to be so tentative and qualified everywhere, we 
already say " Implementations or protocols MAY use different matching 
schemes from the ones described in this document, as long as those 
mechanisms are clearly specified." So we don't have to have so many 
qualifications. We can just say that the mechanism used to handle 
weights is X, since we *already* say that anyone can use different 
schemes. We can just use one qualification on the entire description.

My resulting suggested changes are now even more consise:

<old>

If a protocol, application, or specification needs to assign a weight to 
a language range which lacks one in a list, a good strategy would be to 
assign the range the same value as that of the preceding language range. 
If the first language range has no weight, it is given the highest 
possible value (which would, for example, be "1.0" for Accept-Language). 
Language ranges with zero weights MAY be removed or they MAY be treated 
as meaning "do not return content for any tags that match this range". 
For example, the list "fr, en;q=0.5, de, it" might become "fr;q=1.0, 
en;q=0.5, de;q=0.5, it;q=0.5".

Regardless of whether weights are assigned or not, the language priority 
list SHOULD be sorted from highest priority to lowest. If weight values 
have been assigned to some items in the list, language ranges that share 
the same weights SHOULD remain in the same order as in the original 
language priority list, since the order of the list carries meaning for 
some matching schemes (such as lookup (Lookup) 
<http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.html#lookup>).

</old>

<new>

The matching mechanisms specified in this document use the following 
strategy for resolving weights into an ordered list. If the first 
language range has no weight, it is given the highest possible value 
(e.g, "1.0" for Accept-Language). Language ranges with no weights are 
given the same value as that of the preceding language range 
(successively). The language priority list is then sorted from highest 
priority to lowest, where language ranges that share the same weights 
remain in the same order as in the original language priority list. 
Language ranges are removed if they have zero weights, or occur 
previously in the list. For example, the list "fr, de, es;q=0.0, 
en;q=0.5, de, it;q=0.8, fr" would become "fr;q=1.0, it;q=0.8, en;q=0.5, 
de;q=0.5". This strategy MAY be modified as per Section 3.

</new>