ISSUE-24: A compromise on authoritative metadata using Accept?

We had some discussion last night of issue-24 [1].  From the unapproved 
draft minutes:

"DC: our position on contentTypeOverride-24 is: if it says text/plain, 
it's text/plain. Recent HTML 5 drafts say: if you're looking for an image, 
treat what comes back as an image, even if the MIME type says text/plain 
(or something pretty close to that)"

We had a discussion that included some speculation that one path would be 
to compromise our position on Authoritative Metadata, and while I'm not 
particularly happy about the prospect, I think it's worth looking at what 
the best possible compromises might look like.  So, while having trouble 
sleeping last night, the following admittedly idea came to me.

* We would stick with the story that Content-Type is the authoritative 
source of media-type info for a retreived representation.

* The HTML 5 spec will allow for the <img> tag game, but it will state 
that users agents SHOULD issue an Accept: header, e.g. for image/jpeg, in 
that case.

* The authoritative metadata finding (and perhaps a revised RFC 2616) will 
state: as stated in section 14.1 of RFC 2616, a server SHOULD respond with 
status code 406 if the requested type is not available.  If the server is 
nonconformant and returns status code 200 with some other type, then the 
user agent MAY, at its own risk, infer that the data is of the requested 
type (or one of the requested types), rather than of the type given in the 
Content-type.  Ideally, the user agent should warn the user that it is 
recovering from a non-conformant use of HTTP.

It seems to me that this has, among other things, the desirable 
characteristic that the semantics are described at the protocol level, 
which is not true if you just predicate it all on: "If the link was from 
an <img> tag".

Rationale:

RFC 2616 [2] says:

"The Accept request-header field can be used to specify certain media 
types which are acceptable for the response.  Accept headers can be used 
to indicate that the request is specifically limited to a small set of 
desired types, as in the case of a request for an in-line image."

[...]

"If an Accept header field is present, and if the server cannot send a 
response which is acceptable according to the combined Accept field value, 
then the server SHOULD send a 406 (not acceptable) response."

So, if a client issues Accept: image/jpeg, and gets back Status code 200 
with Content-type: text/plain, it has Prima Facie evidence that the server 
has violated RFC 2616.  The presentation of the image is rationalized as a 
best effort to recover from an error.

I'm suspect there are holes in this, but does it perhaps suggest a 
promising direction?  Thanks.

Noah

[1] http://www.w3.org/2001/tag/2007/09/13-tagmem-minutes#item05
[2] http://www.ietf.org/rfc/rfc2616.txt

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Friday, 14 September 2007 04:46:16 UTC