Martin Duerst wrote:
> At 23:59 07/05/30, Julian Reschke wrote:
>> Paul Hoffman wrote:
>>> Serious question, not a gratuitous opening of a big can-o-worms: would the WG also consider extensions to HTTP that would go into different documents? That is, is the WG only for the revision of the base spec, or also open to ( animated && lengthy && contentious ) discussion of other documents as well?
>> I guess the idea was that the more we restrict the scope of what we want to do, the easier it'll be to gather the right group of people to do it.
>>
>> For instance, RFC2617 needs a revision badly as well (for instance, wrt to I18N of usernames and passwords, and, as far as I can recall, certain problems with the definition of Digest Auth). IMHO; this should occur in a separate working group.
>
> There are some i18n-related fixes needed in RFC 2616 as well.
>
> The two main ones I know of are:
>
> - RFC 2616 prescribes that headers containing non-ASCII have to use
> either iso-8859-1 or RFC 2047. This is unnecessarily complex and
> not necessarily followed. At the least, new extensions should be
> allowed to specify that UTF-8 is used.
We have talked about this, but it's currently not on the issues list. I
think it should be.
> - RFC 2616 prescribes a default of iso-8859-1 for the 'charset'
> parameter for text/* mime types. At least in two very important
> cases, this is not followed: For text/html, there is no default,
> or put in other words, the default is whatever your browser is
> set to. For text/xml and related types, the default is US-ASCII.
> At a miminum, the spec should make sure the implementers get
> an idea of this, rather than having to find out the hard way.
Agreed. That issue is
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i20>.
Best regards, Julian