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

Re: Unknown text/* subtypes [i20]

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 12 Feb 2008 18:49:32 +0100
Message-ID: <47B1DC2C.7050307@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Geoffrey Sneddon <foolistbar@googlemail.com>, ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>

Roy T. Fielding wrote:
>> 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 understood we had consensus as our WG chair had directed us to make 
the change in the spec. Also, in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0105.html> 
you seemed to say that you're ok with the change as long as we describe 
the vulnerability.

>>> 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.

I have no problem with that. My understanding was that the 
implementations actually do *not* implement this, but maybe I was 
focused too much to text/xml.

>>> 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 obey
> the standard.  They still don't obey the change you made.  They do not 

I'm aware of that, but at least this change would mean that they are 
violating one specification less than before.

> 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.

Seems more like "back to the drawing board". My understanding was we 
*did* agree on removing the default -- see 
<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/20#comment:4> -- but 
apparently there has been some misunderstanding related to that.

BR, Julian
Received on Tuesday, 12 February 2008 17:49:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT