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

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



Phillips, Addison wrote:
The one bit of language tagging infrastructure that we have not revised since this whole body of work has started is RFC 3282, which defines Content-Language and Accept-Language. This morning I had cause to want to reference it, but a desire not to (since it depends on 3066 rather than the current-and-future BCP 47).
FWIW, the reference is:

 [TAGS]      Alvestrand, H., "Tags for the Identification of
              Languages", BCP 47, RFC 3066

At the time, it seemed obvious to me that references to a standards-track specification were intended to be "this one or any version that obsoletes it"; it was only later that I discovered that there could be multiple differences of opinion on this even in cases that seemed obvious to me.

If the document were to be revised, an obvious improvement would be to split the references into normative and informative, and remove the unused ones - none of the ISO references are in fact used; this was the result of a rather hasty split from 1766.

If YAM decides that it's ready to go to Standard status, I really don't see any need except for formalism and nitpicking to revise the document at all.

Over to YAM list....

                  Harald


 I'm pretty sure that the whole machinery of a WG is not needed to revise this document--I'm thinking it would make a suitable individual submission. But I thought I'd mention it here to see if anyone had thoughts about whether it were necessary, whether this list would make a suitable place to solicit comments, and whether anyone thought a WG charter were necessary for same (this last I studiously hope is not the case).

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.