Subject: [Ltru] Remaining issues

From: "Doug Ewell" <[email-masked]>
Date: Fri, 27 Jun 2008 19:11:16 -0600

What remaining issues do we have before we can go to WG Last Call?

Offhand I can think of two:

* whether to make "cmn" or "zh-cmn" the deprecated value
* what to do about "car"

There may be more; that's why I ask.

I'd really like to start wrapping this up.  One thing that worries me is 
being stuck in IETF Last Call or the RFC Editor queue when ISO 639-3 
releases their annual list of changes.

--
Doug Ewell  *  Arvada, 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: John Cowan <[email-masked]>
Date: Fri, 27 Jun 2008 23:13:13 -0400

Doug Ewell scripsit:

> I'd really like to start wrapping this up.

I strongly agree.

> One thing that worries me is being stuck in IETF Last Call or the RFC
> Editor queue when ISO 639-3 releases their annual list of changes.

I don't think either of those are relevant.  If we are not yet approved,
that just means we can't apply the changes directly in 4645bis but will
have to process them through on ietf-languages in bulk, which shouldn't
be much of a problem.  (Of course, you'll have to play Official Doug.)

As for the editor queue, it doesn't matter: as soon as 4645bis and 4646bis
are approved, the new LSR goes into effect and so does the (mildly) new
process.  Delays in the queue only affect people who want to refer to
some feature of the new RFC either directly or as part of BCP 47.

-- 
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              [email-masked]
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 28 Jun 2008 11:14:48 -0600

John Cowan <cowan at ccil dot org> wrote:

> I don't think either of those are relevant.  If we are not yet 
> approved, that just means we can't apply the changes directly in 
> 4645bis but will have to process them through on ietf-languages in 
> bulk, which shouldn't be much of a problem.  (Of course, you'll have 
> to play Official Doug.)

What I've written in draft-4645bis is:

"The version of the Language Subtag Registry that was current at the 
time of IESG approval of this memo served as the starting point for this 
update."

Then the three ISO 639-3 files are listed individually and referenced by 
specific revision.  OK, you're right; there is no requirement to update 
the 639-3-based data dynamically while IETF is mulling over the drafts.

We would, however, have to update the draft to account for changes made 
by ietf-languages, such as the current "Moldovan" addition, which are 
much fewer in number than 639-3 changes.  It might be problematic to 
tell the Reviewer and ietf-languages to postpone such changes for a few 
weeks until IETF LC is done, because we hold the Reviewer's feet to the 
fire to respond to all requests within two weeks.  Maybe the fact of 
being in IETF LC would have to be cast as a "significant objection 
raised on the list" to justify extending the review period two weeks at 
a time, but I don't know if that would be considered a process 
violation.

> As for the editor queue, it doesn't matter: as soon as 4645bis and 
> 4646bis are approved, the new LSR goes into effect and so does the 
> (mildly) new process.

Right again.  After all this time, I'd forgotten that we operated under 
RFC 3066bis for almost a year before it was approved as RFC 4646.