Hi, RFC 3282 seemed quite short, the one easy read I've had here.From: "Doug Ewell" <doug at ewellic.org>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 It's short! > --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. Yes, for the most part we need current examples. Thanks, C. E. Whitehead cewcathar at hotmail.com > * 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.) How do you keep all this in memory ??? > * 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 |
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.