Re: [xhr] statusText is underdefined

On 2012-03-28 09:48, Glenn Adams wrote:
> ...
>     It's time to stop citing RFC 2616. Please have a look at
>     <http://greenbytes.de/tech/ webdav/draft-ietf-httpbis-p2-
>     semantics-19.html#rfc.section. 4
>     <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.4>>.
>
>
> Since 2616 is published and HTTPbis is not, I will go on citing it.

You can cite it, but it is kind of pointless. If you disagree with what 
HTTPbis says, by all means send feedback to the HTTPbis WG. Some of the 
specs are in Working Group Last Call (this one soonish).

>     Summary: HTTPbis does not attempt to define the character encoding
>     anymore; if you use anything other than US-ASCII, you are on your
>     own. RFC 2047 encoding never was used in practice, and has been removed.
>
>     The right thing to do is the same as for header field values: use a
>     US-ASCII compatible encoding that is most likely to work, and which
>     is non-lossy, so a UTF-8 field value *can* be retrieved when needed.
>
>     That encoding is ISO-8859-1.
>
>
> I'm not sure what you mean by citing ISO-8859-1 and UTF-8 in the same
> context. Please elaborate.

If you have UTF-8 on the wire and the client handles it as ISO-8859-1, 
the API user can extract the original octets from the string and 
re-decode from UTF-8. Of course that requires either heuristics or 
out-of-band information that this actually was UTF-8 in the first place.

>     (And HTTPBis doesn't talk about this because it defines octets on
>     the wire, not an API).
>
> If HTTPbis doesn't define the character encoding of bytes on the wire
> when serializing reason status, then it leaves much to be desired.

It can't without breaking existing implementations. Again, if you want 
to provide feedback, by all means do so.

Best regards, Julian

Received on Wednesday, 28 March 2012 10:48:50 UTC