Randy Presuhn | 1 May 06:07
Picon

Re: It MUST and SHALL be preserved

Hi -

> From: "John Cowan" <cowan <at> ccil.org>
> To: <ltru <at> ietf.org>
> Sent: Thursday, April 30, 2009 2:11 PM
> Subject: [Ltru] It MUST and SHALL be preserved
>
> Just to keep things simple, let's change all SHALLs to MUSTs.

As co chair: Let's not.  The two have exactly the same effect from
and RFC 2119 point of view.  At this stage, we need to limit ourselves
to addressing the AD review comments, stuff we agreed earlier
to address (references), and show-stopper bugs that happen to
pop up.

Randy (who is known to be somewhat humor-impaired, in case this
was meant in jest.)

John Cowan | 1 May 07:23

Re: It MUST and SHALL be preserved

Randy Presuhn scripsit:

> Randy (who is known to be somewhat humor-impaired, in case this
> was meant in jest.)

Not in jest, but I suppose it *was* a bad idea at this stage.
Never mind.

--

-- 
John Cowan  cowan <at> ccil.org  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!"
Kent Karlsson | 1 May 16:02
Picon

Re: Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping


See below. This message includes proposed text towards the end of the
message.

Den 2009-04-30 22.53, skrev "Phillips, Addison" <addison <at> amazon.com>:

> Although I agree with your sentiments, I think we can avoid some additional
> working group bloodletting by being careful with our wording choices. I
> particularly note that RFC 2119 keywords, while have a normative weight to
> them, are not the only way to be ³normative² in a spec. Thus, I propose to
> take your suggestion:
>  
> --
> The default canonical form SHOULD normally be used for canonicalization. The
> extended canonical form may be useful
> in environments where the presence of the macrolanguage is beneficial in
> matching or selection.
> --
>  
> Š but modified to readŠ
>  
> --
> <t>Normally, the 'default' canonicalization is preferred. However, the
> 'extended' canonical form is useful
> in environments where the presence of the macrolanguage is beneficial in
> matching or selection (see <xref target="choiceUsingExtlang"></xref>).</t>
> --
>  
> In incorporating your proposed changes, I noticed that there was no need for
> double- or triple-list embedding. I also note that, since we are describing a
(Continue reading)

Kent Karlsson | 1 May 17:41
Picon

zh-Latn-CN-variant1-a-extend1-x-wadegile

Regarding the example

zh-Latn-CN-variant1-a-extend1-x-wadegile

that occurs in section 4.4.2, I find it less than ideal to use "x-wadegile", now that "wadegile" is a registered variant subtag. At least some comment regarding this would be in order, in case you don't want to change the example.

        /kent k
Phillips, Addison | 1 May 17:45
Picon
Favicon

Re: zh-Latn-CN-variant1-a-extend1-x-wadegile

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

zh-Latn-CN-variant1-a-extend1-x-wadegile

Last Call is over. Perhaps we can consider this as an errata for AUTH48 (he says, glancing to the co-chairs)

 

Addison

 

Addison Phillips

Globalization Architect -- Lab126

 

Internationalization is not a feature.

It is an architecture.

 

From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On Behalf Of Kent Karlsson
Sent: Friday, May 01, 2009 8:42 AM
To: LTRU Working Group
Subject: [Ltru] zh-Latn-CN-variant1-a-extend1-x-wadegile

 

Regarding the example

zh-Latn-CN-variant1-a-extend1-x-wadegile

that occurs in section 4.4.2, I find it less than ideal to use "x-wadegile", now that "wadegile" is a registered variant subtag. At least some comment regarding this would be in order, in case you don't want to change the example.

        /kent k

Randy Presuhn | 1 May 19:00
Picon

Re: zh-Latn-CN-variant1-a-extend1-x-wadegile

Hi -

As a technical contributor...

There is no prohibition on the stuff following the "x-" from
looking like something that has been registered, so I don't
see anything wrong with the example.  I'd even consider it
a feature.

As co-chair...

AUTH48 would *NOT* be an appropriate time to consider such a change.

We can do it now, if we think this is a technical problem that
will cause deployment or interoperability problems, or a serious
editorial problem that would lead to the specification being
misunderstood.  *If* others think this is important, I'll
enter it into the tracker and we can discuss it.

Randy

> From: "Phillips, Addison" <addison <at> amazon.com>
> To: "Kent Karlsson" <kent.karlsson14 <at> comhem.se>; "LTRU Working Group" <ltru <at> ietf.org>
> Sent: Friday, May 01, 2009 8:45 AM
> Subject: Re: [Ltru] zh-Latn-CN-variant1-a-extend1-x-wadegile
>
> Last Call is over. Perhaps we can consider this as an errata for AUTH48 (he says, glancing to the co-chairs)
>
> Addison
>
> Addison Phillips
> Globalization Architect -- Lab126
>
> Internationalization is not a feature.
> It is an architecture.
>
> From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On Behalf Of Kent Karlsson
> Sent: Friday, May 01, 2009 8:42 AM
> To: LTRU Working Group
> Subject: [Ltru] zh-Latn-CN-variant1-a-extend1-x-wadegile
>
> Regarding the example
>
> zh-Latn-CN-variant1-a-extend1-x-wadegile
>
> that occurs in section 4.4.2, I find it less than ideal to use "x-wadegile", now that "wadegile" is a
registered variant subtag.
At least some comment regarding this would be in order, in case you don't want to change the example.
>
>         /kent k
>

--------------------------------------------------------------------------------

> _______________________________________________
> Ltru mailing list
> Ltru <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>

Kent Karlsson | 1 May 22:05
Picon

Re: zh-Latn-CN-variant1-a-extend1-x-wadegile


I would just propose to at a short note, along the lines of:

    "Note that 'wadegile' is now a registered variant subtag, and that
    should be used for designating the Wade-Giles romanisation rather
    than a private-use subtag."

Just to avoid having the example being read as a current recommendation of
some kind, w.r.t. Wade-Giles romanisation tagging.

I will not push for this if others think it is bad idea to edit that in now.

    /kent k

Den 2009-05-01 19.00, skrev "Randy Presuhn" <randy_presuhn <at> mindspring.com>:

> Hi -
> 
> As a technical contributor...
> 
> There is no prohibition on the stuff following the "x-" from
> looking like something that has been registered, so I don't
> see anything wrong with the example.  I'd even consider it
> a feature.
> 
> As co-chair...
> 
> AUTH48 would *NOT* be an appropriate time to consider such a change.
> 
> We can do it now, if we think this is a technical problem that
> will cause deployment or interoperability problems, or a serious
> editorial problem that would lead to the specification being
> misunderstood.  *If* others think this is important, I'll
> enter it into the tracker and we can discuss it.
> 
> Randy
> 
>> From: "Phillips, Addison" <addison <at> amazon.com>
>> To: "Kent Karlsson" <kent.karlsson14 <at> comhem.se>; "LTRU Working Group"
>> <ltru <at> ietf.org>
>> Sent: Friday, May 01, 2009 8:45 AM
>> Subject: Re: [Ltru] zh-Latn-CN-variant1-a-extend1-x-wadegile
>> 
>> Last Call is over. Perhaps we can consider this as an errata for AUTH48 (he
>> says, glancing to the co-chairs)
>> 
>> Addison
>> 
>> Addison Phillips
>> Globalization Architect -- Lab126
>> 
>> Internationalization is not a feature.
>> It is an architecture.
>> 
>> From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On Behalf Of Kent
>> Karlsson
>> Sent: Friday, May 01, 2009 8:42 AM
>> To: LTRU Working Group
>> Subject: [Ltru] zh-Latn-CN-variant1-a-extend1-x-wadegile
>> 
>> Regarding the example
>> 
>> zh-Latn-CN-variant1-a-extend1-x-wadegile
>> 
>> that occurs in section 4.4.2, I find it less than ideal to use "x-wadegile",
>> now that "wadegile" is a registered variant subtag.
> At least some comment regarding this would be in order, in case you don't want
> to change the example.
>> 
>>         /kent k
>> 
> 
> 
> ------------------------------------------------------------------------------
> --
> 
> 
>> _______________________________________________
>> Ltru mailing list
>> Ltru <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ltru
>> 
> 
> 
> _______________________________________________
> Ltru mailing list
> Ltru <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ltru

CE Whitehead | 1 May 22:31
Picon

Re: Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping

Hi!

From: "Phillips, Addison" <addison at amazon.com>
 
Date: Thu, 30 Apr 2009 09:13:11 -0700
>(as individual contributor) >> > 3. In the 'default' canonical form, subtags of type 'extlang' >> MUST >> > 4. In the 'extended' canonical form, primary language subtags >> with a >> I propose the names "short" and "long" respectively. > 'extended' seems like a more natural name for the latter form.* Yes >I acknowledge that the name 'default' is prejudicial, in its way, but it was the previous intent of 'SHOULD' and it is the canonical form that the registry is optimized for. > If we don't want to say that it's the default, we could pick a name that is partial antonym for 'extended', such as 'compact', 'regular', or (hmm...) 'short'. 'abbreviated'? 'brief'? But I have no problem with 'default'. Also, I like Mark's text; it's clear: 
4.5.  Canonicalization of Language Tags

  Since a particular language tag is sometimes used by many processes,
  language tags SHOULD always be created or generated in a canonical
  form.

  There are two canonical forms for language tags.  The 'default'
  canonical form maps each 'extlang' subtag to its Preferred-Value.
  The 'extended' canonical form includes the macrolanguage primary
  language subtag before eligible (extended) language subtags."
 
And I think I understand Addison's amendment (I'm just not up on the changes to the values that occur during processing--the length is changed?) & agree there needs to be an amendment:
 
""These mappings MUST be done before additional processing, since there can be additional changes to subtag values."
  Best,--C. E. Whiteheadcewcathar <at> hotmail.com> How about 'short' and 'extended'? >If we don't say 'default' (or even if we do), oughtn't we to have some text explaining when to use which? >Addison
CE Whitehead | 2 May 16:28
Picon

Re: Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping

Hi!
 
I. 
I still think Mark’s text reads more clearly than other possible introductory text and that it is the text to start with in the introduction to canonicalization . . . I can't do anything with:
"A language tag is in canonical form, either default canonical form or
extlang canonical form, when the tag is well-formed according to the
rules in <xref target="syntax"/> and <xref target="sources"/> and
canonicalising it does not change it"
Mark's text clearly introduces the two types of canonicalization, which you all seem to think you need to do.
)

 
Mark’s suggested introductory text:
 
"4.5.  Canonicalization of Language Tags
  Since a particular language tag is sometimes used by many processes,
  language tags SHOULD always be created or generated in a canonical
  form.
  There are two canonical forms for language tags.  The 'default'
  canonical form maps each 'extlang' subtag to its Preferred-Value.
  The 'extended' canonical form includes the macrolanguage primary
  language subtag before eligible (extended) language subtags."
 
 
However, Kent points out that,
"Mapping just the subtag will not do anything here (if we just consider the
strings, ignoring the primary language vs. extlang classification). One
needs to map the language tag prefix, up to and including the extlang subtag
in question, to the preferred value."
 
So then, do we replace:
"each 'extlang' subtag"
with
"each subtag in the primary language-extension language combination" ???
 
Also, I want to clarify the implication of Kent’s suggested change to the steps in canonicalization going to affect the use of the term "macrolanguage" in the above?(Kent's worried about sign language subtags that are extension language subtags but don't have a macrolanguage):
"5. For the extlang canonical form (but not for the default canonical form),   a primary language subtag that is also registered as an 'extlang' subtag   is replaced by the corresponding language-extlang combination, where the
   primary language subtag here is the Prefix registered for the extlang."
 
Does the above mean that we need to say here:
"The ‘extlang’ canonical form includes the registered prefix for the extension language before eligible (extlang) language subtags"
???
(I noted that Kent did not like "extended canonical form" and acted accordingly.)
 
These changes would result in:
 
  "Since a particular language tag is sometimes used by many processes,
  language tags SHOULD always be created or generated in a canonical
  form.
  There are two canonical forms for language tags.  The 'default'
  canonical form maps each each subtag in the primary language-extension language combination to its Preferred-Value.
  The 'extended' canonical form includes the registered prefix for the extension language before eligible (extlang) language subtags."
 
II.
 
I also find the following text useful:
<t>Normally, the 'default' canonicalization is preferred. However, the 'extlang' canonical form  is useful
 
in environments where the presence of the macrolanguage is beneficial in matching or selection (see <xref target="choiceUsingExtlang"></xref>).</t>
 
III.
 
My goof on Addison’s text (below)—as Kent pointed out, Addison means that: “mapping a subtag to its preferred value should occur before any additional steps in canonicalization”
 
>"These mappings MUST be done before additional processing, since there can be additional changes to subtag values." 
>form(s)."
 
But then would not Kent's suggested step 2  (below) become step 1? but otherwise everything follows mapping:
 
>Canonicalisation of a well-formed [or well-defined, see comment above]
>language tag is defined by doing the following steps, in order, using data
>from the current IANA language subtag registry (<xref
>target="ianaformat"/>).
 
>1. Extension sequences in the tag are ordered into case-insensitive ASCII
>   order by the singleton subtags. (At the time of publication of this
>   document, there were no extension subtags registered.)
 
>2. A redundant or grandfathered tag that has a Preferred-Value field in
>   the IANA registry is replaced with its preferred value.
 
> 3. A non-extlang subtag that has a Preferred-Value field in the IANA
>   registry is replaced with its preferred value.
 
> 4. A tag prefix of the form language-extlang is replaced by the
>   preferred value registered for the extlang.
 
> 5. For the extlang canonical form (but not for the default canonical form),
>   a primary language subtag that is also registered as an 'extlang' subtag
>   is replaced by the corresponding language-extlang combination, where the
>   primary language subtag here is the Prefix registered for the extlang.

(NOTE: Hope my suggestions make some sense.  Sorry if I'm not keeping up with the discussion on this (the postings online aren't quite up-to-date???)

--C. E. Whitehead
cewcathar <at> hotmail.com
Kent Karlsson | 2 May 17:24
Picon

Re: Ticket #45: AD Issue #12: reason for SHOULD in 4.5 extlang mapping


Den 2009-05-02 16.28, skrev "CE Whitehead" <cewcathar <at> hotmail.com>:

Hi!
 
I.  
I still think Mark’s text reads more clearly than other possible introductory text and that it is the text to start with in the introduction to canonicalization . . . I can't do anything with:
"A language tag is in canonical form, either default canonical form or
extlang canonical form, when the tag is well-formed according to the
rules in <xref target="syntax"/> and <xref target="sources"/> and
canonicalising it does not change it"
Mark's text clearly introduces the two types of canonicalization, which you all seem to think you need to do.
)

Part of my suggestion was to *first* have the definition, then say something about recommended use.

Mark’s suggested introductory text:
 
"4.5.  Canonicalization of Language Tags
  Since a particular language tag is sometimes used by many processes,
  language tags SHOULD always be created or generated in a canonical
  form.
  There are two canonical forms for language tags.  The 'default'
  canonical form maps each 'extlang' subtag to its Preferred-Value.
  The 'extended' canonical form includes the macrolanguage primary
  language subtag before eligible (extended) language subtags."
 
 
However, Kent points out that,
"Mapping just the subtag will not do anything here (if we just consider the
strings, ignoring the primary language vs. extlang classification). One
needs to map the language tag prefix, up to and including the extlang subtag
in question, to the preferred value."
 
So then, do we replace:
"each 'extlang' subtag"
with
"each subtag in the primary language-extension language combination" ???
 
Also, I want to clarify the implication of Kent’s suggested change to the steps in canonicalization going to affect the use of the term "macrolanguage" in the above?(Kent's worried about sign language subtags that are extension language subtags but don't have a macrolanguage):
"5. For the extlang canonical form (but not for the default canonical form),   a primary language subtag that is also registered as an 'extlang' subtag   is replaced by the corresponding language-extlang combination, where the
   primary language subtag here is the Prefix registered for the extlang."
 
Does the above mean that we need to say here:
"The ‘extlang’ canonical form includes the registered prefix for the extension language before eligible (extlang) language subtags"
???

I think having step 5 saying that is sufficient, no need to duplicate that statement.

(I noted that Kent did not like "extended canonical form" and acted accordingly.)
 
These changes would result in:
 
  "Since a particular language tag is sometimes used by many processes,
  language tags SHOULD always be created or generated in a canonical
  form.
  There are two canonical forms for language tags.  The 'default'
  canonical form maps each each subtag in the primary language-extension language combination to its Preferred-Value.
  The 'extended' canonical form includes the registered prefix for the extension language before eligible (extlang) language subtags."
 
II.
 
I also find the following text useful:
<t>Normally, the 'default' canonicalization is preferred. However, the 'extlang' canonical form  is useful
 
in environments where the presence of the macrolanguage is beneficial in matching or selection (see <xref target="choiceUsingExtlang"></xref>).</t>

Saying "macrolanguage" here is not exactly correct.  Otherwise text like that can go after the definition of the normal forms.

III.
 
My goof on Addison’s text (below)—as Kent pointed out, Addison means that: “mapping a subtag to its preferred value should occur before any additional steps in canonicalization”
 
>"These mappings MUST be done before additional processing, since there can be additional changes to subtag values."
>form(s)."
 
But then would not Kent's suggested step 2  (below) become step 1? but otherwise everything follows mapping:

The ordering does not matter for all steps. But I suggest having one order that is correct (of course), makes some kind of logical grouping, and have the optional part last. And then say "in order" without making a great fuss using "MUST". Also: have the steps as clean as possible, moving all examples, explanations, text on usage, to after the definition of the canonical forms rather than bog down the steps in the (algorithmic) definition with such text.

    /kent k


>Canonicalisation of a well-formed [or well-defined, see comment above]
>language tag is defined by doing the following steps, in order, using data
>from the current IANA language subtag registry (<xref
>target="ianaformat"/>).
 
>1. Extension sequences in the tag are ordered into case-insensitive ASCII
>   order by the singleton subtags. (At the time of publication of this
>   document, there were no extension subtags registered.)
 
>2. A redundant or grandfathered tag that has a Preferred-Value field in
>   the IANA registry is replaced with its preferred value.
 
> 3. A non-extlang subtag that has a Preferred-Value field in the IANA
>   registry is replaced with its preferred value.
 
> 4. A tag prefix of the form language-extlang is replaced by the
>   preferred value registered for the extlang.
 
> 5. For the extlang canonical form (but not for the default canonical form),
>   a primary language subtag that is also registered as an 'extlang' subtag
>   is replaced by the corresponding language-extlang combination, where the
>   primary language subtag here is the Prefix registered for the extlang.

(NOTE: Hope my suggestions make some sense.  Sorry if I'm not keeping up with the discussion on this (the postings online aren't quite up-to-date???)

--C. E. Whitehead
cewcathar <at> hotmail.com

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru

Gmane