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

Mark

On Sun, Jul 20, 2008 at 8:31 PM, Doug Ewell <doug at ewellic.org> wrote:

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.

good

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

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. 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).
=>
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).

> 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. 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. Preferred-Value Field.

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. 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.

--
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
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.