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

Re: Unknown text/* subtypes [i20]

From: Javier Godoy <rjgodoy@fich.unl.edu.ar>
Date: Wed, 9 Jan 2008 16:51:58 -0200
Message-ID: <002901c852f0$bbe3db40$017ba8c0@Javier>
To: "Robert Brewer" <fumanchu@aminus.org>
Cc: <ietf-http-wg@w3.org>, "Mark Nottingham" <mnot@mnot.net>, <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>

----- Original Message ----- 
From: "Robert Brewer" <fumanchu@aminus.org>
To: "Mark Nottingham" <mnot@mnot.net>; "Frank Ellermann" 
Cc: <ietf-http-wg@w3.org>
Sent: Wednesday, January 09, 2008 3:48 PM
Subject: RE: Unknown text/* subtypes [i20]

Robert Brewer wrote:

>Mark Nottingham wrote:
>> note the following text:
>>> Data in character sets other than "ISO-8859-1" or its subsets MUST
>>> be labeled with an appropriate charset value.
>> Depending on how you read the context, this would need to be restated
>> as something like:
>> "Media subtypes of the "text" type MUST be labeled with an appropriate
>> charset value."
>> My preference would be to soften this to a SHOULD, so that in cases
>> where it's administratively difficult for people to set a charset
>> value, conflicting statements aren't made. I'd rather have the
>> metadata be explicitly missing than wrong.
>Except that administrative difficulties lead to complaints which lead to
>fixed software where nothing else seems to. As a server implementor, I'm
>tired of guessing charsets on request bodies [1]. I'd much rather see a
>MUST so the conversation fails in a way that clearly fixes blame, even
>though I may choose to work around it.

>From RFC 2119:
 SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

In this case, the "full implications" of a client not sending a charset 
parameter would be that the server
may do a wrong guess (AFAIK, it is not REQUIRED to do any guess at all).

This situation has a counterpart on the recipient-side, as Julian said on 
> (...) we can state "in absence of charset parameter recipient MAY do
>charset sniffing (BOM, XML decl, HTML meta tag, ...), which would
>probably match what's actually implemented.


>From RFC 2119:
 MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

I think it adequately describes the situation you refer (as complaints lead 
to implementing OPTIONAL features, which would have not been implemented 


Received on Wednesday, 9 January 2008 18:52:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC