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

On Sun, 15 Dec 1996, Klaus Weide wrote:

Hello Klaus,

> On Fri, 13 Dec 1996, Martin J. Duerst wrote:
> [ lots snipped ]

> > Then let's make this file (and a little bit of code to
> > extract the desired warning) available to implementors,
> > and let's ask them to just send the strings out as is,
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > and just silently ignore the antiquated ISO-8859-1 default
>       ^^^^^^^^^^^^^^^^^^^^
> > for warnings, and silently change that to UTF-8.
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Sounds like an extremely bad idea.

It probably was. I appologize.

> The HTTP 1.1 draft is accepted and
> is going to become an RFC.  That is done and over.  If you think that
> part of it is really unacceptable, you should try to take that up with
> the http-wg for the upcoming revision when the RFC advances to Draft
> Standard (or not), and if you feel the arguments are not adequately
> considered, take it up with the IESG (or whatever are the appropriate
> channels).  Or you could write a "Warnings considered harmful" RFC.

These are obviously better ways to deal with it. What I strongly object
against is the attitude "the draft is accepted" + "it's in the draft"
=> "it's fixed forever".
The issue was never seriously discussed, and as you show below,
even more general issues (the question whether it makes sense to
have the server send out text messages in the first place) obviously
haven't been discussed in enough depth either. I think it should be
discussed, and a better solution should be found.



> > Interestingly enough, with this solution, the server side
> > does not have to worry AT ALL about what encoding the
> > warnings are in, how to convert that encoding to something
> > allowed, how to implement RFC1522, or whatever.
> > I guess implementors will love this. Those that don't care
> > wont do anything else than English, anyway.
> 
> - I don't know what connections to implementors you have (but you say
>   that you are only guessing about them).  I think It is far more likely 
>   they will listen to the http-wg.  

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?


> - Who are those implemetors (= potential senders of Warning headers)
>   anyway?  For now, I don't think there are many that would even think
>   of making use of more-than-ASCII Warning text.  There isn't much
>   urgency.

Good point. It looks like there is still some time. But it is
better to discuss and solve this sooner than later.


> - 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.

Looks like you are just doing (not only suggesting) something similar
to what I suggested above: Silently change the protocol to something
more reasonable :-).
With all fairness, I think your arguments are sound. But the protocol
says something completely different. It mentionnes all kinds of
considerations for what language to choose. It even goes as far
as mentionning English as the default, as if the arbitrary implementor
couldn't reach the conclusion for him/herself that English has the
best change if there is no indication for something else :-).
The protocol in no way mentionnes the possibility that the warning
text could be missing, and a client implementor not adding it would
not have to be blamed.


> - For all other Warning messages (yet to be defined) you cannot offer 
>   a table now.  (And translating "Miscellaneous warning" into different
>   languages doesn't make much sense, since that is obviously not the
>   text a user is meant to see..)

Agree for the other warnings. But the table could be completed later.
And if there is no use showing the "Miscellaneous warning" to the
user, what is it defined for anyway?


> If you really want to approach implementers (for now, makers/vendors of
> proxies), you might ask them to either hold off creating non-ASCII
> warning text (until the header syntax may be redefined - or not), or 
> to always use 1522 format instead of relying on an 8859-1 default.

Good idea for a start.


Regards,	Martin.

Received on Monday, 16 December 1996 08:05:34 UTC