- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 04 Feb 2012 12:55:26 +0100
- To: Anne van Kesteren <annevk@opera.com>
- CC: Bjoern Hoehrmann <derhoermi@gmx.net>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, HTTP Working Group <ietf-http-wg@w3.org>
On 2012-02-04 08:13, Anne van Kesteren wrote: > On Sat, 04 Feb 2012 04:58:07 +0100, Bjoern Hoehrmann <derhoermi@gmx.net> > wrote: >> * Anne van Kesteren wrote: >>> Other than XML, is there a precedent for using "encoding"? Most >>> places use "charset" I think (HTTP, CSS, HTML). >> >> DOM Level 3 Core uses xmlEncoding and inputEncoding, XSLT uses output- >> encoding, .NET uses System.Text.Encoding.*, Google search uses "ie" and >> "oe" parameters indicating "encoding", ... It seems unlikely you could >> make a sensible argument about usage (outside the context of HTTP >> headers, which includes "HTML") to choose one over the other here. > > Well, CSS has @charset, and HTML has a charset attribute. And > xmlEncoding and inputEncoding are on their way out. I think it would > make more sense to keep using charset as a keyword. One thing that bothers me more is potential confusion with specifying the charset of parameters in WWW-Authenticate. People who do not read specs might read the following WWW-Authenticate: Basic realm="something", charset="UTF-8" as "something" is encoded in UTF-8. Now there's not a lot we can do about people not reading specs, but how about: WWW-Authenticate: Basic realm="something", accept-charset="UTF-8" ? (Stolen from <http://www.w3.org/TR/html4/interact/forms.html#adef-accept-charset>) Best regards, Julian
Received on Saturday, 4 February 2012 11:56:15 UTC