Subject: Re: [Ltru] editor's copy of draft-20 updated...

From: "Doug Ewell" <[email-masked]>
Date: Fri, 5 Dec 2008 20:37:30 -0700

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

>>> ("These" => "The latter" for clarity; "each" => "" since they 
>>> haven't got a record each, instead they have range records (which I 
>>> don't like...).)
>>
>> Note that we got rid of ranges, I believe.
>
> They are still in lstreg-4646bis-draft-07.txt (and are still described 
> in draft-ietf-ltru-4646bis-20.txt).

We did have a discussion about getting rid of ranges, but the outcome of 
the discussion (IIRC) was that there wasn't enough benefit to justify 
adding about 600 new records.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

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

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 5 Dec 2008 21:18:54 -0700

"Phillips, Addison" <addison at amazon dot com> wrote:

> There is/was an existing prohibition on registering a prefix for a 
> prefix-free variant.
>
> What is a possibly substantial change is that we allow prefixes to be 
> removed provided the overall set of recommended language tags remains 
> a superset of the original.

As long as we are willing to throw the doors open to technical changes, 
or even clarifications, this long after WG Last Call...

We should be looking at the underlying reason we have these complex 
rules about adding or changing prefixes for a variant.  The reason is 
that we want the option of adding more prefixes if the state of 
knowledge about that variant increases, but we don't want to remove 
possibilities and turn perfectly good language tags into invalid or 
ill-advised ones.  It's not the *actual prefixes* that matter, but the 
range of tagging options they represent.

So what we should be doing is thinking of the prefixes associated with a 
variant as a set, as Addison said, and allowing the set to be replaced 
only by a superset of the original set, regardless of the individual 
prefixes themselves.

That means that the set {xx-Latn} can be replaced by {xx-Latn, xx-Cyrl}, 
and I think we all agree up to that point.  But it also means the set 
{xx-Latn, xx-Cyrl} can be replaced by the set {xx}.  That is, the set of 
tags for "language xx written in Latin or Cyrillic" can be replaced by 
the set of tags for "language xx written in any script, or no script, or 
not written."  It makes no sense to express the latter set as {xx, 
xx-Cyrl}.  That would be like saying "the set of people who live in 
Illinois, plus the set of people who live in Chicago."

The empty set of prefixes { } doesn't really fit the notational model, 
but the premise is the same: it represents the set of all possible 
prefixes, unconstrained, which is undeniably a superset of all other 
sets.  Because of this, any set of prefixes could be replaced by the 
empty set -- that is, any variant with one or more prefixes could have 
its scope widened by removing all of the prefixes.  This "ultimate 
widening" should ABSOLUTELY be allowed, and may not be undone or 
otherwise further modified.

Whatever rules are drawn up to restrict the changing and deleting of 
prefixes should take this model into account, and should not focus on 
preserving the individual prefixes.

> With the previous wording, if you had this record:
>
> Subtag: foobar
> Prefix: xx-Latn
> Prefix: xx-Cyrl
>
> You could "widen" it by modifying one of the ranges or adding another, 
> but you MUST NOT remove an entry. So either of these would be 
> acceptable:
>
> Subtag: foobar
> Prefix: xx
> Prefix: xx-Cyrl
>
> --
>
> Subtag: foobar
> Prefix: xx-Latn
> Prefix: xx-Cyrl
> Prefix: xx
>
> But the following record (now permitted) was NOT permitted:
>
> Subtag: foobar
> Prefix: xx
>
> This in spite of the fact that it is syntactically equivalent.
>
> Probably this change should prohibit removing the last prefix (the 
> ultimate widening)??

---

From: Kent Karlsson <[email-masked]>
Date: Sat, 06 Dec 2008 11:34:32 +0100

Den 2008-12-06 05.18, skrev "Doug Ewell" <[email-masked]>:

sets.

Indeed, there is no way to express "the empty set of prefixes" in the
registry. Not having any "Prefix" fields in a record means the universal set
of prefixes. (Or would be equivalent to "Prefix: *", but that syntax is not
permitted.

> Because of this, any set of
> prefixes could be replaced by the 
empty set -- that is, any variant with one
> or more prefixes could have 
its scope widened by removing all of the
> prefixes.  This "ultimate 
widening" should ABSOLUTELY be allowed, and may not
> be undone or 

Whatever rules are drawn up to
> restrict the changing and deleting of 
prefixes should take this model into
> account, and should not focus on

---

From: Kent Karlsson <[email-masked]>
Date: Sat, 06 Dec 2008 11:38:06 +0100

Den 2008-12-06 05.18, skrev "Doug Ewell" <[email-masked]>:

Indeed, there is no way to express "the empty set of prefixes" in the
registry. Not having any "Prefix" fields in a record means the universal set
of prefixes. (Or would be equivalent to "Prefix: *", but that syntax is now
not permitted.)

Which indeed was the goal of my proposed change. If we allow "widening" in
principle for prefixes, there should be no irrelevant restrictions on how
that widening is expressed as a list of Prefix fields in a record.

    /kent k

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 6 Dec 2008 11:41:01 -0700

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

>> The empty set of prefixes { } doesn't really fit the notational 
>> model, but the premise is the same: it represents the set of all 
>> possible prefixes, unconstrained, which is undeniably a superset of 
>> all other sets.
>
> registry. Not having any "Prefix" fields in a record means the 
> universal set of prefixes. (Or would be equivalent to "Prefix: *", but 
> that syntax is not permitted.

I tried to say that, but didn't word it very well.  The set of 
*expressed* prefixes in the Registry is a representation, but not 
necessarily 1-to-1, of the set of *allowable* prefixes in language tags.

As an example, ietf-languages registered the variants '1901' and '1996' 
in an attempt to bring the registered tags "de-1901" and company into 
the world of regular tags, constructed from subtags.  Originally, under 
RFC 3066, the following tags had been registered:

de-1901
de-AT-1901
de-CH-1901
de-DE-1901
de-1996
de-AT-1996
de-CH-1996
de-DE-1996

Notice how ietf-languages did not register the variants '1901' and 
'1996' each with prefixes of "de", "de-AT", "de-CH", and "de-DE". 
Instead, it was (correctly) felt that the single prefix "de" would cover 
the other possibilities (and potentially more).

Similarly, the single prefix "xx" would cover the two prefixes "xx-Latn" 
and "xx-Cyrl", and more.  Adding one expressed prefix and deleting two, 
a net reduction of one *expressed* prefix in the Registry, would 
substantially increase the number of *allowable* prefixes for this 
variant in tags.  That's why I don't agree with requiring the new set to 
be {xx-Latn, xx-Cyrl, xx}.

The extreme example of this is that the empty set of expressed prefixes 
corresponds to the universal set of allowable prefixes.  'fonipa' has no 
expressed prefixes; therefore according to the syntax, it can validly be 
used in a tag with any prefix.  (Side note: I'm aware that it makes no 
sense to use 'fonipa' with, say, "zh-Hani".  It is not my intent here to 
argue in favor of adding logic to the syntax to support non-initial 
prefixes, to prevent people from engaging in this sort of unwise 
tagging, especially not at this late date.)

On the other hand, as Kent implied, there is no way to express "the 
empty set of *allowable* prefixes" in the Registry.  There would be no 
purpose for such an expression, since it would clearly make no sense to 
register a variant that could not be used with any prefix.