Re: Comments on the HTTP/1.0 draft.

In the end, I think that we either change the definition of
"content-type" to modify the handling of text/* types (such change
being unlikely) or we register application/plaintext and
application/html to be "just like text/plain and text/html
(respectively), but "charset" defaults to ISO-8859-1 and the EOL
convention depends on the character set. For charset=US-ASCII and
ISO-8859-1, the EOL convention is that EOLs consist of either CR, LF,
or CRLF, but uniformly through the body. We may want to restrict the
value of the "charset" parameter to be those things which have
complete registration information, including US-ASCII transliteration
(<degree>, <a'>), mapping to other charactersets, etc.

This would allow current servers to continue to send what they are
sending, except that they'd need to label it differently

The labelling can be upgraded gracefully (clients can be
modified to Accept: application/html & application/text, and then
servers can send things that way if they're asked for.)

This also allows application/plaintext; charset=UNICODE, as well as
allowing Japanese web servers to export JIS codes in a way that
JIS-accepting browsers could read the data efficiently, and others
could still view the pages, albeit after translation (either by client
or server).

Received on Friday, 9 December 1994 21:07:48 UTC