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

Re: Round 3: moving HTTP 1.0 to informational

From: Larry Masinter <masinter@parc.xerox.com>
Date: Fri, 9 Feb 1996 23:15:30 PST
To: fielding@avron.ICS.UCI.EDU
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <96Feb9.231543pst.2733@golden.parc.xerox.com>
Are we converging?
> We should also add:
>>                               Recipients must ignore any media type
>> parameters whose names they do not recognize.
... and then, over "ignore"
> I couldn't think of a better word for "treat the media type as if the
> unrecognized parameter and its value were not present" -- maybe we
> should just add that.
> Aren't we just better off not adding this?
>I think it would help -- I got it from Ned's additions to MIME-IMB.

I don't like 'treat the media type as if the unrecognized parameter
and its value were not present' any better, for the same reason: a
forwarding agent probably shouldn't toss unrecognized parameters.  I
don't think it's really clear what MIME-IMB means by it, and I don't
see what it adds.
Re the ASCII vs 8859-1 default: I think we've just been browsing
different pages. It seems the problem was the escape of Mosaic-l10n,
and the use of different font code sets for Russian, Greek, etc.

> I don't see how.  All WWW software defaults to ISO-8859-1 as per the
> original design of the Web.

?? Mosaic-l10n was pretty popular.

> That is true of libwww, libwww-perl, the
> Python libraries, Mosaic, NCSA httpd, Apache httpd, Spyglass Mosaic,
> MS Internet Explorer, and Netscape Navigator.

I was thinking of 'servers' not 'clients'. Yes, most ISO-8859-1
clients assume ISO-8859-1.

> I disagree -- all current practice that is not known to be broken
> is saying charset="ISO-8859-1" if no charset is present.  That is
> in the definition of the HTTP protocol.

It's really hard to find a web server there that *doesn't* use
whatever-ya-got as the character encoding.  If it were just a few here
and there, I'd go along with you, but when it's all over, it's hard to
swallow saying "oh, they're just broken" and have it apply to
www.*.ru, www.*.jp, www.*.gr, www.*.kr, www.*.cn etc.

How about:

#   The "charset" parameter is used with some media types to define
#   the character set (Section 3.4) of the data.  When no explicit
#   charset parameter is provided by the sender, media subtypes of the
#   "text" subtype are defined to have a default charset value of
#   "ISO-8859-1" when received via HTTP. However, currently many web
#   servers ignore have ignored this specification, and provide data
#   using other charsets but without proper labelling. To compensate
#   for this, some HTTP user agents provide a configuration option to
#   allow the user to change the default interpretation of the media
#   type character set when no charset parameter is given. This
#   situation reduces interoperability. It is recommended servers that
#   provide text in character streams other than ISO-8859-1 should
#   label the data appropriately.

This both promotes the 'recommended' behavior and also tells the

I don't really care about most of the rest of the issues. I still
don't know why you want to say "origin server" when "server" will do,
or [tm] on Unix and Windows when no one else does, but I don't care
much.  And I'll go along with calling out "content-" headers

Are we converging?
Received on Friday, 9 February 1996 23:18:49 UTC

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