Subject: Re: [Ltru] rfc4646bis-18 "SHALL NOT be rejected"

From: "Doug Ewell" <[email-masked]>
Date: Mon, 3 Nov 2008 07:26:50 -0700

"Phillips, Addison" <addison at amazon dot com> wrote:

> ZR/CD and TL/TP are not necessarily Bad Changes. And BU/MY is not 
> necessarily a bad oscillation. The people involved certainly have 
> feelings about what their country should be called and, while this has 
> nothing to do with linguistic reality, it is not necessarily "wrong". 
> Yes, purely political and/or administrative changes are a real 
> problem. But getting the "right" choice is wrapped up in external 
> considerations that we probably don't want to tangle with.

I disagree, though I agree with Co-Chair Randy's decision not to make 
any changes at this point, but rather to prepare ourselves to defend 
this decision at IETF LC.

ZR/CD happened in 1997 and was out of our control.  There was already 
the possibility of RFC 1766/3066 language tags in both -ZR and -CD, so 
there was no difference in "churn" whether we chose ZR or CD as the 
canonical subtag.  TL/TP happened in 2002, a year before we started this 
effort, so the situation is similar.

Changing the canonical form of MM (not MY, Malaysia) to BU would be 
different, because BU has been out of commission since 1989, before Date 
A (publication of RFC 1766), and there is no need to assume that valid 
BCP 47 language tags exist in -BU.  This would indeed introduce 
canonical-form churn where none had existed before.

People do have feelings about what their country should be called, but 
subtags in the LSR are not meant to reflect this perfectly, not even to 
the extent that ISO 3166 attempts to reflect it.  They are just codes. 
If we really are trying to promote stability, it doesn't really matter 
what the two letters are, as long as they uniquely identify the region 
(one reason I've never been swayed by the UK/GB debate).  Adding or 
changing Description fields is a much better way to call a country by 
the name its citizens prefer.

> I guess the question is: how would you suggest we react? Making the 
> LSR make purely political decisions is rife with really ugly potential 
> problems. If we force the LSR to track ISO (with some exceptions), we 
> avoid having to decide if one country name or another is "best". This 
> is not ideal, but it hasn't proved that distressing in practice.

The political decision here would be to follow ISO 3166 every time it 
changes a 2-letter code element to match the latest name reported by a 
country's new administration.  The technically sound decision, from the 
perspective of a stable coding system, would be to keep the canonical 
code element (subtag) the same, and use Description fields to keep up 
with changing names.

> I won't claim this is perfect. I claim that this is what we've always 
> done and for good reason too. Have you considered what would happen if 
> competing claims were made about ISO registrations?

I claim it is not what we set out to do back in 2003, when avoidance of 
the CS debacle was at the core of our efforts.  For many people this was 
a greater motivation to revise RFC 3066 than the addition of script 
subtags.

--
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: "Phillips, Addison" <[email-masked]>
Date: Mon, 3 Nov 2008 07:58:44 -0800

> this decision at IETF LC.

I think you and Randy are not taking a holistic view here.

Would you not agree that there are ISO decisions that "must" be entered into the registry? These would include new language assignments, new script assignments, assignments for new countries (where border changes have occurred, presumably), deprecations, and so on. 

These changes we describe---at great length and complexity---in Section 3.4, which is about 'stability'. If the stability rules are not right, then you should argue about that section. Instead you are arguing that the MUSTard in that section can still be avoided via the public review process.

Please note that what you and Randy are arguing for is ALREADY REQUIRED. Section 3.4, Rule 15.D says:

--
    For ISO 3166-1 codes, if the newly assigned code's meaning is associated with the same UN M.49 code as another 'region' subtag, then the existing region subtag remains as the preferred value for that region and no new entry is created. A comment MAY be added to the existing region subtag indicating the relationship to the new ISO 3166-1 code.
--

In my view, the "SHALL NOT be rejected" phrase protects the LSR from people who would argue (for example) that "MM" should become "BU" (for example).

Addison

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 3 Nov 2008 12:31:40 -0800

Hi -

As a technical contributor...

> From: "Phillips, Addison" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Monday, November 03, 2008 7:58 AM
> Subject: Re: [Ltru] rfc4646bis-18 "SHALL NOT be rejected"
...
> Would you not agree that there are ISO decisions that "must" be
> entered into the registry? These would include new language
> assignments, new script assignments, assignments for new 
> countries (where border changes have occurred, presumably),
> deprecations, and so on. 

No.  I could see treating them as SHOULD, but do not see why
a MUST is necessary for the process or protocol to work, in the
spirit of section 6 of RFC 2119.
 
> These changes we describe---at great length and complexity---
> in Section 3.4, which is about 'stability'. If the stability rules are
> not right, then you should argue about that section. Instead you
> are arguing that the MUSTard in that section can still be avoided
> via the public review process.

Indeed,
   14.  Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that are
        withdrawn by their respective maintenance or registration
        authority remain valid in language tags.  A 'Deprecated' field
        containing the date of withdrawal MUST be added to the record.
        If a new record of the same type is added that represents a
        replacement value, then a 'Preferred-Value' field MAY also be
        added.  The registration process MAY be used to add comments
        about the withdrawal of the code by the respective standard.

*permits* the right thing to be done, but only vaguely hints at it behind
an "if" and some MAYs.
 
>     For ISO 3166-1 codes, if the newly assigned code's meaning is
> associated with the same UN M.49 code as another 'region' subtag,
> then the existing region subtag remains as the preferred value for that
> region and no new entry is created. A comment MAY be added to the
> existing region subtag indicating the relationship to the new ISO 3166-1 code.
> --

I've pointed out this passage before, which is why I'm willing to go with
"no change" for now.  I just see the "SHALL NOT be rejected" as being
in logical conflict with rules like this.
 
> In my view, the "SHALL NOT be rejected" phrase protects the LSR
> from people who would argue (for example) that "MM" should become
> "BU" (for example).

I don't see how this reading is possible.  A phrase like "SHALL NOT be
rejected" would trump any optional causes for possible rejection.

As co-chair...

But let's see what the IESG etc. make of it.

Randy