Subject: Re: [Ltru] Proposed edit MD12 (davis)

From: "Mark Davis" <[email-masked]>
Date: Mon, 17 Mar 2008 17:33:42 -0700

It appears that we didn't come to consensus yet on this item.

Mark

On Fri, Feb 22, 2008 at 9:50 AM, Mark Davis <[email-masked]>
wrote:

> On Fri, Feb 22, 2008 at 8:20 AM, Addison Phillips <[email-masked]>
> wrote:
>
> > I think there are two things here:
> >
> > 1. Are we willing to forego the "reconstruct as at date" feature?
>
>
> I think someone (John?) pointed out to me on the list that we don't
> currently guarantee that in the spec, and that it is currently not possible
> -- one cannot reliably reconstruct the complete status of the registry as of
> a given date from the information currently there. (And I don't know that
> anyone especially needs that feature, even if it is possible.)
>
>
> >
> >
> > 2. How should Preferred-Value be stabilized?
> >
> > For the latter, I think the question is whether we should allow
> > registration requests for Preferred-Value removal independent of outside
> > standard activity (i.e. for cases other than an action by one of the ISO
> > groups).
>
>
> What I think we want to do is mirror the language for Deprecated: "Usually,
> the addition of a 'Deprecated' field is due to the action of one of the
> standards bodies, such as ISO 3166, withdrawing a code."
>
> So we could say
>
> "Usually the addition, removal, or change in a Preferred-Value field for a
> subtag is to reflect changes in one of the source standard, such as ISO
> 3166. For example, if an ISO 3166 region code is deprecated in favor of
> another code, that SHOULD result in changes in the Preferred-Value field.
> The changes MAY affect other subtags as well.
>
>    - Suppose that subtag X has a Preferred-Value of Y. If Y changes to
>    have a Preferred-Value of Z, then the Preferred-Value for X MUST also change
>    to be Z.
>    - Suppose that a variant subtag 'foobar' represents a language not
>    yet available in ISO 639-3. The later addition of the corresponding language
>    code in ISO SHOULD result in the addition of a Preferred-Value for
>    'foobar'."
>
> Add also in 3.1.6:
>
> "Every subtag with a Preferred-Value field MUST also have a Deprecated
> field."
>
> ...
>
> "Usually the addition or removal of a Deprecated field is to reflect
> changes in one of the source standard, such as ISO 3166.  ..."
>
> ====
>
> We also need a fix for "These values form three groups:". This needs to be
> changed into: "Some examples of this are:"
>
> The reason for this change is that we clearly want to allow a registered
> language subtags (and variants) to be Deprecated and Preferred-Valued: if
> there is a registration for 'foobar' that later ends up having a new ISO 639
> code, we want to be able to deprecate it and point to the new value.
>
> So really any subtag has the potential of having Deprecated and
> Preferred-Value attached to it.
>
>
>
> > For the former, I don't know that anybody has implemented this
> > capability to date---I certainly have not.
>
>
> >
> > Addison
> >
> > Mark Davis wrote:
> > > If we can get consensus on that, I can help you track down the points
> > in
> > > the text that need changing.
> > >
> > > Mark
> > >
> > > On Thu, Feb 21, 2008 at 8:16 PM, Addison Phillips <
> > [email-masked]
> > > <mailto:[email-masked]>> wrote:
> > >
> > >     I have followed this thread down to here, which is apparently the
> > >     current end. With regard to inclusion of the Comment, I note that
> > it
> > >     would not just be a one-time event, but also potentially require
> > >     maintenance, which is a pain and might be overlooked.
> > >
> > >     I *also* note a couple reasons why we didn't allow a change to the
> > >     Preferred-Value but instead noted many times in RFC 4646 that you
> > have
> > >     to follow the chain. First, region codes in particular change with
> > some
> > >     regularity. The LSR would have to recognize that one change
> > affected
> > >     several subtags and update each one. Second, the transitive nature
> > >     allows one to reconstruct canonicality of a language tag as at a
> > >     particular date, a feature that is not possible if you remove the
> > chain.
> > >
> > >     However, I agree with Mark's Burma case. We should, in my opinion,
> > relax
> > >     the stability of Preferred-Value to allow removal or modification.
> > This
> > >     would allow modifications to remove transitive links (killing the
> > second
> > >     case above). It would also require some more modifications to
> > stability
> > >     rules and maintenance requirements.
> > >
> > >     Addison
> > >
> > >     Doug Ewell wrote:
> > >      > John Cowan <cowan at ccil dot org> wrote:
> > >      >
> > >      >>> It sounds like it's time to start a different thread.  The
> > change
> > >      >>> proposed in *this* thread was to recommend adding a comment
> > >     regarding
> > >      >>> the canonical form under certain circumstances. Do we or do
> > we not
> > >      >>> have agreement regarding *that* proposal?
> > >      >> I am opposed to the idea of adding such a comment, as I do not
> > >     believe
> > >      >> the contents of Comment fields should be part of the
> > algorithms
> > >     of BCP
> > >      >> 47.
> > >      >
> > >      > Actually, the proposed comment would not form part of the
> > algorithm.
> > >      > Rather, it would help remind implementers and tourists alike
> > that the
> > >      > correct algorithm is to follow the chain of Preferred-Values,
> > >     instead of
> > >      > stopping after the first one.
> > >      >
> > >      > That said, I too am concerned about specifying algorithmic
> > >     behavior in
> > >      > Comments fields.  Remember that the current Registry has a
> > group of
> > >      > rather inane Comments fields like this:
> > >      >
> > >      > Type: grandfathered
> > >      > Tag: i-navajo
> > >      > Description: Navajo
> > >      > Added: 1997-09-19
> > >      > Preferred-Value: nv
> > >      > Deprecated: 2000-02-18
> > >      > Comments: replaced by ISO code nv
> > >      >
> > >      > Some people who don't understand that the Comments field in
> > this case
> > >      > simply mirrors the Preferred-Value field might think the
> > Comments
> > >     field
> > >      > is normative.
> > >      >
> > >      > I would be leery about adding comments that people might
> > *think* form
> > >      > part of the algorithm, as John did, even if they don't really.
> > >      >
> > >      > In any case, any proposal in 4646bis that imposes a change on
> > the
> > >      > updated Registry in 4645bis should be considered technical, not
> > >      > editorial.
> > >      >
> > >      > --
> > >      > Doug Ewell  *  Fullerton, California, 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] <mailto:[email-masked]>
> > >      > http://www.ietf.org/mailman/listinfo/ltru
> > >
> > >
> > >     --
> > >     Addison Phillips
> > >     Globalization Architect -- Yahoo! Inc.
> > >     Chair -- W3C Internationalization Core WG
> > >
> > >     Internationalization is an architecture.
> > >     It is not a feature.
> > >     _______________________________________________
> > >     Ltru mailing list
> > >     [email-masked] <mailto:[email-masked]>
> > >     http://www.ietf.org/mailman/listinfo/ltru
> > >
> > >
> > >
> > >
> > > --
> > > Mark
> >
> >
> > --
> > Addison Phillips
> > Globalization Architect -- Yahoo! Inc.
> > Chair -- W3C Internationalization Core WG
> >
> > Internationalization is an architecture.
> > It is not a feature.
> >
>
>
>
> --
> Mark

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

---

From: John Cowan <[email-masked]>
Date: Mon, 17 Mar 2008 21:27:05 -0400

> It appears that we didn't come to consensus yet on this item.

Is anyone opposed to the proposal below?  I am for it.

-- 
John Cowan    http://ccil.org/~cowan    [email-masked]
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru