Subject: [Ltru] Changes to draft-4645bis resulting from new draft-4646bis

From: "Doug Ewell" <[email-masked]>
Date: Sun, 20 Jul 2008 21:31:25 -0600

I've combed through draft-4646bis-17 looking for changes that would 
affect draft-4645bis.

As a reminder, draft-4645bis-05 was submitted to the RFC Editor on May 8 
(referencing draft-4646bis-13), and I have an editor's copy of 
draft-4645bis-06 dated June 21 on my Web site that references 
draft-4646bis-15.  (Sorry about the number soup here; I couldn't think 
of a better way to explain this without using a table.) 
Draft-4645bis-06 will be edited to reflect the changes described here 
before being submitted.

The changes I've found are as follows:

1.  For each Description field that occurs in two or more non-deprecated 
subtags of the same type, we need to change at least one to eliminate 
the duplication.  I will send proposed changes to both the 
ietf-languages and LTRU lists, and will take any feedback into account 
when revising the draft.

2.  For each record containing Description fields that differ only in 
stylistic usage of apostrophes, hyphens, and so forth (such as Ge'ez and 
Geʻez), we need to pick one and discard the rest.  I will send the 
relevant records to both mailing lists, ask for a rough consensus as to 
the preferred rendering, and ask the Reviewer to make the final 
decision, taking any list feedback into account.

Issues that we still haven't resolved include:

3.  whether to change the list of languages that have extlangs 
(currently ar, kok, ms, sgn, sw, uz, zh), and if we do change it, what 
explanation to provide for the choice in draft-4645bis

4.  whether extlangs can have Suppress-Script (question asked by Addison 
with special attention to the Arabic extlangs)

I would hope that we can resolve these remaining questions with at least 
as much analytical effort and energy as we devoted to the largely 
theoretical question of arranging multiple prefixless variants within a 
tag.

--
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: "Mark Davis" <[email-masked]>
Date: Mon, 21 Jul 2008 10:24:50 -0700

Mark

On Sun, Jul 20, 2008 at 8:31 PM, Doug Ewell <[email-masked]> wrote:

> I've combed through draft-4646bis-17 looking for changes that would affect
> draft-4645bis.
>
> draft-4646bis-15.  (Sorry about the number soup here; I couldn't think of a
> better way to explain this without using a table.) Draft-4645bis-06 will be
> edited to reflect the changes described here before being submitted.
>
> subtags of the same type, we need to change at least one to eliminate the
> duplication.  I will send proposed changes to both the ietf-languages and
> LTRU lists, and will take any feedback into account when revising the draft.
>
> Geʻez), we need to pick one and discard the rest.  I will send the relevant
> records to both mailing lists, ask for a rough consensus as to the preferred
> rendering, and ask the Reviewer to make the final decision, taking any list
> feedback into account.

good

> 3.  whether to change the list of languages that have extlangs (currently
> ar, kok, ms, sgn, sw, uz, zh), and if we do change it, what explanation to
> provide for the choice in draft-4645bis

Unless someone makes a good argument for changing them, I suggest we just go
forward with these. I think we have enough text in 4.1.2 already.

There are a few other items that seem to not be in
http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html yet, I think
because we may not have had specific language. I think we were in agreement
that we need to drop the Deprecated from the Extlang cases, and tie the
Preferred Value closer to canonicalization.

Here are my suggestions:

> Extended language subtag records MUST include a 'Preferred-Value' and
'Deprecated' field. The 'Preferred-Value' and 'Subtag' fields MUST be
identical.
=>
Extended language subtag records MUST include a 'Preferred-Value' field. The
'Preferred-Value' and 'Subtag' fields MUST be identical.

> Although valid in language tags, subtags and tags with a 'Deprecated'
field are deprecated and validating processors SHOULD NOT generate these
subtags.
ADD: However, for backwards compatibility the deprecated code may be
preferred in many contexts: see
3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>
Preferred-Value Field.

> The value in this field is strongly RECOMMENDED as the best choice to
represent the value of this record when selecting a language tag.
=>
The value in this field is used for canonicalization, and shows that the
tags SHOULD be treated as equivalent on input. If the subtag or tag is also
Deprecated, then the Preferred Value is RECOMMENDED. However, for backwards
compatibility the deprecated code may be preferred in many contexts. For
example, both "iw" and "he" can be used in the Java programming language,
but "he" is converted on input to "iw", which is thus the canonical form in
Java.

"Records that contain a 'Preferred-Value' field MUST also have a
'Deprecated' field. This field contains the date on which the tag or subtag
was deprecated in favor of the preferred value."
REMOVE

"The 'Preferred-Value' field in subtag records of type "extlang" also
contains an "extended language range". This allows the subtag to be
deprecated in favor of either a single primary language subtag or a new
language-extlang sequence."
=>
The 'Preferred-Value' field in subtag records of type "extlang" also
contains an "extended language range". This allows either a single primary
language subtag or a new language-extlang sequence to be preferred.

> Extended language subtag records MUST include the fields 'Prefix',
'Deprecated', and 'Preferred-Value' with field-values assigned as described
in Section 2.2.2 (Extended Language
Subtags)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#extlang>
.
=>
Extended language subtag records MUST include the fields 'Prefix' and
'Preferred-Value' with field-values assigned as described in Section
2.2.2 (Extended
Language Subtags)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#extlang>
.

> For example, use 'he' for Hebrew in preference to 'iw'.
ADD: However, for backwards compatibility the deprecated code may be
preferred in many contexts: see
3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>
Preferred-Value Field.

> However, tags that include these values SHOULD NOT be selected by users or
generated by implementations.
=> Tags that include these values SHOULD NOT be selected by users or
generated by implementations.
However, for backwards compatibility the deprecated code may be preferred in
many contexts: see
3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>
Preferred-Value Field.

> with special attention to the Arabic extlangs)

We are treating the two forms as equivalent. So I think we can just add the
following:

[in 3.1.9.  Suppress-Script Field]
ADD AT END
Tags formed using extlangs are equivalent to those with the extlang subtag
as the primary language subtag; thus the Suppress-Script field for the
primary language subtag applies to tags using the corresponding extlang. For
example, if 'abh' has Suppress-Script: Arab, then Arb should be suppressed
from both ar-abh-AF and abh-AF.

>
> I would hope that we can resolve these remaining questions with at least as
> much analytical effort and energy as we devoted to the largely theoretical
> question of arranging multiple prefixless variants within a tag.

agreed, glad you refocused this.

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 21 Jul 2008 14:01:15 -0700

Comments follow.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

3.  whether to change the list of languages that have extlangs (currently ar, kok, ms, sgn, sw, uz, zh), and if we do change it, what explanation to provide for the choice in draft-4645bis

Unless someone makes a good argument for changing them, I suggest we just go forward with these. I think we have enough text in 4.1.2 already.

+1

There are a few other items that seem to not be in http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html yet, I think because we may not have had specific language. I think we were in agreement that we need to drop the Deprecated from the Extlang cases, and tie the Preferred Value closer to canonicalization.

Here are my suggestions:

> Extended language subtag records MUST include a 'Preferred-Value' and 'Deprecated' field. The 'Preferred-Value' and 'Subtag' fields MUST be identical.
=>
Extended language subtag records MUST include a 'Preferred-Value' field. The 'Preferred-Value' and 'Subtag' fields MUST be identical.

(editor hat) DONE.

> Although valid in language tags, subtags and tags with a 'Deprecated' field are deprecated and validating processors SHOULD NOT generate these subtags.
ADD: However, for backwards compatibility the deprecated code may be preferred in many contexts: see 3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>  Preferred-Value Field.

(editor hat OFF). I don’t think this quite jibes with removing ‘Deprecated’. If we remove deprecated from extlang records, we don’t have to say anything else here. What we do have to say is something about preferred values later.

> The value in this field is strongly RECOMMENDED as the best choice to represent the value of this record when selecting a language tag.
=>
The value in this field is used for canonicalization, and shows that the tags SHOULD be treated as equivalent on input. If the subtag or tag is also Deprecated, then the Preferred Value is RECOMMENDED. However, for backwards compatibility the deprecated code may be preferred in many contexts. For example, both "iw" and "he" can be used in the Java programming language, but "he" is converted on input to "iw", which is thus the canonical form in Java.

(editor hat OFF) The iw/he example is orthogonal to the extlang problem we’re addressing here. I’m not sure it makes sense to thrust this example in at this juncture.

(editor hat) This text also seemed a little awkward to me and a rewrite was in order. I didn’t ignore your suggestions, but had to reorganize to achieve the right result (such as adding a case to the former “three cases” list. Here is the resulting text:

--
<section anchor="preferredfield" title="Preferred-Value Field">

<t>The field 'Preferred-Value' contains a mapping between the record in which it appears and another tag or subtag (depending on the record's 'Type'). The value in this field is used for canonicalization (see <xref target="canonical"></xref>). In cases where the subtag or tag also has a 'Deprecated' field, then the 'Preferred-Value' is RECOMMENDED as the best choice to represent the value of this record when selecting a language tag. </t>

<t>Records containing a Preferred-Value fall into one of these four groups:

<list style="numbers">

   <t>ISO 639 language codes that were later withdrawn in favor of other codes. These values are mostly a historical curiosity. The 'he'/'iw' pairing above is an example of this.</t>

   <t>Subtags (with types other than language or extlang) taken from codes or values that have been withdrawn in favor of a new code. In particular, this applies to region subtags taken from ISO 3166-1, because sometimes a country will change its name or administration in such a way that warrants a new region code. In some cases, countries have reverted to an older name, which might already be encoded. For example, the subtag 'ZR' (Zaire) was replaced by the subtag 'CD' (Democratic Republic of the Congo) when that country's name was changed.</t>

   <t>Tags or subtags that have become obsolete because the values they represent were later encoded. Many of the grandfathered or redundant tags were later encoded by ISO 639, for example, and fall into this grouping. For example, "i-klingon" was deprecated when the subtag 'tlh' was added. The record for "i-klingon" has a 'Preferred-Value' of 'tlh'.</t>

   <t>Extended language subtags always have a mapping to their identical primary language subtag. For example, the extended language subtag 'yue' (Cantonese) can be used to form the tag "zh-yue". It has a Preferred-Value mapping to the primary language subtag 'yue', meaning that a tag such as "zh-yue-Hant-HK" can be canonicalized to "yue-Hant-HK".</t>

</list>
</t>

<t>Records other than those of type 'extlang' that contain a 'Preferred-Value' field MUST also have a 'Deprecated' field. This field contains the date on which the tag or subtag was deprecated in favor of the preferred value.</t><t>For records of type 'extlang', the 'Preferred-Value' field appears without a corresponding 'Deprecated' field. An implementation MAY ignore these preferred value mappings, although if it ignores the mapping, it SHOULD do so consistently. It SHOULD also treat the Preferred-Value as equivalent to the mapped item. For example, the tags "zh-yue-Hant-HK" and "yue-Hant-HK" are semantically equivalent and ought to be treated as if they were the same tag.</t>

<t>Occasionally the deprecated code is preferred in certain contexts. For example, both "iw" and "he" can be used in the Java programming language, but "he" is converted on input to "iw", which is thus the canonical form in Java. </t>

<t>'Preferred-Value' mappings in records of type 'region' sometimes do not represent exactly the same meaning as the original value. There are many reasons for a country code to be changed, and the effect this has on the formation of language tags will depend on the nature of the change in question. For example, the region subtag 'YD' (Democratic Yemen) was deprecated in favor of the subtag 'YE' (Yemen) when those two countries unified in 1990.</t>

<t>A 'Preferred-Value' MAY be added to, changed, or removed from records according to the rules in <xref target="maintreg"/>. Addition, modification, or removal of a 'Preferred-Value' field in a record does not imply that content using the affected subtag needs to be retagged.</t>

<t>The 'Preferred-Value' fields in records of type "grandfathered" and "redundant" each contain an "extended language range" (<xref target="RFC4647"></xref>) that is strongly RECOMMENDED for use in place of the record's value. In many cases, these mappings were created via deprecation of the tags during the period before <xref target="RFC4646"/> was adopted. For example, the tag "no-nyn" was deprecated in favor of the ISO 639-1-defined language code 'nn'. </t><t>The 'Preferred-Value' field in subtag records of type "extlang" also contains an "extended language range". This allows the subtag to be deprecated in favor of either a single primary language subtag or a new language-extlang sequence.</t>

<t>Usually the addition, removal, or change of a Preferred-Value field for a
subtag is done to reflect changes in one of the source standards. For example, if an ISO 3166-1 region code is deprecated in favor of
another code, that SHOULD result in the addition of a Preferred-Value field.
</t>

<t>Changes to one subtag MAY affect other subtags as well: when proposing changes to the registry, the Language Subtag Reviewer will review the registry for such effects and propose the necessary changes using the process in <xref target="registrationProc"></xref>, although anyone MAY request such changes. For example:

<list>

   <t>Suppose that subtag 'XX' has a Preferred-Value of 'YY'. If 'YY' later changes to
have a Preferred-Value of 'ZZ', then the Preferred-Value for 'XX' MUST also change
to be 'ZZ'.</t>

   <t>Suppose that a registered language subtag 'dialect' represents a language not
yet available in any part of ISO 639. The later addition of a corresponding language
code in ISO 639 SHOULD result in the addition of a Preferred-Value for
'dialect'.</t>

</list>
</t>
</section>
--

"Records that contain a 'Preferred-Value' field MUST also have a 'Deprecated' field. This field contains the date on which the tag or subtag was deprecated in favor of the preferred value."
REMOVE

"The 'Preferred-Value' field in subtag records of type "extlang" also contains an "extended language range". This allows the subtag to be deprecated in favor of either a single primary language subtag or a new language-extlang sequence."
=>
The 'Preferred-Value' field in subtag records of type "extlang" also contains an "extended language range". This allows either a single primary language subtag or a new language-extlang sequence to be preferred.

> Extended language subtag records MUST include the fields 'Prefix', 'Deprecated', and 'Preferred-Value' with field-values assigned as described in Section 2.2.2 (Extended Language Subtags)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#extlang>.
=>
Extended language subtag records MUST include the fields 'Prefix' and 'Preferred-Value' with field-values assigned as described in Section 2.2.2 (Extended Language Subtags)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#extlang>.

(editor hat) DONE.

> For example, use 'he' for Hebrew in preference to 'iw'.
ADD: However, for backwards compatibility the deprecated code may be preferred in many contexts: see 3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>  Preferred-Value Field.

(editor hat OFF) Do we really need to litter the document for this one case?

(editor hat) Changed the ‘he’/’iw’ example here to ‘jbo’/”art-lojban”.

> However, tags that include these values SHOULD NOT be selected by users or generated by implementations.
=> Tags that include these values SHOULD NOT be selected by users or generated by implementations.
However, for backwards compatibility the deprecated code may be preferred in many contexts: see 3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>  Preferred-Value Field.

(editor hat OFF) This doesn’t belong here? The context of this sentence is subtags that are deprecated with no P-V. The item says “SHOULD NOT” on purpose and I don’t think we need to belabor it in this instance.

4.  whether extlangs can have Suppress-Script (question asked by Addison with special attention to the Arabic extlangs)

We are treating the two forms as equivalent. So I think we can just add the following:

[in 3.1.9.<http://3.1.9.>  Suppress-Script Field]
ADD AT END
Tags formed using extlangs are equivalent to those with the extlang subtag as the primary language subtag; thus the Suppress-Script field for the primary language subtag applies to tags using the corresponding extlang. For example, if 'abh' has Suppress-Script: Arab, then Arb should be suppressed from both ar-abh-AF and abh-AF.

(editor hat OFF) Wouldn’t we just include the S-S field in the records of type extlang?

(editor hat) I did the necessary edits to do it that way.

I would hope that we can resolve these remaining questions with at least as much analytical effort and energy as we devoted to the largely theoretical question of arranging multiple prefixless variants within a tag.

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

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 21 Jul 2008 14:33:33 -0700

Mark

On Mon, Jul 21, 2008 at 2:01 PM, Phillips, Addison <[email-masked]>
wrote:

> Unless someone makes a good argument for changing them, I suggest we just
> go forward with these. I think we have enough text in 4.1.2 already.
>
>
>
> +1
>
>
> Extended language subtag records MUST include a 'Preferred-Value' field.
> The 'Preferred-Value' and 'Subtag' fields MUST be identical.
>
>
>
> (editor hat) DONE.
>
>
>
> preferred in many contexts: see 3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>
> Preferred-Value Field.
>
>
>
> (editor hat OFF). I don't think this quite jibes with removing
> 'Deprecated'. If we remove deprecated from extlang records, we don't have to
> say anything else here. What we do have to say is something about preferred
> values later.
>
ok

> (editor hat OFF) The iw/he example is orthogonal to the extlang problem
> we're addressing here. I'm not sure it makes sense to thrust this example in
> at this juncture.
>
>
>
> (editor hat) This text also seemed a little awkward to me and a rewrite was
> in order. I didn't ignore your suggestions, but had to reorganize to achieve
> the right result (such as adding a case to the former "three cases" list.
> Here is the resulting text:
>
>
>
> --
>
> <t>The field 'Preferred-Value' contains a mapping between the record in
> which it appears and another tag or subtag (depending on the record's
> 'Type'). The value in this field is used for canonicalization (see <xref
> target="canonical"></xref>). In cases where the subtag or tag also has a
> 'Deprecated' field, then the 'Preferred-Value' is RECOMMENDED as the best
> choice to represent the value of this record when selecting a language tag.
> </t>
>
>
>
>    <t>ISO 639 language codes that were later withdrawn in favor of other
> codes. These values are mostly a historical curiosity. The 'he'/'iw' pairing
> above is an example of this.</t>
>
>
>
>
>    <t>Subtags (with types other than language or extlang) taken from codes
> or values that have been withdrawn in favor of a new code. In particular,
> this applies to region subtags taken from ISO 3166-1, because sometimes a
> country will change its name or administration in such a way that warrants a
> new region code. In some cases, countries have reverted to an older name,
> which might already be encoded. For example, the subtag 'ZR' (Zaire) was
> replaced by the subtag 'CD' (Democratic Republic of the Congo) when that
> country's name was changed.</t>
>
>
>
>
>    <t>Tags or subtags that have become obsolete because the values they
> represent were later encoded. Many of the grandfathered or redundant tags
> were later encoded by ISO 639, for example, and fall into this grouping. For
> example, "i-klingon" was deprecated when the subtag 'tlh' was added. The
> record for "i-klingon" has a 'Preferred-Value' of 'tlh'.</t>
>
>
>
>    <t>Extended language subtags always have a mapping to their identical
> primary language subtag. For example, the extended language subtag 'yue'
> (Cantonese) can be used to form the tag "zh-yue". It has a Preferred-Value
> mapping to the primary language subtag 'yue', meaning that a tag such as
> "zh-yue-Hant-HK" can be canonicalized to "yue-Hant-HK".</t>
>
>
>
>
> </list>
>
> </t>
>
>
>
> <t>Records other than those of type 'extlang' that contain a
> 'Preferred-Value' field MUST also have a 'Deprecated' field. This field
> contains the date on which the tag or subtag was deprecated in favor of the
> preferred value.</t><t>For records of type 'extlang', the 'Preferred-Value'
> field appears without a corresponding 'Deprecated' field. An implementation
> MAY ignore these preferred value mappings, although if it ignores the
> mapping, it SHOULD do so consistently. It SHOULD also treat the
> Preferred-Value as equivalent to the mapped item. For example, the tags
> "zh-yue-Hant-HK" and "yue-Hant-HK" are semantically equivalent and ought to
> be treated as if they were the same tag.</t>
>

all good (we could make the first MUST be a SHOULD, but I'm ok with your
text).

>
>
> <t>Occasionally the deprecated code is preferred in certain contexts. For
> Java. </t>
> <t>'Preferred-Value' mappings in records of type 'region' sometimes do not
> represent exactly the same meaning as the original value. There are many
> reasons for a country code to be changed, and the effect this has on the
> formation of language tags will depend on the nature of the change in
> question. For example, the region subtag 'YD' (Democratic Yemen) was
> deprecated in favor of the subtag 'YE' (Yemen) when those two countries
> unified in 1990.</t>
>
>
>
> <t>A 'Preferred-Value' MAY be added to, changed, or removed from records
> according to the rules in <xref target="maintreg"/>. Addition, modification,
> or removal of a 'Preferred-Value' field in a record does not imply that
> content using the affected subtag needs to be retagged.</t>
>
>
>
>
>
> <t>The 'Preferred-Value' fields in records of type "grandfathered" and
> "redundant" each contain an "extended language range" (<xref
> target="RFC4647"></xref>) that is strongly RECOMMENDED for use in place of
> the record's value. In many cases, these mappings were created via
> deprecation of the tags during the period before <xref target="RFC4646"/>
> was adopted. For example, the tag "no-nyn" was deprecated in favor of the
> ISO 639-1-defined language code 'nn'. </t><t>The 'Preferred-Value' field in
> subtag records of type "extlang" also contains an "extended language range".
> This allows the subtag to be deprecated in favor of either a single primary
> language subtag or a new language-extlang sequence.</t>
>
>
>
> subtag is done to reflect changes in one of the source standards. For
> example, if an ISO 3166-1 region code is deprecated in favor of
>
> <t>Changes to one subtag MAY affect other subtags as well: when proposing
> changes to the registry, the Language Subtag Reviewer will review the
> registry for such effects and propose the necessary changes using the
> process in <xref target="registrationProc"></xref>, although anyone MAY
> request such changes. For example:
>
>
>
> <list>
>
>
>
>
good

> in Section 2.2.2 (Extended Language Subtags)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#extlang>
> .
> =>
> 'Preferred-Value' with field-values assigned as described in Section 2.2.2
> (Extended Language Subtags)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#extlang>
> .
>
>
>
> (editor hat) DONE.
>
>
>
> preferred in many contexts: see 3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>
> Preferred-Value Field.
>
>
>
No, I guess as long as we have it in one place. (We do tend to repeat the
same MUSTs and SHOULDs with these things in different places....)

>
>
> (editor hat) Changed the 'he'/'iw' example here to 'jbo'/"art-lojban".
>
ok

> However, for backwards compatibility the deprecated code may be preferred
> in many contexts: see 3.1.7.<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html#preferredfield>
> Preferred-Value Field.
>
>
>
> (editor hat OFF) This doesn't belong here? The context of this sentence is
> subtags that are deprecated with no P-V. The item says "SHOULD NOT" on
> purpose and I don't think we need to belabor it in this instance.
>

ok, good

> (editor hat OFF) Wouldn't we just include the S-S field in the records of
> type extlang?
>

Because they there is always the chance that we screw up the
synchronization.  If we include the S-S by reference that can't happen. If
we include the SS field in extlang fields, then we also have to add the rule
for the Language Reviewer that anything that every extlang MUST have an SS
if and only if the corresponding primary language subtag does.

> ______________________________ _________________
> Ltru mailing list
> [email-masked]

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 21 Jul 2008 14:45:59 -0700

all good (we could make the first MUST be a SHOULD, but I'm ok with your text).

AP> We could do that, but it would be a change in the rules. That is, we don’t now allow a value to have a preferred value unless we mean to deprecate it. Other than the extlang case (which I regard as handwaving), are there any cases in which we would have a P-V without also deprecating the non-preferred value?

(editor hat OFF) Wouldn't we just include the S-S field in the records of type extlang?

Because they there is always the chance that we screw up the synchronization.  If we include the S-S by reference that can't happen. If we include the SS field in extlang fields, then we also have to add the rule for the Language Reviewer that anything that every extlang MUST have an SS if and only if the corresponding primary language subtag does.

AP> And, just to make trouble, can an extlang have a different S-S from its Macrolanguage?? And can an extlang have an S-S and its macrolanguage not have one. For example, could ‘gan’ have an S-S of Hans even though zh does not (and should not)? Maybe we should go the other direction and inherit from Macrolanguage.

Addison

Addison Phillips

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 21 Jul 2008 14:55:24 -0700

Mark

On Mon, Jul 21, 2008 at 2:45 PM, Phillips, Addison <[email-masked]>
wrote:

> AP> We could do that, but it would be a change in the rules. That is, we
> don't now allow a value to have a preferred value unless we mean to
> deprecate it. Other than the extlang case (which I regard as handwaving),
> are there any cases in which we would have a P-V without also deprecating
> the non-preferred value?
>

I'm ok with your text (my reservations are minor; and I don't want to make
an issue of them).

> AP> And, just to make trouble, can an extlang have a different S-S from its
> Macrolanguage??
>

There is nothing fundamental about the relationship that requires the same
scripts. 'sr' and 'hr' share the same macrolanguage, but don't have the same
default script.

> And can an extlang have an S-S and its macrolanguage not have one.
>

Clearly yes.

> For example, could 'gan' have an S-S of Hans even though zh does not (and
> should not)?
>

Yes.

> Maybe we should go the other direction and inherit from Macrolanguage.
>

No. We should impose all and only those conditions that are required. And
the required condition is that "zh-yue" and "yue", being equivalent, need to
have the same SS. If we make the SS of the corresponding primary language
subtag apply to the entlang, then we don't have the possibility of
mismatches in the repository. But I send you possible language if you (and
others) really want it in there.

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 21 Jul 2008 22:32:19 -0600

Mark Davis wrote:

> http://inter-locale.com/ID/draft-ietf-ltru-4646bis-17.html yet, I 
> think because we may not have had specific language. I think we were 
> in agreement that we need to drop the Deprecated from the Extlang 
> cases, and tie the Preferred Value closer to canonicalization.

OK, another item for 4645bis.

> ... However, for backwards compatibility the deprecated code may be 
> preferred in many contexts. For example, both "iw" and "he" can be 
> used in the Java programming language, but "he" is converted on input 
> to "iw", which is thus the canonical form in Java.

I'm not wild about calling a lot of attention to cases like this.  The 
message it sends is that after reading this 88-page document full of 
MUSTard, you're free to define your own canonicalization rules however 
you please.

Java was first released in 1995, the same year that RFC 1766 appeared 
and brought additional attention to the use of ISO 639 language codes on 
the Internet.  Most people who used language tags referred to informal 
ISO 639 code lists, which were often badly out of date and may have 
included the code element 'iw' which had been withdrawn from ISO 639 in 
1989.  Certainly nobody would have used the term "canonical form" in 
relation to language tags back then.  Java is not an exemplary case of 
how to make RFC 4646bis fit your needs.

> preferred in many contexts: see 3.1.7.  Preferred-Value Field.

I seriously question "many."

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 21 Jul 2008 22:37:47 -0600

Mark Davis wrote:

> synchronization.  If we include the S-S by reference that can't 
> happen. If we include the SS field in extlang fields, then we also 
> have to add the rule for the Language Reviewer that anything that 
> every extlang MUST have an SS if and only if the corresponding primary 
> language subtag does.

A primary-extlang combination should take its Suppress-Script, if any, 
from the primary language subtag.

Problem: If you have some flavor of Arabic, denoted by an extlang, that 
isn't written overwhelmingly in the Arabic script, how do you interpret 
the absence of a script subtag?  (I personally don't think this is a 
huge real-world problem, but it's the sort of thing we in LTRU love to 
dwell on.)

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 21 Jul 2008 22:40:55 -0600

Mark Davis wrote:

> No. We should impose all and only those conditions that are required. 
> And the required condition is that "zh-yue" and "yue", being 
> equivalent, need to have the same SS. If we make the SS of the 
> corresponding primary language subtag apply to the entlang, then we 
> don't have the possibility of mismatches in the repository. But I send 
> you possible language if you (and others) really want it in there.

I think we should be very grateful at this point that 'zh' does not have 
a Suppress-Script.

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 21 Jul 2008 21:51:29 -0700

Hi -

As a technical contributor....

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Monday, July 21, 2008 9:37 PM
> Subject: Re: [Ltru] Changes to draft-4645bis resulting from new draft-4646bis
>
> Mark Davis wrote:
> 

For precisely this reason, the Supress-Script (if any) associated with
a particular subtag should not be presumed to indicate what the
Supress-Script would be for something else, even in the case of a
primary-extlang combination, even if they are overwhelmingly likely
to have the same value.  I don't think it is reasonable to *require*
every extlang to have the same suppress-script as the corresponding
primary language tag.  (Particularly if we remember that the original
intention of Supress-Script was compatibility with existing data that
lacked script subtags, and would not be an issue for newly regstered
languages since, by definition, there would be no legacy data.)

Putting in a rule to require them to "propagate" or to be the same
would be a false economy, in my opinion.

Randy

---

From: John Cowan <[email-masked]>
Date: Tue, 22 Jul 2008 01:04:49 -0400

Randy Presuhn scripsit:

> primary language tag.  

-1

Having a Suppress-Script or not, and what particular value it has, is
a property of a language, not a way of describing that language.  It is
not reasonable for xx-yyy to have a different S-S value from yyy, since
xx-yyy and yyy are synonymous, any more than it would be reasonable for
he and iw to have different S-S values.  It *is* reasonable for xx-yyy
and xx to have different S-S values.

> (Particularly if we remember that the original intention of
> Supress-Script was compatibility with existing data that lacked script
> subtags, and would not be an issue for newly regstered languages since,
> by definition, there would be no legacy data.)

That's true.  Unfortunately, several xx-yyy forms are legacy.

> would be a false economy, in my opinion.

How a false economy?  It would be an economy (true or false) not to
provide S-S headers for both the extlang and the corresponding language
tag.  It would be inconsistent to allow them to have different values.
IMHO it is less confusing to provide the header in both places.

-- 
John Cowan  [email-masked]  http://ccil.org/~cowan
Female celebrity stalker, on a hot morning in Cairo:
"Imagine, Colonel Lawrence, ninety-two already!"
El Auruns's reply:  "Many happy returns of the day!"
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Kent Karlsson" <[email-masked]>
Date: Tue, 22 Jul 2008 14:00:58 +0200

Doug Ewell wrote:
> A primary-extlang combination should take its Suppress-Script,
> if any, from the primary language subtag.

For zzz-xxx and xxx to be as equivalent as possible
(and I think that is a goal), zzz-xxx must not only
take the supress-script from the xxx subtag (as a
language subtag, it seems unnecessary to duplicate
this information in the record for xxx as extlang).
It must even be so that the the supress-script from
xxx, ***including its absence*** MUST ***override***
the supress-script from zzz in the zzz-xxx combiniation.
So in zzz-xxx the supress-script from the record for
zzz is NEVER relevant.

		/kent k

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 22 Jul 2008 08:28:04 -0700

The question is whether xx and yyy can have separate S-S values. I think it is *possible* that this could happen, it just isn't apparent that we have the problem at present. For example, someone pointed out to me that some forms of Arabic use(d) Latin script---it is just that these forms are now extinct.

I don't think that xx-yyy and yyy can have different S-S values for the reason John points out: a language either is or is not written in "just one" script. Other combinations seem plausible though:

    Xx    yyy
SS  a     a
SS  a     b
SS  -     a
SS  a     -
SS  -     -

Where (a) and (b) are different scripts and (-) represents no SS present. The most unlikely cases are the second and fourth ones (xx has a script and yyy does not or has a separate script).  In these cases, a language could be "overwhelmingly written" in a script while a fairly small, usually unremarked, encompassed language is the exception.

Addison

Addison Phillips

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Cowan
> Sent: Monday, July 21, 2008 10:05 PM
> To: Randy Presuhn
> Cc: LTRU Working Group

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 22 Jul 2008 08:51:02 -0700

I agree... except to note that Suppress-Script is not a normative field. It is an informative field. Lack of a Suppress-Script does not imply that a script subtag is needed or necessary. It may only imply that specific information is not available for that language.

If one knows that the majority of Arabic-language documents are written in the Arabic script and knows nothing about Sudanese Creole Arabic (pqa), one still might not wish to include the 'Arab' subtag in a tag "ar-pqa-SD".

Addison

Addison Phillips

> Behalf Of Kent Karlsson
> Sent: Tuesday, July 22, 2008 5:01 AM
> To: 'LTRU Working Group'