W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: proposed HTTP changes for charset

From: Nickolay Saukh <nms@nns.ru>
Date: Wed, 03 Jul 1996 13:56:58 +0400
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <11680.836387818@Alyona.office.nns.ru>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1007
> < The "charset" parameter is used with some media types to define the
> < character set (section 3.4) of the data. Origin servers SHOULD
> < include an appropriate charset parameter for those media types which
> < allow one (including text/html and text/plain) to avoid ambiguity.
> < In the absence of a charset parameter, the default charset value MAY
> < be assumed to be "ISO-8859-1" when received from a HTTP/1.1 server.
> < Unfortunately, some HTTP/1.0 clients do not properly deal with
> < explicit charset parameters for text/html data, and some HTTP/1.0
> < server sites send no charset parameter, even when the charset of the
> < data is not ISO-8859-1. For compatibility with older clients and
> < servers, implementations may need to be careful when communicating
> < with older versions, by not sending a charset parameter when the
> < data is ISO-8859-1, and by allowing local configuration when
> < recieving unlabelled data from HTTP/1.0 servers.
> This establishes a convention that charset SHOULD be sent, but lays
> out some of the compatibility constraints during the transition
> period. Is this sufficient?

     This word or the adjective "recommended" means that there may exist
     valid reasons in particular circumstances to ignore this item, but
     the full implications should be understood and the case carefully
     weighed before choosing a different course.

SHOULD and MAY in first paragraph allows server not to label
iso-8859-5 entities and be HTTP/1.1 conformant.
Received on Wednesday, 3 July 1996 03:02:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC