Subject: Re: [Ltru] Fw: [IANA #235907] Last Call: draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP

From: "Doug Ewell" <[email-masked]>
Date: Tue, 12 May 2009 21:40:53 -0600

John Cowan <cowan at ccil dot org> wrote:

>>> 1] What should be done with the existing registry of templates at
>>> http://www.iana.org/assignments/lang-subtags-templates/index.html?
>
> Nothing.  It will grow as new subtags are registered.

There might be one issue related to this, though.  While the LTRU 
process drags on, the continuing efforts of standards bodies and 
individual requesters on ietf-languages may result in new and/or changed 
subtags in the existing Registry that don't appear in draft-4645bis. 
This has already happened as a result of the latest batch of ISO 15924 
script codes, including 'Zinh' and five others.

According to the co-chairs, we can't just "AUTH48" these into the new 
Registry; they need to be re-added, exceptionally, by ietf-languages and 
the Reviewer.  In the case of changes mandated by changes to core 
standards, the outcome will probably be the same, but in the case of 
individually requested variants, this could potentially result in the 
same debate being held twice, possibly with different results.

Given all this, I don't know whether the registration forms for such 
re-registered subtags might need to be posted on the IANA site a second 
time.

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

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 12 May 2009 23:08:42 -0700

Well, we're not done yet. Write a rule in 4645bis to cover these so that there is no silly work to do by the LSR. It should be pretty straight forward:

---
Registrations completed under RFC 4646 after this document was frozen but before the registry was updated MUST be incorporated by IANA in the order in which they were received (as determined by their File-Date record) into the new registry as part of the update process. Registrations after date yyyy-mm-dd are the ones to be scrutinized by IANA.
---

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Doug Ewell
> Sent: Tuesday, May 12, 2009 8:41 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Fw: [IANA #235907] Last Call: draft-ietf-ltru-
> 4646bis (Tags for Identifying Languages) to BCP
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 13 May 2009 06:56:13 -0600

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

> Well, we're not done yet. Write a rule in 4645bis to cover these so 
> that there is no silly work to do by the LSR. It should be pretty 
> straight forward:

Draft-4645bis is done, at least in theory.  It's waiting for an external 
party -- that'd be draft-4646bis -- before being progressed to the IESG. 
I don't know if we want to reopen it at this stage, particularly since 
13th-hour LC comments are coming in now for the document that is still 
open.  But I will make a change if the co-chairs and AD are OK with it. 
I don't like silly work either, and I'm not keen on hearing the Reviewer 
complain about this.

> Registrations completed under RFC 4646 after this document was frozen 
> but before the registry was updated MUST be incorporated by IANA in 
> the order in which they were received (as determined by their 
> File-Date record) into the new registry as part of the update process. 
> Registrations after date yyyy-mm-dd are the ones to be scrutinized by 
> IANA.

If we were to add something, I'd be OK with this particular wording, 
except that "frozen" worries me a little -- I don't think that's defined 
anywhere, and obviously if we make a change now, that "unfreezes" the 
document, so it won't help with the registrations made a month or two 
('Zinh' and company).

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 13 May 2009 07:32:38 -0700

> But I will make a change if the co-chairs and AD are OK with it.
> I don't like silly work either, and I'm not keen on hearing the
> Reviewer complain about this.

I'm not fond of the idea of changing the document either.

> anywhere, and obviously if we make a change now, that "unfreezes"
> the document, so it won't help with the registrations made a month or
> two ('Zinh' and company).
> 

"Frozen" is probably not the right thing. Perhaps just the simple:

--
Registrations completed after date yyyy-mm-dd MUST be incorporated into this registry by IANA. This includes some registrations completed under RFC 4646 prior to the adoption of this document.
--

Anyway, it shouldn't be very hard. If we don't make the change, the LSR could just send an email to IANA once the new registry is in place with a reminder to re-incorporate the changes (and listing which ones they are). Ad hoc processes are sometimes the best way to handle minor issues.

Addison

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 May 2009 10:57:11 -0700

Hi -

> From: "Phillips, Addison" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, May 12, 2009 11:08 PM
> Subject: Re: [Ltru] Fw: [IANA #235907] Last Call:draft-ietf-ltru-4646bis (Tags for Identifying Languages) to BCP
>
> Well, we're not done yet. Write a rule in 4645bis to cover these
> so that there is no silly work to do by the LSR. It should be pretty straight forward:
> 
> ---
> but before the registry was updated MUST be incorporated by IANA in the
> order in which they were received (as determined by their File-Date record)
> into the new registry as part of the update process. Registrations after
> date yyyy-mm-dd are the ones to be scrutinized by IANA.
> ---

As co-chair:

NO WAY.  Re-opening the document to make this kind of change after
IETF last call is not something I would be willing to even consider.
The amount of work and delay caused by doing it would be far greater
than the amount of "extra" work for all those registrations that
have been inundating [email-masked].  Bad tradeoff.

Randy