Re: Unknown text/* subtypes [i20]

----- Original Message ----- 
From: "Robert Brewer" <fumanchu@aminus.org>
To: "Mark Nottingham" <mnot@mnot.net>; "Frank Ellermann" 
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
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 
2008-01-04
> (...) 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.

+1

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

Regards,

Javier
.

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