Ian Hickson wrote: > For example HTML4 says to not default to any encoding at all [1] [...] Yes, but HTTP has to work for plain text, pre-HTML 4, etc., and I think HHTP needs its own idea of what is allowed in a HTTP header. If one side refuses to say what the body is the other side needs a working assumption for the job at hand (= HTTP transmission). How browsers display a body (if at all) is a different question. "Assume it's something remotely related to ASCII, i.e. all octets that could be ASCII actually are ASCII" is good enough for HTTP, isn't it ? I don't see where "assume Latin-1" is actually needed today with respect to *HTTP*, even for HTML 2 (or arguably 3.2). The W3C validator ignores this HTML detail - AFAIK I'm the only user who ever asked if that's as it should be. It is irrelevant outside of validator torture tests... :-) > it would seem pointless for HTTP to try to define something > here: it would just get ignored. I think we mean the same thing when I propose that it's pointless to define "something different from MIME" in the HTTP spec., a normative MIME reference (+ explanation of the change) will do. FrankReceived on Tuesday, 15 January 2008 03:12:18 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:19 UTC