- From: Gavin Nicol <gtn@ebt.com>
- Date: Thu, 8 Dec 1994 21:31:17 -0500
- To: mvanheyn@cs.indiana.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Can you be more specific about what you are trying to say? How exactly >should an ideal HTTP server send a document that is in plain, unformatted >US-ASCII text? Using Unicode? If you read carefully. I am proposing UTF-7 or UTF-8. UTF-8 is "ASCII compatible", and I guess one could use CRLF as per MIME safely with either. However, I think that text, in general, should just be sent as a stream of bytes (like GIF is), because there are too many possible representations in use today, and we should allow people to continue using them. CLients should handle line break conversion. In my proposal, if the client can accept US-ASCII (very high probability), then the server would send US-ASCII provided the data was US-ASCII, or easily converted into it. If the data is a mixed language document containing Arabic, Kanji, Hiragana, English, and Thai, and the client indicates that it can accept UTF, it would get UTF data (display is another matter). My biggest problem with the MIME defintion of text/* is that it is horribly skewed toward ASCII, which is *not* a canonical text format, but rather a charset encoding. As such, I think text/* should be basically a binary stream, and if we really want to use the current MIME stuff, it should be: text/plain; charset=us-ascii and we can play all the games we like with CRLF within that. I would prefer a default charset of UTF-? for MIME, but *that* is not likely to happen :-)
Received on Thursday, 8 December 1994 18:30:18 UTC