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

On Mon, 16 Dec 1996, Larry Masinter wrote:

> The issue WAS seriously discussed at length in one of the design
> subgroup meetings (I forget which one) but, as you point out, never on
> the mailing list. It was clear that putting warning text inside
> messages was awkward, but given the design constraints, it was the
> best compromise available. If you have a proposal for a better
> solution, then make it.

As for encoding, I have presented my proposals. 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). I don't know whether this is a suitable solution.
I mainly don't know how big the chance is that we will have
other warnings than the 6 now defined.


> # As for "who is the standard", it's definitely http-wg. But not having
> # to implement RFC1522 will be a relief to most implementors, don't
> # you think so?
> 
> RFC1522 is inescapable for those clients that want to use charsets
> other than 8859-1 and UTF8. In the current setup, RFC1522 is
> avoidable for those clients that only implement 8859-1. And RFC1522
> code must be there anywhere for any software package that includes
> both a web browser and a mail client. (I think this includes most
> client vendors). So I'm not sure which implementors you're claiming
> will be relieved.

It's mainly the server implementors that I am thinking about.
They don't have the RFC1522 code around. And my guess is that
as long as they don't send anything, clients won't do much
to receive it. RFC1522 is not inescapable.


> > - For those few Warnings 10-14 defined in the HTTP draft you could
> >   provide tables for several languages.  But those well-defined Warnings
> >   can also be recognized by clients.  I found no requirement in HTTP 1.1
> >   that a client must use the Warning text sent to it, so I assume it is
> >   compliant behaviour if the _client_ creates a message in the appropriate
> >   language (after recognizing the number)..  The client program is in a 
> >   better position to know the user's preferred language(s).  Maybe that
> >   is the approach that will be taken by implemetations.
> 
> The point here is that warning headers are simple text/plain messages
> whose charset is as likely to be influenced by 'accept-charset'
> and 'accept-language' requests as full responses.

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. RFC1522 was an unavoidable pain for 7-bit
mail before the introduction of Unicode/ISO 10646 and UTF-8.
UTF-8 makes it unnecessary. The shorter things are, the
more "charset" tagging gets clumsy. At the end of the scale,
there are things such as URNs and URLs.

Regards,	Martin.

Received on Tuesday, 17 December 1996 06:39:13 UTC