Re: Charset support (was: Accept-Charset support)i

# As for encoding, I have presented my proposals.

I don't believe that any of your proposals improve the situation.

# For the issue of warning text in general, Klaus Weide has made some
# comments that amout to a proposal (don't send text, let the client add
# the text).

While this is a possibility, it isn't in the standard, and I don't
think that it helps significantly in any dimension: it doesn't improve
bandwidth, interoperability, or internationalization.

# I don't know whether this is a suitable solution.

It's not.

# I mainly don't know how big the chance is that we will have
# other warnings than the 6 now defined.

What difference does it make.

# It's mainly the server implementors that I am thinking about.

Server implementors can use static strings for warning messages, and
encoding a string using RFC1522 can be done in a few lines of code.

And no server implementor has complained that RFC 1522 is too
difficult to implement.

# RFC1522 is not inescapable.

It is if you want to serve something other than Unicode and ISO-8859-1
(now) or US-ASCII (if you were to get your way). And anyone who wants
to build software that works for clients who have software that use
anything other than Unicode (i.e., most of the currently deployed web
clients) will have to support RFC 1522.

# Accept-language: Yes. For Accept-Charset, there is a chance to
# make a difference. By the time a serious amount of non-English
# warnings is sent around, the major browsers will have UTF-8
# support anyway. So there is a chance that we can avoid
# RFC1522 altogether.

There is no chance.

Larry

Received on Tuesday, 17 December 1996 11:51:32 UTC