Subject: [Ltru] draft-21 mod: move RFC 4645 reference to informative

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 8 Feb 2009 09:23:40 -0800

Issue: move RFC 4645 reference to informative

Resolution: moved to the informative section from the normative section. The "normative" material in 4645 in question isn't up to the standard of having a normative reference.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

---

From: Martin Duerst <[email-masked]>
Date: Mon, 09 Feb 2009 11:06:05 +0900

Hello Addison,

At 02:23 09/02/09, Phillips, Addison wrote:
>Resolution: moved to the informative section from the normative section. 
>The "normative" material in 4645 in question isn't up to the standard of 
>having a normative reference.

This is as requested by the chairs. However, it is incomplete.

On February 2nd, I wrote:

I have looked at this and at the diff, and have run the idnits tool.

However, we now have an informative reference in a normative sentence:

       E.  UN numeric codes and ISO 3166-1 alpha-2 codes for countries
           or areas listed as eligible for registration in Section 4 of
           [RFC4645] but not presently registered MAY be entered into
           the IANA registry via the process described in Section 3.5.
           Once registered, these codes MAY be used to form language
           tags.

My understanding from previous discussions (both Randy and I had
the same idea) was that for this instance of referencing [RFC4645],
we would replace it inline with the only instance left, resulting
in something like:

       E.  The UN numeric code or ISO 3166-1 alpha-2 code (once assigned)
           for the Channel Islands MAY be entered into the IANA registry
           via the process described in Section 3.5 (for historic
           details, see [RFC4645]).

Can you please make such an update to your staging draft,
so that we are ready to move forward when the copyright
issues are solved.

I haven't seen anybody reply to this except for Gerard Lang.

Can you please make the requested edit, or tell me why you
think it's not appropriate?

Regards,    Martin.

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

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 8 Feb 2009 20:43:34 -0800

I didn't make the change to the text in part because it was overlooked. However, I'm also allergic to the text you propose. The reference to 4645 used to be normative because, in fact, it was normative in precisely this spot. However, the Channel Islands related registrations were accomplished in the 4646 era, so having a bit of "MAY" for them seems redundant.

I therefore propose putting a version of your text shaped thusly:

E. A few ISO 3166-1 codes, representing the Channel Islands, for which no UN M.49 code was assigned are assigned in the registry. For historic details, see [RFC 4645].

This eliminates the (formerly necessary) normative reference and the no-longer-appropriate normative languages.

Addison

Addison Phillips

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]]
> Sent: Sunday, February 08, 2009 6:06 PM
> To: Phillips, Addison; LTRU Working Group
> Subject: Re: [Ltru] draft-21 mod: move RFC 4645 reference to
> informative
> 
> Hello Addison,
>

---

From: Martin Duerst <[email-masked]>
Date: Mon, 09 Feb 2009 15:49:42 +0900

Hello Addison,

At 13:43 09/02/09, Phillips, Addison wrote:
>I didn't make the change to the text in part because it was overlooked.

Okay, no problem.
 
>However, I'm also allergic to the text you propose. The reference to 4645 
>used to be normative because, in fact, it was normative in precisely this 
>spot. However, the Channel Islands related registrations were accomplished 
>in the 4646 era, so having a bit of "MAY" for them seems redundant.

That's not my understanding. Three registrations have been made,
but a fourth is still outstanding.

If I put together section 4 of RFC 4645:

4.  Omitted Code Elements

   The following code elements from [UN_M.49] were not associated with
   [ISO3166-1] alpha-2 code elements.  Consequently, they were not
   assigned as subtags in the initial Language Subtag Registry, but were
   valid candidates for registration as region subtags, using the
   process in [RFC4646]:

      830   Channel Islands
      831   Guernsey
      832   Jersey
      833   Isle of Man

   The last three became ineligible for registration in April, 2006,
   when the [ISO3166-1] code elements GG, JE, and IM were assigned as
   region subtags.

with section 2.2.4, point 4.E, of draft-ietf-ltru-4646bis-20.txt
(as currently published):

then for me, the NET RESULT is that
      830   Channel Islands
is currently still available for registration. This matches the last
paragraph of section 4 of RFC 4645, as well as the current IANA registry,
which shows GG, JE, and IM as registered, but no registration for
"Channel Islands".

My reading of both 4645/4646 as well as the new drafts as published
(i.e. up to version -20), is that if somebody had a need to tag some language
(let's say English) with a region of "Channel Islands", then s/he could
apply to ietf-languages and require the code 830 to be enterend into
the IANA registry, and would then use en-830 for "English as used in
the Channel Islands".

>E. A few ISO 3166-1 codes, representing the Channel Islands, for which no 
>UN M.49 code was assigned are assigned in the registry. For historic 
>details, see [RFC 4645].
>
>This eliminates the (formerly necessary) normative reference and the 
>no-longer-appropriate normative languages.

In my reading, this eliminates too much, and is a (small but) substantive
change, for which it's way too late (unless somebody comes and claims
that this is really, really important and affects interoperability).

If you don't like the exact text I propose, please propose alternative
text that doesn't change the content.

Regards,    Martin.

---

From: Mark Davis <[email-masked]>
Date: Mon, 9 Feb 2009 08:04:53 -0800

Because the Channel Islands are equal to the Bailiwick of Guernsey plus the
Bailiwick of Jersey, I think the need for 830 has gone by (you may not
disagree with that - you did have a MAY - but just to be clear).

Back to the matter at hand, I think all of the suggestions are missing
something. This spec will live for a long time. Saying that the Channel
Islands MAY be registered will become false if and when a two letter code
for them appears. I would just delete E, since the issues are covered in the
other bullets.

Mark

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 9 Feb 2009 09:06:15 -0800

If a two letter code appears for 830, it can be registered “normally”: it is covered by existing rules. If we just eliminate “E” we eliminate the ability to (separately) register 830 as a subtag. I agree with Mark that no one needs that subtag—there exist the other Channel Island subtags and no one has registered ‘830’ having been given the opportunity.

So: +1 for eliminating “E” altogether.

Addison Phillips

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Davis
Sent: Monday, February 09, 2009 8:05 AM
To: Martin Duerst
Cc: Phillips, Addison; LTRU Working Group
Subject: Re: [Ltru] draft-21 mod: move RFC 4645 reference to informative

Because the Channel Islands are equal to the Bailiwick of Guernsey plus the Bailiwick of Jersey, I think the need for 830 has gone by (you may not disagree with that - you did have a MAY - but just to be clear).

Back to the matter at hand, I think all of the suggestions are missing something. This spec will live for a long time. Saying that the Channel Islands MAY be registered will become false if and when a two letter code for them appears. I would just delete E, since the issues are covered in the other bullets.

Mark

On Sun, Feb 8, 2009 at 22:49, Martin Duerst <[email-masked]<mailto:[email-masked]>> wrote:
Hello Addison,

Okay, no problem.

If I put together section 4 of RFC 4645:

4.  Omitted Code Elements

     830   Channel Islands
     831   Guernsey
     832   Jersey
     833   Isle of Man

with section 2.2.4, point 4.E, of draft-ietf-ltru-4646bis-20.txt
(as currently published):

Regards,    Martin.

>> From: Martin Duerst [mailto:[email-masked]<mailto:[email-masked]>]
>> >[email-masked]<mailto:[email-masked]>
>> #-#-#  http://www.sw.it.aoyama.ac.jp
>> mailto:[email-masked]<mailto:[email-masked]>

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]<mailto:[email-masked]>

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

---

From: John Cowan <[email-masked]>
Date: Mon, 9 Feb 2009 13:56:22 -0500

> So: +1 for eliminating “E” altogether.

+1

-- 
John Cowan    <[email-masked]>     http://www.ccil.org/~cowan
But no living man am I!  You look upon a woman.  Eowyn I am, Eomund's daughter.
You stand between me and my lord and kin.  Begone, if you be not deathless.
For living or dark undead, I will smite you if you touch him.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 10 Feb 2009 10:25:26 +0900

I understand your reasoning, and content-wise I might even
agree, but it IS a normative change, and as a co-chair,
I don't want to go to another last call at this stage.
If nobody has figured out until now that this item might
be removed, then we can as well leave it in.

If Randy as a co-chair has another opinon, I'll defer to him
on this matter.

Regards,   Martin.s

At 02:06 09/02/10, Phillips, Addison wrote:
>If a two letter code appears for 830, it can be registered $Bc`WO(Bormally$Bc`Y(B it is covered by existing rules. If we just eliminate $Bc`W&c`Y(Bwe eliminate the ability to (separately) register 830 as a subtag. I agree with Mark that no one needs that subtag$Bc`GU(Bhere exist the other Channel Island subtags and no one has registered $Bc`O(B30$Bc`Q(Bhaving been given the opportunity.
> 
>So: +1 for eliminating $Bc`W&c`Y(Baltogether.
> 
>Addison Phillips
>On Sun, Feb 8, 2009 at 22:49, Martin Duerst <<mailto:[email-masked]>[email-masked]> wrote:
>Hello Addison,
>
>>> ><mailto:[email-masked]>[email-masked]
>>> #-#-#  <http://www.sw.it.aoyama.ac.jp>http://www.sw.it.aoyama.ac.jp
>>> mailto:[email-masked]
>
>
>#-#-#  <http://www.sw.it.aoyama.ac.jp>http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]
>
><mailto:[email-masked]>[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 9 Feb 2009 22:32:45 -0800

Hi -

> From: "Martin Duerst" <[email-masked]>
> To: "Phillips, Addison" <[email-masked]>; "Mark Davis" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Monday, February 09, 2009 5:25 PM
...

I'm also wary of introducing technical changes at this late stage,
particularly without any demonstrated need.  Please,let's just 
replace the paragraph with:

       E.  The UN numeric code 830 (Channel Islands) and any corresponding
           ISO 3166-1 alpha-2 code not presently registered MAY
           be entered into the IANA registry via the process described
           in Section 3.5.

(I deliberately lost the last sentence of the paragraph.  It
added nothing and would not be missed.)

Randy

---

From: Kent Karlsson <[email-masked]>
Date: Tue, 10 Feb 2009 13:34:39 +0100

I agree.

---

From: Mark Davis <[email-masked]>
Date: Tue, 10 Feb 2009 09:50:08 -0800

Just so we are all on the same page, the v21 text is:

UN numeric codes and ISO 3166-1 alpha-2 codes for countries or areas listed
as eligible for registration in Section 4 of [RFC4645] (Ewell, D., "Initial
Language Subtag Registry," September
2006.)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#RFC4645>but
not presently registered MAY be entered into the IANA registry via the
process described in Section 3.5 (Registration Procedure for
Subtags)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#registrationProc>.
Once registered, these codes MAY be used to form language tags.

http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#region

I think the minimal change is:

UN numeric codes and ISO 3166-1 alpha-2 codes for countries or areas listed
as eligible for registration in Section 4 of [RFC4645] (Ewell, D., "Initial
Language Subtag Registry," September
2006.)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#RFC4645>but
not presently registered MAY be entered into the IANA registry via the
process described in Section 3.5 (Registration Procedure for
Subtags)<http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#registrationProc>,
subject to provision D. Once registered, these codes MAY be used to form
language tags.

While I think we are all clear that provision D limits provision E -- that
is, that if ISO adds a code XX for 830, then 830 could no longer be
registered -- we should make it very clear in the document. Once we do that,
we can leave the rest of the information alone.

Mark

[Side note for some future version -- NOT for now.

The MUSTs and MAYs on what can and cannot be added to the registry found in
various places:

   1. http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#sources
   2.
   http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#ianastability
   3.
   http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#registrationProc
   4. http://inter-locale.com/ID/draft-ietf-ltru-4646bis-20.html#possibleReg
   5. perhaps others

Part of it is that we want to give users of the registry information on what
can and cannot occur in the registry, and in other sections give the
Language Subtag Reviewer information on what he/she must/may do, and then in
other sections give those filling out the Registration form information on
what they can/may request. But that means that we have duplication in
various places, and it is hard to make sure that everything is covered
everywhere. Ideally we would have one place where all the restrictions were
set out, and we could just reference that.

End side note.]

On Tue, Feb 10, 2009 at 04:34, Kent Karlsson <[email-masked]>wrote:

> I agree.
>
>
> Den 2009-02-10 07.32, skrev "Randy Presuhn" <[email-masked]
> >:
>

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 10 Feb 2009 13:01:52 -0800

That's not the point of E, though. E covers the case allowing either a UN M.49 code or a ISO 3166-1 code that has no corresponding element in the other standard (and is not already covered by one of our rules) to be registered. This set now consists of exactly one code ('830'). So Randy's proposed text isn't quite right. It should read:

--
For historical reasons, the UN numeric code 830 (Channel Islands), which was not registered at 
the time this document was adopted and had, at that time, no corresponding ISO 3166-1 code, 
MAY be entered into the IANA registry via the process described in Section 3.5, provided no
ISO 3166-1 code with that exact meaning has been previously registered.
--

This is effectively the same text as what we have (so it isn't a "normative change"). Since "E" refers to a list and that list has exactly one item, it probably makes sense to just say it.

If ISO 3166-1 were to give 830 a code (we are assured that it will not, apparently), then "E" wouldn't apply any more. Then our existing rules would apply.

Addison

Addison Phillips

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Monday, February 09, 2009 10:33 PM
> To: LTRU Working Group

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Feb 2009 13:16:22 -0800

Hi -

> From: "Phillips, Addison" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, February 10, 2009 1:01 PM
> Subject: RE: [Ltru] draft-21 mod: move RFC 4645 reference to informative
...
...

As a technical contributor...
This proposed text looks very good to me.

As co-chair...
This seems to be our best "minimum change" proposal for this paragraph
so far.  Are there any objections to adopting Addison's proposed text?

Randy

---

From: Mark Davis <[email-masked]>
Date: Tue, 10 Feb 2009 13:26:49 -0800

no objections

Mark

---

From: John Cowan <[email-masked]>
Date: Tue, 10 Feb 2009 16:32:44 -0500

> so far.  Are there any objections to adopting Addison's proposed text?

I'd strike "for historical reasons", which seems unnecessary to me.

-- 
What is the sound of Perl?  Is it not the       John Cowan
sound of a [Ww]all that people have stopped     [email-masked]
banging their head against?  --Larry            http://www.ccil.org/~cowan

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Feb 2009 13:33:52 -0800

Hi -

this was assigned issue #3.

Randy

> To: "LTRU Working Group" <[email-masked]>
> Sent: Sunday, February 08, 2009 9:23 AM
> Subject: [Ltru] draft-21 mod: move RFC 4645 reference to informative
>
> Resolution: moved to the informative section from the normative section. The "normative" material in 4645 in question isn't up to
the standard of having a normative reference.

---

From: Martin Duerst <[email-masked]>
Date: Wed, 11 Feb 2009 16:54:24 +0900

Agreeing with Randy, both as a technical contributor and as a co-chair.

And fine with removing the "For historical reasons,", leaving that
to the editor to decide.

Regards,    Martin.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 12 Feb 2009 12:08:56 -0800

Hi -

As co-chair:
Seeing no further comment, we'll accept the resolution

> > ISO 3166-1 code with that exact meaning has been previously registered.

"For historical reasons" may be omitted at the editor's discretion.

I've updated the status to "closed".

To see all reports, including closed ones, use:
http://trac.tools.ietf.org/wg/ltru/trac/report/6

Randy