Subject: Re: [Ltru] RFC 3282: should we revise it?

From: "Doug Ewell" <[email-masked]>
Date: Wed, 5 Aug 2009 19:37:38 -0600

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

> Ever the optimist, I would hope that such a revision wouldn't require 
> the level of effort needed for the BCP 47 work.

You never know.  In September 2005 on ietf-languages, Peter Constable 
mentioned the upcoming 4646bis effort and said:

"For my part, I hope that *that* revision is completed in a *much* 
shorter time that 3066bis has taken."

As we now know, 4646bis took a year or so longer than 4646.

But a quick look at RFC 3282--which is possible, since it's only 8 pages 
long including boilerplate and page breaks--suggests that the following 
changes might be all that is necessary:

* Update reference to ABNF and remove EBNF in sections 2 and 3.

* Update examples in Section 2.1 using i-languages to use ISO 639-based,
  grandfathered, hypothetical 5-to-8-character registered, or private-
  use tags instead.

* Consider a simple update to Section 4, possibly just a pointer to the
  security section of 4646bis.

* As suggested by CE Whitehead, update reference to Language "Tag"
  Reviewer (which was correct at the time 3282 was written) to refer to
  the Language "Subtag" Reviewer instead.  (On the other hand, it's just
  an acknowledgement.)

* Split references into normative and informative.

* Update [TAGS] reference to 3066 to point to 4646bis instead.

* Consider removing references to ISO standards, as the syntax and
  content of tags are fully defined by 4646bis and the Registry.

This in turn suggests that it should be feasible for an individual to 
prepare and submit an update without experiencing the surreal delays of 
the LTRU process, and without being subjected to undue slings and 
arrows.

--
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: Wed, 5 Aug 2009 21:22:27 -0700

> As we now know, 4646bis took a year or so longer than 4646. You forget that there were a dozen or so draft-davis-phillips documents before the WG even started.

No it didn't. Mark and I started 4646 on the very first day of the Iraq war.

> the LTRU process, and without being subjected to undue slings and

Well, as noted, "ever the optimist".....

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 5 Aug 2009 23:28:38 -0600

"Phillips, Addison" <addison at amazon dot com> wrote (slightly 
rearranged):

> No it didn't. Mark and I started 4646 on the very first day of the 
> Iraq war. You forget that there were a dozen or so 
> draft-davis-phillips documents before the WG even started.

I didn't forget.  My copy of draft-phillips-langtags-00 is dated 
2003-12-17.  The final draft which became RFC 4646, 
draft-ietf-ltru-registry-14, was approved by IESG on 2005-11-15, or 699 
days later.  We did wait another 10 months for RFC numbers, but that 
time was mostly spent working on the relatively uncontroversial 
draft-4647 and planning for LTRU 2.0.

Draft-ietf-ltru-4646bis-00, the first LTRU 2.0 draft, was dated 
2006-09-11 -- perhaps coincidentally, the same date RFC 4646 was 
published.  Draft-ietf-ltru-4646bis-23 was approved by IESG on 
2009-06-18 (the formal announcement came a week later).  That's a span 
of 1,011 days, or 315 days longer for LTRU 2.0 than for LTRU 1.0.  And 
of course, we're still waiting for RFC numbers.

I'd be willing to bet we spent more days actually *working* on the first 
set of drafts than on the second, but we had a LOT of downtime over the 
past 3 years.  Some issues were left unresolved and undiscussed for 
weeks at a time.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 22 Aug 2009 14:37:11 +0900

[Co-chair hat off; mostly written a couple weeks ago]

I'm mostly offline now, so I haven't actually looked at the text, but 
from Doug's list below, it seem to me that an update may be desirable, 
but not really needed. That means that if somebody (like the YAM WG) 
really has the cycles to do, why not, but otherwise, there might be more 
pressing work around. Please note that RFC 4646 obsoletes (or was it 
updates) RFC 3066, so for all intents and purposes, the references in 
RFC 3282 to RFC 3066 are actually to RFC 4646, or soon an even newer one.

Regards,   Martin.

On 2009/08/06 10:37, Doug Ewell wrote:
> the LTRU process, and without being subjected to undue slings and arrows.
>
> --
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru

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