[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 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.