Subject: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 28 Apr 2009 21:50:32 -0700

The AD mentions:

--
Comment number 7 from the AD review at
http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html

7). In Section 3.4:

    15. Codes assigned by ISO 639, ISO 15924, or ISO 3166-1 that
    conflict with existing subtags of the associated type, including
    subtags that are deprecated, MUST NOT be entered into the
    registry. The following additional considerations apply to
    subtag values that are reassigned:

    [...]

    F. For ISO 3166-1 codes, if there is no associated UN numeric
    code, then the Language Subtag Reviewer SHALL petition the
    UN to create one. If there is no response from the UN
    within ninety days of the request being sent, the Language
    Subtag Reviewer SHALL prepare a proposal for entering in the
    IANA registry as soon as practical a registered variant
    subtag as an alternate value for the new code. The form of
    the registered variant subtag will be at the discretion of
    the Language Subtag Reviewer and MUST conform to other
    restrictions on variant subtags in this document. This
    situation is very unlikely to ever occur.

    16. UN M.49 has codes for both countries and areas (such as '276'
    for Germany) and geographical regions and sub-regions (such as
    '150' for Europe). UN M.49 country or area codes for which
    there is no corresponding ISO 3166-1 code SHOULD NOT be
    registered, except as a surrogate for an ISO 3166-1 code that is
    blocked from registration by an existing subtag. If such a code
    becomes necessary, then the registration authority for ISO
    3166-1 SHOULD

Why SHOULD is used here instead of SHALL?
Similar text in 15.F says SHALL, which is stronger.
Also, 15.F specifies expected response time (90 days), which is missing
below. Any reason why you don't want to specify deadline in this case?

    first be petitioned to assign a code to the
    region. If the petition for a code assignment by ISO 3166-1 is
    refused or not acted on in a timely manner, the registration
    process described in Section 3.5 MAY then be used to register
    the corresponding UN M.49 code. This way, UN M.49 codes remain
    available as the value of last resort in cases where ISO 3166-1
    reassigns a deprecated value in the registry.
--

I think the cases are different.

In the former case, BCP 47 requires a UN M.49 code to exist. In the extremely unlikely event that "we" are the first to notice that one hasn't been assigned, the LSR is obligated to ask for one.

In the latter case (rule 16) we presume that someone is asking for a UN M.49 code that has no corresponding ISO 3166 code. This is not unheard of. It is merely exceptionally rare and typically a Bad Idea to register exceptionally (hence the recommendation to go to ISO, etc.). It isn't SHALL because we don't rely on the code for continued stable operation of the registry. 

Proposed resolution: no change.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Apr 2009 13:26:04 -0700

Hi -

As a technical contributor...

> From: "Phillips, Addison" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, April 28, 2009 9:50 PM
> Subject: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49
>
> The AD mentions:
>
> --
> In the former case, BCP 47 requires a UN M.49 code to exist. In the extremely unlikely event that "we" are the first to notice
that one hasn't been assigned, the LSR is obligated to ask for one.
>
> In the latter case (rule 16) we presume that someone is asking for a UN M.49 code that has no corresponding ISO 3166 code. This is
not unheard of. It is merely exceptionally rare and typically a Bad Idea to register exceptionally (hence the recommendation to go
to ISO, etc.). It isn't SHALL because we don't rely on the code for continued stable operation of the registry.
> Proposed resolution: no change.

I disagree.  The context is where a code has become necessary.  We have
a policy that essentially amounts to avoiding the numeric codes unless there
is no alternative.  No one has suggested any scenario where it might make
sense to not petition the ISO 3166 registration authority.  Maintaining the
policy in an even-handed way suggests to me that we should indeed replace
the sentence currently reading

      If such a code becomes necessary, then the registration authority for ISO
      3166-1 SHOULD first be petitioned to assign a code to the region.

with

      If such a code becomes necessary, then the registration authority for ISO
      3166-1 SHALL first be petitioned to assign a code to the region.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 30 Apr 2009 13:46:30 -0700

>       3166-1 SHALL first be petitioned to assign a code to the

(as contributor)

I agree with this change.

(as editor)

I have implemented this change in my copy.

Addison

Addison Phillips

---

From: Mark Davis <[email-masked]>
Date: Thu, 30 Apr 2009 13:53:56 -0700

Randy, I agree with you on that text, but it isn't sufficient. Bear with me:

This section is setting out requirements: "Assignments to the IANA Language
Subtag Registry MUST follow the following stability rules:"

The full text of this clause is the following (I inserted a paragraph break
for clarity - we should do that in the text also).

        blocked from registration by an existing subtag.

        If such a code
        becomes necessary, then the registration authority for ISO
        3166-1 SHOULD first be petitioned to assign a code to the
        region.  If the petition for a code assignment by ISO 3166-1 is
        refused or not acted on in a timely manner, the registration
        process described in Section 3.5
<http://tools.ietf.org/html/draft-ietf-ltru-4646bis-21#section-3.5>
MAY then be used to register
        the corresponding UN M.49 code.  This way, UN M.49 codes remain
        available as the value of last resort in cases where ISO 3166-1
        reassigns a deprecated value in the registry.

The antecedant is "If such a code becomes necessary". If it *IS* necessary,
then the first SHOULD needs to be a SHALL (as you say), but also the
subsequent MAY needs to turn into a MUST.

2. The use of the passive for SHOULDs and MUSTs and MAYs and so on makes the
fulfillment conditions pretty darned obscure. Jumping into a piece of text
like this requires exegesis to puzzle out who is responsible for doing what.
Based on the text, it appears that the subject of SHOULDs/MUSTs... for this
section is normally "Amendments". That is the Amendments MUST (or SHOULD) do
something. But in a few cases (like 15E), and in this particular case,
because it is not talking about requirements on the amendments but on the
LSR, then it should be the following. (Changes are distinguished by
indentation, since yellow doesn't work for Doug.)

Incorporating both changes:

        blocked from registration by an existing subtag.

        If such a code
        becomes necessary, then the
Language Subtag Reviewer SHALL petition the registration authority for ISO
        3166-1
to assign a code to the
        region.  If the petition for a code assignment by ISO 3166-1 is
        refused or not acted on in a timely manner, the
Language Subtag Reviewer SHALL use the
registration
        process described in Section 3.5
<http://tools.ietf.org/html/draft-ietf-ltru-4646bis-21#section-3.5>
        to register
        the corresponding UN M.49 code.  This way, UN M.49 codes remain
        available as the value of last resort in cases where ISO 3166-1
        reassigns a deprecated value in the registry.

Mark

On Thu, Apr 30, 2009 at 13:26, Randy Presuhn
<[email-masked]>wrote:

> > In the former case, BCP 47 requires a UN M.49 code to exist. In the
> extremely unlikely event that "we" are the first to notice
> > In the latter case (rule 16) we presume that someone is asking for a UN
> M.49 code that has no corresponding ISO 3166 code. This is
> not unheard of. It is merely exceptionally rare and typically a Bad Idea to
> register exceptionally (hence the recommendation to go
> to ISO, etc.). It isn't SHALL because we don't rely on the code for
> continued stable operation of the registry.
> >
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Apr 2009 14:03:27 -0700

Hi -

I agree with Mark's analysis, including the insertion of
a paragraph break.  (FWIW, "yellow" also doesn't work for me.)

Randy

> From: "Mark Davis" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Thursday, April 30, 2009 1:53 PM
> Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UN M.49
...
>         reassigns a deprecated value in the registry.
...

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 30 Apr 2009 14:01:19 -0700

If the petition for a code assignment by ISO 3166-1 is

        process described in Section 3.5<http://tools.ietf.org/html/draft-ietf-ltru-4646bis-21#section-3.5> MAY then be used to register

        reassigns a deprecated value in the registry.
The antecedant is "If such a code becomes necessary". If it IS necessary, then the first SHOULD needs to be a SHALL (as you say), but also the subsequent MAY needs to turn into a MUST.

Addison> Actually, we should mutate the “MAY” to be a regular English verb “can”, which is the intended meaning, I believe.

2. The use of the passive for SHOULDs and MUSTs and MAYs and so on makes the fulfillment conditions pretty darned obscure. Jumping into a piece of text like this requires exegesis to puzzle out who is responsible for doing what. Based on the text, it appears that the subject of SHOULDs/MUSTs... for this section is normally "Amendments". That is the Amendments MUST (or SHOULD) do something. But in a few cases (like 15E), and in this particular case, because it is not talking about requirements on the amendments but on the LSR, then it should be the following. (Changes are distinguished by indentation, since yellow doesn't work for Doug.)

Addison> The LSR can’t be required to do this. The likely case would be for some person who wants/needs a region code (hence the “necessity”). I think my solution (a simple one word change to ‘can’) plus Randy’s “SHALL” is sufficient.

Addison

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 30 Apr 2009 14:03:31 -0700

(as editor)

I have inserted the paragraph break. I have not implemented other changes yet, pending a co-chair determination (since I just five seconds ago sent an email suggesting something different :-) ). 

Addison

Addison Phillips

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Thursday, April 30, 2009 2:03 PM
> To: LTRU Working Group

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Apr 2009 14:13:38 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Subject: RE: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs. UNM.49
>
> (as editor)
> 
> I have inserted the paragraph break. I have not implemented other changes yet,
> pending a co-chair determination (since I just five seconds ago sent an email
> suggesting something different :-) ). 

As co-chair...

The rationales have been circulated.  Let's have a post from the
editor of just what he thinks the proposed text alternatives are,
labeled (A), (B), etc., since there's been enough enough rapid-fire
traffic to make it confusing.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 30 Apr 2009 14:20:39 -0700

(as editor)

Here are the proposed texts:

A) (SHOULD->SHALL, MAY->can)

16.  UN M.49 has codes for both 'countries' and 'areas' (such as
        '276' for Germany) and 'geographical regions' and 'sub-regions'
        (such as '150' for Europe).  UN M.49 'country' or 'area' codes
        for which there is no corresponding ISO 3166-1 code MUST NOT be
        registered, except as a surrogate for an ISO 3166-1 code that is
        blocked from registration by an existing subtag.

        If such a code becomes necessary, then the registration
        authority for ISO 3166-1 SHALL first be petitioned to assign a
        code to the region.  If the petition for a code assignment by
        ISO 3166-1 is refused or not acted on in a timely manner, the
        registration process described in Section 3.5 can then be used
        to register the corresponding UN M.49 code.  This way, UN M.49
        codes remain available as the value of last resort in cases
        where ISO 3166-1 reassigns a deprecated value in the registry.

B) (SHOULD->SHALL, MAY->SHALL, make the LSR do it)

16.  UN M.49 has codes for both 'countries' and 'areas' (such as
        '276' for Germany) and 'geographical regions' and 'sub-regions'
        (such as '150' for Europe).  UN M.49 'country' or 'area' codes
        for which there is no corresponding ISO 3166-1 code MUST NOT be
        registered, except as a surrogate for an ISO 3166-1 code that is
        blocked from registration by an existing subtag.

        If such a code becomes necessary, then the Language Subtag Reviewer 
        SHALL petition the registration authority for ISO
        3166-1 to assign a code to the region.  If the petition for a 
        code assignment by ISO 3166-1 is refused or not acted on in a 
        timely manner, the Language Subtag Reviewer SHALL use the
        registration process described in Section 3.5 to register
        the corresponding UN M.49 code.  This way, UN M.49 codes remain
        available as the value of last resort in cases where ISO 3166-1
        reassigns a deprecated value in the registry.

C) (insert the para break but otherwise do nothing)

16.  UN M.49 has codes for both 'countries' and 'areas' (such as
        '276' for Germany) and 'geographical regions' and 'sub-regions'
        (such as '150' for Europe).  UN M.49 'country' or 'area' codes
        for which there is no corresponding ISO 3166-1 code MUST NOT be
        registered, except as a surrogate for an ISO 3166-1 code that is
        blocked from registration by an existing subtag.

        If such a code becomes necessary, then the registration
        authority for ISO 3166-1 SHOULD first be petitioned to assign a
        code to the region.  If the petition for a code assignment by
        ISO 3166-1 is refused or not acted on in a timely manner, the
        registration process described in Section 3.5 MAY then be used
        to register the corresponding UN M.49 code.  This way, UN M.49
        codes remain available as the value of last resort in cases
        where ISO 3166-1 reassigns a deprecated value in the registry.

Addison Phillips

> Sent: Thursday, April 30, 2009 2:14 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO
> 3166 vs. UNM.49
> 
> Hi -
>

---

From: Mark Davis <[email-masked]>
Date: Thu, 30 Apr 2009 14:26:52 -0700

Thanks for spelling out the options. The old overall structure is:

If X is necessary, the LSR SHOULD do Y, and if that doesn't work the LSR MAY
do Z.

Randy is pointing out that if X is necessary, then the SHOULD must be a
MUST. By the same reasoning, the MAY must be a MUST -- because X is
necessary. So if we accept Randy's change, we need to be consistent and use
text B. The alternative is to do nothing (text C).

But both text A and C are bizarre. If X *IS* necessary, then there is no
reason not to direct the LSR to do the subsequent steps. And if X *is not*
necessary, there is no reason to allow the LSR to do the subsequent steps.
So the optionality needs to be out of the equation.

Mark

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 30 Apr 2009 14:27:21 -0700

> The LSR can’t be required to do this. The likely 
> case would be for some person who wants/needs a 
> region code (hence the “necessity”). I think 
> my solution (a simple one word change to ‘can’) 
> plus Randy’s “SHALL” is sufficient.

I should add: this would also be consistent with our policy of allowing anyone to perform a registration request.

Addison Phillips

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Apr 2009 14:44:24 -0700

Hi -

> Sent: Thursday, April 30, 2009 2:20 PM
> Subject: RE: [Ltru] Ticket #40: AD Issue #7: section 3.4 on ISO 3166 vs.UNM.49
...
...

I prefer "B".

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 30 Apr 2009 14:42:19 -0700

(as contributor)

I have no objection to B.

Addison

Addison Phillips

> Sent: Thursday, April 30, 2009 2:44 PM
> To: LTRU Working Group
> 3166 vs.UNM.49