Subject: Re: [Ltru] Preferred-Value for YU?

From: "Debbie Garside" <[email-masked]>
Date: Mon, 2 Feb 2009 10:05:55 -0000

Hi Doug

I am not sure that I like the thought of deleting historical information.  I
do see where you are coming from but, nevertheless, are we going to be
missing a link in the chain by deleting "CS" from "YU"?

I hate deleting information from databases! :-)

What I would like to see is information added to the PV field for "YU" (
such as ":2006-10-05") to indicate when "CS" became invalid as the PV.
However, I am, assuming that this would entail an update to 4646bis and is,
therefore, unlikely to be incorporated at this time.

I would ask that you be careful to not inadvertently delete some of the dots
that join the Registry.  However, I cannot, on this fine, cold, soon to be
snowy, Monday morning, think of a valid reason why other than on principle -
I'll try another coffee and maybe write again. :-)

+1 to adding John's comment though.

Best

Debbie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug
Ewell
Sent: 31 January 2009 21:20
To: LTRU Working Group
Subject: Re: [Ltru] Preferred-Value for YU?

John Cowan <cowan at ccil dot org> wrote:

> +1 for removing CS.

Two assenting voices on a Saturday afternoon and no dissenting voices is 
enough to make this minor change to the draft.  There will presumably be 
lots of time for dissenters to make themselves heard.

> I'd propose adding a comment something like "See BA, HR, ME, MK, RS, 
> or SI."

I can do this.  I suppose the precedent of having to provide informative 
mappings every time ISO 3166 countries split or merge has already been 
set by the CS and GB comments.  I imagine when as the Netherlands 
Antilles continue to get their own 3166 codes, the Registry will be 
expected to provide this sort of mapping back to AN, and we may need to 
retrofit comments onto BL and MF as well.

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

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.10.16/1926 - Release Date: 30/01/2009
17:31

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.10.16/1929 - Release Date: 01/02/2009
18:02

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

---

From: Mark Davis <[email-masked]>
Date: Mon, 2 Feb 2009 07:53:50 -0800

I agree about the comment. (Ideally we'd do the same for the other cases
like that.)

Mark

On Sat, Jan 31, 2009 at 12:31, John Cowan <[email-masked]> wrote:

> Doug Ewell scripsit:
>
> > In draft-4645bis, should we modify the record for subtag YU by removing
> > the P-V of CS, since CS is itself deprecated with no P-V?
>
> +1 for removing CS.
>
> I'd propose adding a comment something like "See BA, HR, ME, MK, RS, or
> SI."
>
> --
> John Cowan    [email-masked]    http://ccil.org/~cowan<http://ccil.org/%7Ecowan>
> This great college [Trinity], of this ancient university [Cambridge],
> has seen some strange sights. It has seen Wordsworth drunk and Porson
> sober. And here am I, a better poet than Porson, and a better scholar
> than Wordsworth, somewhere betwixt and between.  --A.E. Housman

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 2 Feb 2009 12:42:31 -0800

Hi -

As co-chair -
I'd strongly prefer that "adjustments" to specific entries be handled
on [email-masked] rather than in the ltru WG.  My reasoning:
  (1) It's time to finish gilding this lily.
  (2) The division of labor between the two groups gives questions of
      form and process to ltru, and of content to ietf-languages.

The ONLY reason for "tweaking" an entry *here* that I could support on
this list at this time is that our processes would not permit the change
to be made via [email-masked].

Randy

> From: "Mark Davis" <[email-masked]>
> To: "John Cowan" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>; "Doug Ewell" <[email-masked]>
> Sent: Monday, February 02, 2009 7:53 AM

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

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 2 Feb 2009 12:57:37 -0800

(as a contributor)

Sadly, while I agree with Randy, a brief review suggests a problem.

First, I agree that, since 'YU' is already in the registry, there is no reason why LTRU even *should* consider changing 4645bis. There is an extant registration process and it covers addition of comments, preferred-values, and such. However, 4646 clearly states that YU->CS cannot be changed at present. Section 3.1 says:

--
The field 'Preferred-Value' MUST NOT be modified once created in the registry.
--

I notice, however, that there may be a consistency problem in Section 3.1.7 of 4646bis-21, though. Specifically, it allows (MAY) a Preferred-Value to "migrate forward". But then uses perhaps-inappropriate normative language in the example covering regions:

--
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 Section 3.5 (Registration Procedure for Subtags), although anyone MAY request such changes. For example:

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

LTRU made this change to avoid "chaining" of preferred-values in the future. But it looks inconsistent as written. Probably the first "MAY" should be changed to read "Changes to one subtag sometimes affects other subtags as well".

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Monday, February 02, 2009 12:43 PM
> To: LTRU Working Group
> > > John Cowan    [email-masked]
> http://ccil.org/~cowan<http://ccil.org/%7Ecowan>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 3 Feb 2009 19:15:54 -0800

Hi -

> From: "Phillips, Addison" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Monday, February 02, 2009 12:57 PM
> Subject: RE: [Ltru] Preferred-Value for YU?
...
> 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 Section 3.5 (Registration Procedure for
Subtags), although anyone MAY request such changes. For example:
>
> 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'.
> --
>
> LTRU made this change to avoid "chaining" of preferred-values in the future. But it looks inconsistent as written. Probably the
first "MAY" should be changed to read "Changes to one subtag sometimes affects other subtags as well".
...

As a technical contributor, I think the current language,
while not ideal, is tolerable.  One can read that first
"MAY" with its strict RFC 2119 sense without anything
"breaking."  Consequently, I'd prefer to leave the text
as-is.

If there is a consensus for change, I could live with
the proposed change only if it is modified to fix its
verb-subject agreement problem, though I think it might
be better stated as "Changes to the Preferred-Value of
a subtag  may have consequences for other subtags."

Randy

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 3 Feb 2009 22:12:47 -0700

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> I am not sure that I like the thought of deleting historical 
> information.  I do see where you are coming from but, nevertheless, 
> are we going to be missing a link in the chain by deleting "CS" from 
> "YU"?
>

If this were the sort of information that the Registry was designed to 
hold, then I would completely agree.  But I'm not convinced that it is. 
We've already agreed that users of the Registry should not have to jump 
from one Preferred-Value to another before arriving at the "correct" 
value.

One question to ask might be: If the user sees that "YU" is deprecated 
but has a Preferred-Value of "CS", then looks up "CS" and sees that it 
too is deprecated, but with no Preferred-Value, what good did it do to 
redirect the user in the first place?

> What I would like to see is information added to the PV field for "YU" 
> (such as ":2006-10-05") to indicate when "CS" became invalid as the 
> PV.  However, I am, assuming that this would entail an update to 
> 4646bis and is, therefore, unlikely to be incorporated at this time.

Good guess.  :-)