W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: Unknown text/* subtypes [i20]

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 12 Feb 2008 09:37:23 -0800
Message-Id: <167B670F-C27F-4B3B-9597-83B5148E1C99@gbiv.com>
Cc: Geoffrey Sneddon <foolistbar@googlemail.com>, ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

On Feb 12, 2008, at 8:42 AM, Julian Reschke wrote:
> Geoffrey Sneddon wrote:
>> On 12 Feb 2008, at 14:03, Julian Reschke wrote:
>>> HTTP/1.1 recipients MUST respect the charset label provided by  
>>> the sender; and those user agents that have a provision to  
>>> "guess" a charset MUST use the charset from the content-type  
>>> field if they support that charset, rather than the recipient's  
>>> preference, when initially displaying a document.
>> Does this mean using US-ASCII for text/xml without an explicit  
>> charset?
> It means whatever the other specifications say about that (e.g.,  
> RFC2046 and RFC3023).

And that's why there is no consensus for this change.  -1

>> I read it as meaning so (as by omitting it you have implicitly  
>> sent a US-ASCII charset label).
> Yes. So HTTP/1.1 doesn't specify a default anymore, but there are  
> defaults specified somewhere else.

Which have been wrong for 20 years, even for email.  The default was  
changed for HTTP
because that is how all HTTP implementations worked at that time.  A  
new default may
be required, but it can't make compliant HTTP/1.1 senders non- 
compliant.  It has
to match what HTTP/1.1 interoperates with today.

>> If you really want to require such a thing it is worth noting that  
>> it is extremely unlikely that any major HTTP implementation will  
>> actually abide by what 2616bis requires (therefore making the  
>> major implementations non-conforming). Do you really want to write  
>> a spec. with  couple of academic/experimental implementations, and  
>> nothing else? Surely it'd be more useful to specify HTTP in such a  
>> way that the major implementations can actually abide by the  
>> specification (while meeting market demands)?
> Did you follow the long discussion leading to this change?
> The reason we are making a change is that user agents indeed do  
> *not* do what RFC2616 said. Thus we're removing that specific  
> requirement. IMHO.

First, that's not true.  Four popular browser implementations do not  
the standard.  They still don't obey the change you made.  They do  
not amount
to the measure of all user agents.

I was waiting for specific text to be suggested, but we can just fix it
in the draft.

Received on Tuesday, 12 February 2008 17:37:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:34 UTC