My thoughts on issues ADAMS84b, ADAMS84

ADAMS84b (406 / Accept-Charset):

To me, the main issue is that the language in 14.2 implies an
"either/or" choice when it means to suggest optional additional
behavior. 

The description of the 406 status code (sec. 10.4.7) already says the
response SHOULD also contain an explanatory entity (unless the response
is to a HEAD request), *and* that the entity does not have to be
"acceptable" to the user agent (according to the constellation of Accept
header fields the user agent has sent).

So I interpret the the clause: 

   "...the server SHOULD send an error response with the 406 (not
acceptable) status code, though the sending of an unacceptable response
is also allowed."

to mean 

   "... the server SHOULD send an error response with the 406 (not
acceptable) status code, though the character set of the response entity
may not be acceptable to the user agent based upon the Accept-Charset
information it provided."

I think the SHOULD needs to stay a SHOULD, but the second part might be
redundant given the existing language in 10.4.7.

Along the same lines, I think the "Note" in 10.4.7 also implies the same
kind of false choice between sending an "unacceptable" response and
sending a 406 response.  To me, sending a 406 is always the right thing
to do -- the choice is whether or not you attach an "unacceptable"
entity to the response.


ADAMS84:

I think the roots of the "implicit" use of iso-8859-1 goes way way back
to the summer of '96 and a discussion which happened at the 36th IETF
meeting.  The main issues involved

* backwards compatibility with HTTP/1.0
* the existence of content mechanisms (CGI, for example) that often have
never indicated what character set they're generating
* a vigorous discussion about what should be assumed for a "text" entity
of "unknown" charset (and iso-8859-1 was winning based on the first
point). 

Maybe Larry and Roy can fill in some of the gaps....

Received on Tuesday, 17 November 1998 09:11:33 UTC