W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Comments on the HTTP/1.0 draft.

From: Gavin Nicol <gtn@ebt.com>
Date: Thu, 8 Dec 1994 21:31:17 -0500
Message-Id: <199412090231.VAA07769@ebt-inc.ebt.com>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:09 EDT