Subject: [Ltru] I-D Action:draft-ietf-ltru-4646bis-19.txt

From: [email-masked]
Date: Tue, 2 Dec 2008 21:30:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Language Tag Registry Update Working Group of the IETF.

	Title           : Tags for Identifying Languages
	Author(s)       : A. Phillips, M. Davis
	Filename        : draft-ietf-ltru-4646bis-19.txt
	Pages           : 87
	Date            : 2008-12-02

This document describes the structure, content, construction, and
semantics of language tags for use in cases where it is desirable to
indicate the language used in an information object.  It also
describes how to register values for use in language tags and the
creation of user-defined extensions for private interchange.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-19.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 3 Dec 2008 08:33:58 -0800

Hi -

As co-chair...

With http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-19.txt
and http://www.ietf.org/internet-drafts/draft-ietf-ltru-4645bis-08.txt
now available, we plan to hand these to our AD in the next few days
for consideration by the IESG for publication as RFCs, replacing
the current RFC 4645 and RFC 4646.

If you spot a "show-stopper" technical problem in either of these,
don't hesitate to post it to this list.  For any other issues, I strongly
suggest holding them for the IETF last call that will (I hope) soon
follow.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 3 Dec 2008 09:24:52 -0800

Unfortunately, there was a major omission in draft #19. See my email of Nov
4 on the topic "[Ltru] rfc4646bis-18 "not suitable" prefix usage" responding
to Addison's proposed text. Since there was no objection raised to my
suggested text, I'd assumed that it was going to be used. I suspect this was
just an oversight, but the technical issues are real. Here is a repeat of my
message.

I didn't find a draft-19 version at
http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-19.html

There are a number of textual problems with the proposed text:

<t>Prefix's field-body contains a "extended language range" (basically, a
collection of subtags, see <xref target="RFC4647"></xref>) which SHOULD be
used with this subtag when forming language tag. The subtags in the prefix
MUST appear before the subtag in Prefix's record. The Prefix MUST NOT
include the wildcard '*'. This field MUST appear only in records whose
'Type' field-body is either 'extlang' or 'variant'. <vspace
blankLines="1"/>For example, the variant 'nedis' (Nadiza dialect) has a '
Prefix' of "sl" (Slovenian), meaning that tags such as "sl-nedis" and
"sl-IT-nedis" are appropriate, while the tag "is-nedis" (Icelandic, Nadiza
dialect) is not.</t>

Most of these were present before your latest suggestion:

   - The suggested text ("The subtags in the prefix MUST appear...") in the
   second line is not consistent with the SHOULD of the first line. That is, we
   can't say "The subtags in the prefixMUST appear before the subtag in
   Prefix's record." if it is only a SHOULD that the prefix be used with the
   subtag at all!
   - The wording is also awkward, since it suggests that the subtags are
   appearing in order in the Prefix's *record* instead of in a language tag.
   - Also, the gloss "basically a collection of subtags" is a bit funny,
   since it is not a collection: I'd expect something like {abc, def, ghi} if
   that were the case. Since they are linked with "-", they are actually
   ordered.
   - The use of extended language range, surprisingly, does *not* eliminate
   syntactically invalid Prefixes!
   - And now that we are excluding the *, and with the fact that it doesn't
   help with the syntax, just the use of "extended language range" is now
   useless.
   - The wording also requires that *each* prefix SHOULD be used, instead of
   *at least one of* the Prefixes!

My suggested revised text:

Prefix's field-body contains a sequence of subtags separated by '-'. This
field MUST appear only in records whose 'Type' field-body is either
'extlang' or 'variant', and one of the following concatenations MUST be a
well-formed language tag

   1. prefix_field_body + "-" + subtag_field_body, or
      2. "und-" + prefix_field_body + "-" + subtag_field_body

For example, the Prefix "Latn-de" for the variant '1994' MUST NOT be
registered, since neither "Latn-de-1994" nor  "und-Latn-de-1994" are
well-formed language tags. The prefix"Latn" could be registered for the
variant '1994', since "und-Latn-1994" is well-formed.

If a record contains any Prefix field, then any language tag containing the
record's subtag SHOULD also contain the subtag(s) from at least one
Prefix field.
Where a language tag contains the prefix's subtag(s) and the record's
subtag, those subtags SHOULD occur in that order in the language tag,
although perhaps with intervening subtags.

For example, the variant 'nedis' (Nadiza dialect) has a 'Prefix' of "sl"
(Slovenian), meaning that tags such as "sl-nedis" and "sl-IT-nedis" are
appropriate, while the tag "is-nedis" (Icelandic, Nadiza dialect) is
not appropriate and SHOULD NOT be used.

The variant '1994' has multiple prefix fields, where each prefix field has
multiple subtags: "sl-rozaj", "sl-rozaj-biske", "sl-rozaj-njiva",... A
language tag containing '1994' SHOULD have all the subtags from at least one
of these prefix fields, such as "sl-fonipa-rozaj-1994" or "sl-rozaj-biske-
fonipa-1994" (the 'fonipa' subtag is added to show the use of optional
intervening subtags). A language tag could contain subtags from multiple
prefix fields, such as "sl-rozaj-biske-njiva-1994", although that should be
avoided where the subtags are mutually exclusive.

Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 3 Dec 2008 10:05:31 -0800

Hi -

> From: "Mark Davis" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Addison Phillips" <[email-masked]>; "Martin Duerst"
<[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, December 03, 2008 9:24 AM
> Subject: Re: [Ltru] Hand-off to AD
>

As co-chair:

Arrrgghhh.  Ok, let's get this issue resolved *quickly*, then decide
whether a new draft is needed.

As a technical contributor...

...
>    Prefix's record." if it is only a SHOULD that the prefix be used with the

Agreed.

>    appearing in order in the Prefix's *record* instead of in a language tag.

Agreed.

>    that were the case. Since they are linked with "-", they are actually

Agreed.

>    syntactically invalid Prefixes!

Yup.

>    help with the syntax, just the use of "extended language range" is now

Agreed.

>    *at least one of* the Prefixes!

Ewww.

> 'extlang' or 'variant', and one of the following concatenations MUST be a

one = "at least one" or "exactly one"?

>       2. "und-" + prefix_field_body + "-" + subtag_field_body

So far, so good.

> variant '1994', since "und-Latn-1994" is well-formed.

I'd omit the example, since it doesn't seem particularly helpful, and
there's potentially no end to examples of what *NOT* to do.

> If a record contains any Prefix field, then any language tag containing the

would read better if the first "any" were an "a"

> not appropriate and SHOULD NOT be used.

I'd drop the negative example.  If we must keep it, I'd replace "not appropriate"
with "not meaningful".

> avoided where the subtags are mutually exclusive.

(Aside: these examples show why it really would have been much better to
have been able to treat IPA as a script!)

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 3 Dec 2008 10:28:34 -0800

Mark

> one = "at least one" or "exactly one"?

"at least one" is better, thanks.

> there's potentially no end to examples of what *NOT* to do.

I disagree. There is also potentially no end of examples of what TO do
either; that doesn't disqualify us from adding examples ;-)

More seriously, negative examples are quite useful for understanding,
especially when we are discussing a constraint.

> would read better if the first "any" were an "a"

either way is fine with me.

> I'd drop the negative example.  If we must keep it, I'd replace "not

I'd disagree. We use "appropriate" all over the place for this kind of case.
"Meaningful" is too open-ended.

> have been able to treat IPA as a script!)

(Also aside: Oh, yes! Unfortunately, the script folks are a bit too
ivory-tower for that. And unfortunately, we didn't anticipate that when we
did 4646, or we would have provided for syntax to allow registration of
script subtags, using one of the currently impossible tags (like 4
characters with at least one digit and at least one letter).)

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 3 Dec 2008 11:26:11 -0800

I generally agree with the observations here, but not with the proposed wording. I seriously disagree with allowing the ‘und’ interpolation (it breaks a lot of things). I have some comments on Mark’s message and text below my signature and, based on those, I therefore propose this revised text, which I think addresses the problems:

<t>Prefix's field-body contains a valid language tag whose subtags SHOULD be used when forming a language tag with this record's subtag. That is, a language tag that includes a subtag whose record includes one or more Prefix fields SHOULD match at least one of the Prefixes using the "Extended Filtering" algorithm (see <xref target="RFC4647"></xref>). Further, each of the subtags in the Prefix SHOULD appear before the subtag itself. This field MUST appear only in records whose 'Type' field-body is either 'extlang' or 'variant'.

<vspace blankLines="1"/>

For example, the variant '1994' (Standardized Resian orthography) has several 'Prefix' fields ("sl-rozaj", "sl-rozaj-biske", "sl-rozaj-njiva", "sl-rozaj-osojs", and "sl-rozaj-solba"). This indicates that tags such as "sl-rozaj-1994" or "sl-Latn-IT-rozaj-biske-1994" might be appropriate choices, while tags such as "sl-nedis-1994" or "is-1994" are not appropriate (and probably not meaningful).</t>

Note that making these changes also means editing Section 3.1.8. Here is the proposed revision:

--
<section anchor="prefixfield" title="Prefix Field">

<t>The field 'Prefix' contains a valid language tag, each of whose subtags SHOULD be used when forming a language tag with this subtag. All of the subtags in at least one of the subtag's Prefix fields SHOULD appear before the subtag itself. For example, the variant subtag '1996' has a 'Prefix' field of "de". This means that tags starting with the sequence "de-" are appropriate with this subtag, so "de-Latf-1996" and "de-CH-1996" are both acceptable, while the tag "fr-1996" is an inappropriate choice.</t>

<t>Fields of type 'Prefix' MUST NOT be removed from any record. The field-body for this type of field MAY be modified, but only if the modification broadens the meaning of the subtag. That is, the field-body can be replaced only by a prefix of itself. For example, the Prefix "be-Latn" (Belarusian, Latin script) could be replaced by the Prefix "be" (Belarusian) but not by the Prefix "ru-Latn" (Russian, Latin script).</t>

<t>Records of type 'variant' MAY have more than one field of type 'Prefix'. Additional
   fields of this type MAY be added to a 'variant' record via the registration process.
   Fields of type 'extlang' MUST have exactly one Prefix field.</t>

<t>The field-body of the 'Prefix' field MUST NOT conflict with any 'Prefix' already registered for a given record. Such a conflict would occur when no valid tag could be constructed that would contain the prefix, such as when two subtags each have a 'Prefix' that contains the other subtag. For example, suppose that the subtag 'avariant' has the prefix "es-bvariant". Then the subtag 'bvariant' cannot given the prefix 'avariant', for that would require a tag of the form "es-avariant-bvariant-avariant", which would not be valid.</t>

</section>
--

Comments?

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

Most of these were present before your latest suggestion:
·         The suggested text ("The subtags in the prefix MUST appear...") in the second line is not consistent with the SHOULD of the first line. That is, we can't say "The subtags in the prefixMUST appear before the subtag in Prefix's record." if it is only a SHOULD that the prefix be used with the subtag at all!
AP> Agreed.
·         The wording is also awkward, since it suggests that the subtags are appearing in order in the Prefix's *record* instead of in a language tag.
AP> Yep.
·         Also, the gloss "basically a collection of subtags" is a bit funny, since it is not a collection: I'd expect something like {abc, def, ghi} if that were the case. Since they are linked with "-", they are actually ordered.
AP> Hence the use of extended language range. But using the filtering algorithm and specifying a valid language tag is more appropriate.
·         The use of extended language range, surprisingly, does *not* eliminate syntactically invalid Prefixes!
AP> Agreed.
·         And now that we are excluding the *, and with the fact that it doesn't help with the syntax, just the use of "extended language range" is now useless.
AP> Not true: the use of extended filtering means that we have a matching algorithm and don’t have to recreate it here.
·         The wording also requires that *each* prefix SHOULD be used, instead of *at least one of* the Prefixes!
AP> corrected.

Prefix's field-body contains a sequence of subtags separated by '-'. This field MUST appear only in records whose 'Type' field-body is either 'extlang' or 'variant', and one of the following concatenations MUST be a well-formed language tag
1.      prefix_field_body + "-" + subtag_field_body, or
2.      "und-" + prefix_field_body + "-" + subtag_field_body
AP> But that isn’t necessary and the “und-“ thing I don’t understand at all.
For example, the Prefix "Latn-de" for the variant '1994' MUST NOT be registered, since neither "Latn-de-1994" nor  "und-Latn-de-1994" are well-formed language tags. The prefix"Latn" could be registered for the variant '1994', since "und-Latn-1994" is well-formed.

AP> Actually, “DE” still means “Germany”, so those would be well-formed tags! You can’t impute meaning to case…..

If a record contains any Prefix field, then any language tag containing the record's subtag SHOULD also contain the subtag(s) from at least one Prefix field. Where a language tag contains the prefix's subtag(s) and the record's subtag, those subtags SHOULD occur in that order in the language tag, although perhaps with intervening subtags.

AP> Not *just* “contain subtags”, but “contain ALL of the subtags” in the first sentence.

For example, the variant 'nedis' (Nadiza dialect) has a 'Prefix' of "sl" (Slovenian), meaning that tags such as "sl-nedis" and "sl-IT-nedis" are appropriate, while the tag "is-nedis" (Icelandic, Nadiza dialect) is not appropriate and SHOULD NOT be used.

The variant '1994' has multiple prefix fields, where each prefix field has multiple subtags: "sl-rozaj", "sl-rozaj-biske", "sl-rozaj-njiva",... A language tag containing '1994' SHOULD have all the subtags from at least one of these prefix fields, such as "sl-fonipa-rozaj-1994" or "sl-rozaj-biske-fonipa-1994" (the 'fonipa' subtag is added to show the use of optional intervening subtags). A language tag could contain subtags from multiple prefix fields, such as "sl-rozaj-biske-njiva-1994", although that should be avoided where the subtags are mutually exclusive.

AP> We have guidance elsewhere on this last bit: variants SHOULD NOT be used together unless one contains the other as a prefix. Thus 1994 can be used with any of the Resian subtags, but ‘biske’ and ‘njiva’ can’t be used together. I didn’t include this in my version because I think we bludgeon it to death elsewhere. ;-)

Mark

On Wed, Dec 3, 2008 at 08:33, Randy Presuhn <[email-masked]<mailto:[email-masked]>> wrote:
Hi -

As co-chair...

Randy

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

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 3 Dec 2008 12:37:41 -0800

comments below
Mark

On Wed, Dec 3, 2008 at 11:26, Phillips, Addison <[email-masked]> wrote:

>  I generally agree with the observations here, but not with the proposed
> wording. I seriously disagree with allowing the 'und' interpolation (it
> breaks a lot of things). I have some comments on Mark's message and text
> below my signature and, based on those, I therefore propose this revised
> text, which I think addresses the problems:
>
>
>
> <t>Prefix's field-body contains a valid language tag whose subtags SHOULD
> be used when forming a language tag with this record's subtag. That is, a
> language tag that includes a subtag whose record includes one or more Prefix
> fields SHOULD match at least one of the Prefixes using the "Extended
> Filtering" algorithm (see <xref target="RFC4647"></xref>). Further, each of
> the subtags in the Prefix SHOULD appear before the subtag itself. This field
> MUST appear only in records whose 'Type' field-body is either 'extlang' or
> 'variant'.
>

This doesn't work, since it requires that a prefix be a valid language tag.
That would require, for example, for a variant that required Latn, that we
list every possible combo of language-subtag + Latn in the prefix. That is
why I used the "und-" notation, because then it all falls out. We could have
used any other language subtag instead, or phrase it as:

"und-" + prefix_field_body + "-" + subtag_field_body
=>
some_language_subtag + "-" + prefix_field_body + "-" + subtag_field_body

Alternatively, however, if that seems too mathematical we could say:

Prefix's field-body contains a sequence of subtags separated by '-'. This
field MUST appear only in records whose 'Type' field-body is either
'extlang' or 'variant'. There MUST be some valid language tag that contains
the prefix subtags in order followed by the record's subtag, possibly with
additional subtags interspersed (excluding singletons).

 For example, the prefix "Latn" could be registered for the variant '1994',
since "de-Latn-1994" is an example of a valid subtag that contains both
"Latn" and "1994" in that order.

The Prefix "Latn-de" for the variant '1994' MUST NOT be registered, since
there is no valid language tag that contains "Latn".

Other comments below.

>
>
> <vspace blankLines="1"/>
>
>
>
> For example, the variant '1994' (Standardized Resian orthography) has
> several 'Prefix' fields ("sl-rozaj", "sl-rozaj-biske", "sl-rozaj-njiva",
> "sl-rozaj-osojs", and "sl-rozaj-solba"). This indicates that tags such as
> "sl-rozaj-1994" or "sl-Latn-IT-rozaj-biske-1994" might be appropriate
> choices, while tags such as "sl-nedis-1994" or "is-1994" are not appropriate
> (and probably not meaningful).</t>
>
>
>
> <t>The field 'Prefix' contains a valid language tag, each of whose
>
list of subtags separated by "-", each...

> subtags SHOULD be used when forming a language tag with this subtag. All of
> the subtags in at least one of the subtag's Prefix fields SHOULD appear
> before the subtag itself. For example, the variant subtag '1996' has a
> 'Prefix' field of "de". This means that tags starting with the sequence
> "de-" are appropriate with this subtag, so "de-Latf-1996" and "de-CH-1996"
> are both acceptable, while the tag "fr-1996" is an inappropriate choice.</t>
>
>
>
> <t>Fields of type 'Prefix' MUST NOT be removed from any record. The
> field-body for this type of field MAY be modified, but only if the
> modification broadens the meaning of the subtag. That is, the field-body can
> be replaced only by a prefix of itself.
>
That is, could be replaced by a subsetted list of subtags. (The modification
could also be to allow any prefix. Mechanically that would entail removing
all Prefix fields.)

> For example, the Prefix "be-Latn" (Belarusian, Latin script) could be
> replaced by the Prefix "be" (Belarusian) but not by the Prefix "ru-Latn"
> (Russian, Latin script).</t>
>
>
>
> <t>The field-body of the 'Prefix' field MUST NOT conflict with any 'Prefix'
> already registered for a given record. Such a conflict would occur when no
> valid tag could be constructed that would contain the prefix, such as when
> two subtags each have a 'Prefix' that contains the other subtag. For
> example, suppose that the subtag 'avariant' has the prefix "es-bvariant".
> Then the subtag 'bvariant' cannot given the prefix 'avariant', for that
> would require a tag of the form "es-avariant-bvariant-avariant", which would
> not be valid.</t>
>
>
>
> </section>
>
> --
>
>
>
> Comments?
>
>
>
> Addison
>
>
>
> Addison Phillips
>
> ·         The suggested text ("The subtags in the prefix MUST appear...")
> in the second line is not consistent with the SHOULD of the first line. That
> is, we can't say "The subtags in the prefixMUST appear before the subtag
> in Prefix's record." if it is only a SHOULD that the prefix be used with
> the subtag at all!
>
> AP> Agreed.
>
> ·         The wording is also awkward, since it suggests that the subtags
> are appearing in order in the Prefix's *record* instead of in a language
> tag.
>
> AP> Yep.
>
> ·         Also, the gloss "basically a collection of subtags" is a bit
> funny, since it is not a collection: I'd expect something like {abc, def,
> ghi} if that were the case. Since they are linked with "-", they are
> actually ordered.
>
> AP> Hence the use of extended language range. But using the filtering
> algorithm and specifying a valid language tag is more appropriate.
>
> ·         The use of extended language range, surprisingly, does *not*
> eliminate syntactically invalid Prefixes!
>
> AP> Agreed.
>
> ·         And now that we are excluding the *, and with the fact that it
> doesn't help with the syntax, just the use of "extended language range" is
> now useless.
>
> AP> Not true: the use of extended filtering means that we have a matching
> algorithm and don't have to recreate it here.
>
> ·         The wording also requires that *each* prefix SHOULD be used,
> instead of *at least one of* the Prefixes!
>
> AP> corrected.
>
>
>
> AP> But that isn't necessary and the "und-" thing I don't understand at
> all.
>
> AP> Actually, "DE" still means "Germany", so those would be well-formed
> tags! You can't impute meaning to case…..
>
>
> If a record contains any Prefix field, then any language tag containing
> the record's subtag SHOULD also contain the subtag(s) from at least one
> Prefix field. Where a language tag contains the prefix's subtag(s) and the
> record's subtag, those subtags SHOULD occur in that order in the language
> tag, although perhaps with intervening subtags.
>
>  AP> Not **just** "contain subtags", but "contain ALL of the subtags" in
> the first sentence.
>
>
>
> of these prefix fields, such as "sl-fonipa-rozaj-1994" or
> "sl-rozaj-biske-fonipa-1994" (the 'fonipa' subtag is added to show the use
> of optional intervening subtags). A language tag could contain subtags from
> multiple prefix fields, such as "sl-rozaj-biske-njiva-1994", although that
> should be avoided where the subtags are mutually exclusive.
>
>
>
> AP> We have guidance elsewhere on this last bit: variants SHOULD NOT be
> used together unless one contains the other as a prefix. Thus 1994 can be
> used with any of the Resian subtags, but 'biske' and 'njiva' can't be used
> together. I didn't include this in my version because I think we bludgeon it
> to death elsewhere. ;-)
>
>
>
>
>
> Mark
>
>
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 3 Dec 2008 12:42:40 -0800

Hi Mark,

We have *always* required full prefixes. If you want something to “fall out” or to allow specifying a prefix that doesn’t include a primary language subtag, we should really use an extended language range (because “*-Latn” matches what you want). But we’ve never allowed this sort of generic prefix--- and the text still doesn’t allow it (elsewhere).

Addison

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Wednesday, December 03, 2008 12:38 PM
To: Phillips, Addison
Cc: Randy Presuhn; Martin Duerst; [email-masked]
Subject: Re: [Ltru] Hand-off to AD

comments below

Mark

On Wed, Dec 3, 2008 at 11:26, Phillips, Addison <[email-masked]<mailto:[email-masked]>> wrote:

I generally agree with the observations here, but not with the proposed wording. I seriously disagree with allowing the 'und' interpolation (it breaks a lot of things). I have some comments on Mark's message and text below my signature and, based on those, I therefore propose this revised text, which I think addresses the problems:

This doesn't work, since it requires that a prefix be a valid language tag. That would require, for example, for a variant that required Latn, that we list every possible combo of language-subtag + Latn in the prefix. That is why I used the "und-" notation, because then it all falls out. We could have used any other language subtag instead, or phrase it as:

Prefix's field-body contains a sequence of subtags separated by '-'. This field MUST appear only in records whose 'Type' field-body is either 'extlang' or 'variant'. There MUST be some valid language tag that contains the prefix subtags in order followed by the record's subtag, possibly with additional subtags interspersed (excluding singletons).
For example, the prefix "Latn" could be registered for the variant '1994', since "de-Latn-1994" is an example of a valid subtag that contains both "Latn" and "1994" in that order.

The Prefix "Latn-de" for the variant '1994' MUST NOT be registered, since there is no valid language tag that contains "Latn".

Other comments below.

<vspace blankLines="1"/>

Note that making these changes also means editing Section 3.1.8.<http://3.1.8.> Here is the proposed revision:

--

subtags SHOULD be used when forming a language tag with this subtag. All of the subtags in at least one of the subtag's Prefix fields SHOULD appear before the subtag itself. For example, the variant subtag '1996' has a 'Prefix' field of "de". This means that tags starting with the sequence "de-" are appropriate with this subtag, so "de-Latf-1996" and "de-CH-1996" are both acceptable, while the tag "fr-1996" is an inappropriate choice.</t>

<t>Fields of type 'Prefix' MUST NOT be removed from any record. The field-body for this type of field MAY be modified, but only if the modification broadens the meaning of the subtag. That is, the field-body can be replaced only by a prefix of itself.
That is, could be replaced by a subsetted list of subtags. (The modification could also be to allow any prefix. Mechanically that would entail removing all Prefix fields.)

For example, the Prefix "be-Latn" (Belarusian, Latin script) could be replaced by the Prefix "be" (Belarusian) but not by the Prefix "ru-Latn" (Russian, Latin script).</t>

</section>

--

Comments?

Addison

Addison Phillips

It is an architecture.

•         The suggested text ("The subtags in the prefix MUST appear...") in the second line is not consistent with the SHOULD of the first line. That is, we can't say "The subtags in the prefixMUST appear before the subtag in Prefix's record." if it is only a SHOULD that the prefix be used with the subtag at all!

AP> Agreed.

•         The wording is also awkward, since it suggests that the subtags are appearing in order in the Prefix's *record* instead of in a language tag.

AP> Yep.

•         Also, the gloss "basically a collection of subtags" is a bit funny, since it is not a collection: I'd expect something like {abc, def, ghi} if that were the case. Since they are linked with "-", they are actually ordered.

•         The use of extended language range, surprisingly, does *not* eliminate syntactically invalid Prefixes!

AP> Agreed.

•         And now that we are excluding the *, and with the fact that it doesn't help with the syntax, just the use of "extended language range" is now useless.

AP> Not true: the use of extended filtering means that we have a matching algorithm and don't have to recreate it here.

•         The wording also requires that *each* prefix SHOULD be used, instead of *at least one of* the Prefixes!

AP> corrected.

AP> But that isn't necessary and the "und-" thing I don't understand at all.

AP> Actually, "DE" still means "Germany", so those would be well-formed tags! You can't impute meaning to case…..

AP> Not *just* "contain subtags", but "contain ALL of the subtags" in the first sentence.

AP> We have guidance elsewhere on this last bit: variants SHOULD NOT be used together unless one contains the other as a prefix. Thus 1994 can be used with any of the Resian subtags, but 'biske' and 'njiva' can't be used together. I didn't include this in my version because I think we bludgeon it to death elsewhere. ;-)

Mark

Hi -

As co-chair...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 3 Dec 2008 13:11:31 -0800

Hi -

> From: "Phillips, Addison" <[email-masked]>
> To: "Mark Davis" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "Martin Duerst" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, December 03, 2008 12:42 PM
> Subject: RE: [Ltru] Hand-off to AD
...
> We have *always* required full prefixes. If you want something to
> “fall out” or to allow specifying a prefix that doesn’t include
> a primary language subtag, we should really use an extended language
> range (because “*-Latn” matches what you want). But we’ve never
> allowed this sort of generic prefix--- and the text still doesn’t
> allow it (elsewhere).
...

I admit to being surprised by the idea of wanting to permit *-Latn
as a prefix.  That was one of the reasons why I questioned the
reference to "extended language range".  Whether we permit such things
will clearly have cause ripples, and we should be really really
sure that it's worth the cost / risk.  While I *can* imagine use cases,
they seem really contrived and leave me unconvinced that we should do
so, particularly at this late juncture.

As co-chair...

If we have indeed "required full prefixes" then the burden
of proof at this juncture is on those who would like something else.
Options:

   (1) provide evidence that we have not "required full prefixes" (optional)
   (2) provide technical arguments that permitting prefixes that don't
       go to the beginning of the tag would provide substantial benefits

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 3 Dec 2008 13:55:01 -0800

I disagree with the procedural point. The
prefix field used "extended language range" since July 31, 2007. See:
http://tools.ietf.org/html/draft-ietf-ltru-4646bis-07#section-3.1.7

So from July 31, 2007 (#17) up until December 2, 2008
(#19), it was possible to indicate that, say, a variant X should be used
with a script tag of 'Latn' or 'Grek' and not others (without having to
enumerate all the language subtags that could go with those scripts), or
that X should only be used with another variant Y, or that X should only be
used with the region 'CH'.

Randy suggested changing that in his note of Nov 2. To which Addison supplied
suggested text. I objected to that on Nov 4, and supplied suggested text
that would retain that ability (without using the extended language tag
syntax, which I agree that nobody particularly wants). Nobody further
objected to my recommendation.

So procedurally, I think it is a bit misleading to characterize this as
requiring the full burden of proof on my side, since #19 has a technical
change that disallowed a feature that was available for 1 1/2 years in the
draft, and a technical change that was made unexpectedly, at the very last
moment.

So before we'd go further, I'd like to see what harm it causes to allow:

Prefix: Latn

or

Prefix: US

etc.

That being said, if there are good reasons why this would be a bad idea, I
could certainly live with the #19 text, but I'd like to hear why it is a bad
idea (or that it required inordinate changes to the text), and not just
close it out on what I think are faulty procedural grounds.

Mark

On Wed, Dec 3, 2008 at 13:11, Randy Presuhn <[email-masked]>wrote:

> > "fall out" or to allow specifying a prefix that doesn't include
> > range (because "*-Latn" matches what you want). But we've never
> > allowed this sort of generic prefix--- and the text still doesn't
> > allow it (elsewhere).
> ...
>

---

From: John Cowan <[email-masked]>
Date: Wed, 3 Dec 2008 17:46:56 -0500

>    (1) provide evidence that we have not "required full prefixes" (optional)

I believe that Mark has answered this.

>        go to the beginning of the tag would provide substantial benefits

An obvious use case would be in creating variants that make sense with
one or more scripts independent of language.  For example, "euboean"
might be created as a variant subtag for Greek script, and that
independent of whether the variant was being used to represent
Greek or Etruscan.  Similarly, the variant subtag "petrine" might represent
the modern variety of Cyrillic (established by Peter the Great), which
is applicable to many languages.  These could also be handled by
script variants in ISO 15924, admittedly, but not all of them are
likely to get past the 15924/RA.

-- 
When I'm stuck in something boring              John Cowan
where reading would be impossible or            (who loves Asimov too)
rude, I often set up math problems for          [email-masked]
myself and solve them as a way to pass          http://www.ccil.org/~cowan
the time.      --John Jenkins
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Wed, 3 Dec 2008 16:22:28 -0800

The use cases aren't necessarily all that contrived: something like "*-Latn" is precisely the kind of prefix that would be appropriate for a variant subtag such as "fonipa" that represents writing-system variation as opposed to a linguistic variation. But I think this was discussed some months ago and that there was not a consensus to introduce that change at this point. (I think I supported it, but at this time I think shipping is a higher priority.)

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Wednesday, December 03, 2008 1:12 PM
To: [email-masked]
Subject: [Ltru] requiring full prefixes (Was: Re: Hand-off to AD)

Hi -

...
...

As co-chair...

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 3 Dec 2008 16:52:56 -0800

Well, *no* change would be the text in
http://tools.ietf.org/html/draft-ietf-ltru-4646bis-18#section-3.1.8

Is that what you are suggesting?

Mark

On Wed, Dec 3, 2008 at 16:22, Peter Constable <[email-masked]>wrote:

> The use cases aren't necessarily all that contrived: something like
> "*-Latn" is precisely the kind of prefix that would be appropriate for a
> variant subtag such as "fonipa" that represents writing-system variation as
> opposed to a linguistic variation. But I think this was discussed some
> months ago and that there was not a consensus to introduce that change at
> this point. (I think I supported it, but at this time I think shipping is a
> higher priority.)
>
>
> Peter
>
>
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 3 Dec 2008 17:17:17 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, December 03, 2008 1:55 PM
> Subject: Re: [Ltru] requiring full prefixes (Was: Re: Hand-off to AD)
>

As co-chair, I overrule the procedural objection.  I searched the archive,
and as far as I can determine, the introduction of "extended language range"
in http://www.ietf.org/mail-archive/web/ltru/current/msg07943.html included
no discussion of the implications of wildcarding.  The discussion appears
to be entirely of ensuring that subtags appear in the correct order, and that
the introduction of intervening subtags not be disallowed.  If there was
any discussion that might be interpreted as a WG consensus to support
non-initial prefixes, I missed it and would appreciate a pointer.

Since I have commented on this issue as a technical contributor, you may
appeal to co-chair Martin; I'd accept whatever his decision might be.

> close it out on what I think are faulty procedural grounds.
 
I'd just like to see closure one way or the other.  As far as I've been able to
determine, support for things like "Prefix: US" was an unintended consequence
of using "extended language range" to address the subtag ordering requirement.

Randy

---

From: Peter Constable <[email-masked]>
Date: Wed, 3 Dec 2008 20:31:28 -0800

I admit to not recalling or being on top of the details of this issue; I was merely speaking from what I recalled. I’d need to take some time to evaluate what I think should happen.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Wednesday, December 03, 2008 4:53 PM
To: Peter Constable
Cc: Randy Presuhn; [email-masked]
Subject: Re: [Ltru] requiring full prefixes (Was: Re: Hand-off to AD)

Mark

On Wed, Dec 3, 2008 at 16:22, Peter Constable <[email-masked]<mailto:[email-masked]>> wrote:
The use cases aren't necessarily all that contrived: something like "*-Latn" is precisely the kind of prefix that would be appropriate for a variant subtag such as "fonipa" that represents writing-system variation as opposed to a linguistic variation. But I think this was discussed some months ago and that there was not a consensus to introduce that change at this point. (I think I supported it, but at this time I think shipping is a higher priority.)

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Randy Presuhn
Sent: Wednesday, December 03, 2008 1:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ltru] requiring full prefixes (Was: Re: Hand-off to AD)

Hi -

> From: "Phillips, Addison" <[email-masked]<mailto:[email-masked]>>
> To: "Mark Davis" <[email-masked]<mailto:[email-masked]>>
> Cc: "Randy Presuhn" <[email-masked]<mailto:[email-masked]>>; "Martin Duerst" <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
...
...

As co-chair...

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 9 Dec 2008 12:05:56 -0800

The following response didn't go on-list because it replied to a message off-list (which I think might not have been intentional). However, since it means a change in draft-20, I'm posting it here.

Draft-20 has been updated as noted in my response.

Addison

Addison Phillips

> From: Phillips, Addison
> Sent: Tuesday, December 09, 2008 11:52 AM
> To: 'Randy Presuhn'; Mark Davis
> Cc: Martin Duerst
> Subject: RE: [Ltru] Prefix field (was: Hand-off to AD)
> 
> (editor hat ON)
> 
> I made the appearance sentence read:
> 
> --
> This field MAY appear in records whose 'Type' field-body is either
> 'extlang' or 'variant' (it MUST NOT appear in any other record
> type).
> --
> 
> (editor hat OFF)
> 
> I disagree with Mark's proposed edit. It isn't consistent with the
> other blocks around it. However, his point about the plurality of
> the field is well taken. I propose this edit:
> 
> <t>Prefix's field-body contains a valid language tag that is
> RECOMMENDED as one possible prefix to this record's subtag. This
> field MAY appear in records whose 'Type' field-body is either
> 'extlang' or 'variant' (it MUST NOT appear in any other record
> type).</t>
> 
> Elsewhere we deal with the specifics of the Prefix field. To
> resolve the editing I propose this edit of the first paragraph:
> 
> <t>The field 'Prefix' contains a valid language tag that is
> RECOMMENDED as one possible prefix to this record's subtag, perhaps
> with other subtags. That is, when including an extended language or
> a variant subtag that has at least one 'Prefix' in a language tag,
> the resulting tag SHOULD match at least one of the subtag's
> 'Prefix' fields using the "Extended Filtering" algorithm (see <xref
> target="RFC4647"></xref>) and each of the subtags in the 'Prefix'
> SHOULD appear before the subtag itself. </t>
> 
> Addison Phillips
> > From: Randy Presuhn [mailto:[email-masked]]
> > Sent: Tuesday, December 09, 2008 11:37 AM
> > To: Mark Davis; Phillips, Addison
> > Cc: Martin Duerst
> > > To: "Phillips, Addison" <[email-masked]>
> > > Cc: "Randy Presuhn" <[email-masked]>; "Martin
> > Duerst" <[email-masked]>
> > > Sent: Tuesday, December 09, 2008 11:04 AM
> > > This message is just about fixing the text for Prefix, making
> no
> > subtantive
> > > change. The text still isn't quite right. The wording implies
> > that every
> > > prefix's subtags are recommended, when it is actually just at
> > least one. And
> > > the last condition is slightly vague, with unclear referents.
> > Recommended
> > > wording below.
> > >
> > >
> > >
> > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-
> > 20.html#recordformat
> > >
> > > Prefix's field-body contains a valid language tag whose subtags
> > are
> > > RECOMMENDED for use together as a prefix for this record's
> subtag.
> > This
> > > 'extlang' or 'variant'.
> > > Prefix's field-body contains a valid language tag. If there are
> > any Prefix
> > > fields, then it is RECOMMENDED that any language tag containing
> > this
> > > record's subtag also contain all the subtags from at least one
> > Prefix field,
> > > in order. This field MUST appear only in records whose 'Type'
> > field-body is
> > > either 'extlang' or 'variant'.
> >
> > I don't think the proposed text is that much of an improvement,
> but
> > I don't object to it.  However, now that my attention is drawn to
> > it,
> > I *do* have a problem with both the original and the proposed
> text.
> > There is a scope / quantifier problem in the last sentence.  The
> > "MUST"
> > should be a "MAY", since the field is optional.  (If we looked
> > closely,
> > we'd probably find others of the form "x MUST y only in records
> of
> > type z"
> > where what is actually intended is "x MAY y in records of type z,
> > and
> > x MUST NOT y in records not of type z.)
> >
> > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-
> > 20.html#prefixfield
> > >
> > > The field 'Prefix' contains a valid language tag whose subtags
> > are
> > > RECOMMENDED for use together as a prefix for this record's
> subtag,
> > perhaps
> > > with other subtags. That is, when including a subtag in a
> > language tag, the
> > > tag SHOULD match at least one of its 'Prefix' fields using the
> > "Extended
> > > Filtering" algorithm (see [RFC4647] (Phillips, A. and M. Davis,
> > "Matching of
> > > Language Tags," September
> > > 2006.)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-
> > 20.html#RFC4647>)
> > > and each of the subtags in the 'Prefix' SHOULD appear before
> the
> > subtag
> > > itself.
> > >
> > > =>
> > >
> > > Prefix's field-body contains a valid language tag. If there are
> > any Prefix
> > > fields, then it is RECOMMENDED that any language tag containing
> > this
> > > record's subtag also contain all the subtags from at least one
> > Prefix field,
> > > in order.  That is, when including a subtag in a language tag,
> > the tag
> > > SHOULD match at least one of its 'Prefix' fields using the
> > "Extended
> > > Filtering" algorithm (see [RFC4647] (Phillips, A. and M. Davis,
> > "Matching of
> > > Language Tags," September
> > > 2006.)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-
> > 20.html#RFC4647>).
> > > Moreover, in the language tag each of the subtags in the
> matched
> > 'Prefix'
> > > SHOULD appear before this record's subtag.
> >
> > I don't think the proposed text is that much of an improvement,
> but
> > I don't object to it.  However, the final "this record's subtag"
> > made
> > me do a double take, because it sounded like it was describing a
> > constraint
> > on the formatting of the record, rather than the use of the
> subtag
> > described
> > by the record.
> >
> > Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 9 Dec 2008 12:07:41 -0800

(editor hat ON)

Static diff file is now up to date on my site also.

Addison Phillips