- From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
- Date: Thu, 04 Jun 2009 16:43:30 -0500
- To: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>
- CC: Mark Baker <distobj@acm.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Julian Reschke wrote:
> Mark Nottingham wrote:
>> Revised proposal:
>>
>> Replace this text in p3 3.2.1:
>>> If and only if the media type is not given by a Content-Type field,
>>> the recipient MAY attempt to guess the media type via inspection of
>>> its content and/or the name extension(s) of the URI used to identify
>>> the resource. If the media type remains unknown, the recipient SHOULD
>>> treat it as type "application/octet-stream".
>> with
>>
>> """
>> If the Content-Type field is not present in a message with a body, the
>> recipient SHOULD assume that the message was sent with a Content-Type
>> of "application/octet-stream".
>>
>> Note that neither the interpretation of the data type of a message nor
>> the behaviours caused by it are not defined by this specification;
>> this potentially includes examination of the content to override the
>> indicated type ("sniffing").
>> """
The first part 'should' read 'MUST', as Julian mentions below, the choice
is in interpretation, not the value of the Content-Type header;
> The first part, now that sniffing isn't mentioned there anymore, makes
> "application/octet-stream" a default at SHOULD level.
Right, this should be default at MUST level; the behavior is entirely
incumbent upon the user agent's choice of action, just as it is for any
arbitrary content-type.
> The definition of "application/octet-stream" in
> <http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.4.5.1> has:
>
> "The recommended action for an implementation that receives an
> "application/octet-stream" entity is to simply offer to put the data in
> a file, with any Content-Transfer-Encoding undone, or perhaps to use it
> as input to a user-specified process."
>
> It's not really the intent to make *that* the default, right?
It has been; clearly documented since '96. This *surprises* you why?
"recommended action" is orthogonal to the UA's choice of action, right?
Clearly, this is not the "MUST", but the existing "SHOULD", to be
superseded by future recommendations for said content type.
The definition clearly provides the latitude to handle octet-stream by
the users' choice of actions. Oh, wait, bother... existing user agents
give the end user no choice. In any case I'm certain your draft will
remedy this.
Received on Thursday, 4 June 2009 21:45:11 UTC