Re: Comments on the HTTP/1.0 draft.

(Your message reached me with an invalid To: line; something somewhere is
brok.)

>>I have already done so several times.  The canonical form for text is defined
>>in RFC 1521 (which just cites 822, of course) as CRLF delimited for US-ASCII
>>or ASCII-like things like 8859-1.  I do not know of a single Internet 
standard
>>protocol that does not employ this representation; let me know if you know
>>of one.
> 
> Your "canonical" text representation does not work for at least half
> the world's languages, and for more than half of the world's
> population.

Of course; it's a canonical form only for some things, which happen to be
ones that account for the vast majority of current usage (though that will
probably not remain the situation forever.)  It's a canonical representation
for ASCII and ASCII-like text; it says nothing about how one should represent
non-ASCII-like text.  Or GIFs or MPEGs.  Those things can be defined by others.

> DOn't you think it's somewhat "inconsiderate" to force
> these people to use non-standard kludges because people 10 years ago
> had no idea at all about language encodings?

HTTP is for transferring objects; I think it's way beyond the scope of 
the HTTP spec to standardize an international character encoding.  HTTP
should be designed to that whatever method is desired can be dropped in
and used.  In the long run maybe one method will be a clear victor.  Or
maybe not.  Certainly not today.

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?

Received on Thursday, 8 December 1994 10:34:15 UTC