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

On Fri, 13 Dec 1996, Martin J. Duerst wrote:
[ lots snipped ]
> 
> Anyway, with regards to warnings, I have a little proposal:
> 
> Let's collect a list of those six warings in the draft, in many
> languages, e.g. in the form:
> 
> en.10	Response is stale
> de.14	Umwandlung angewentet
> 
> and so on. An inital file with English and German (not yet really
> perfect) is available as:
> 
> ftp://www.ifi.unizh.ch/pub/multilingual/http.warnings.utf8
> 
> Any improvements or additions are highly wellcome, just send
> them to me and I'll integrate them. To start, you can get
> the file with English only (still in utf8, but also in ASCII)
> as:
> 
> ftp://www.ifi.unizh.ch/pub/multilingual/http.warnings.ascii
> 
> It's only six short messages at the moment, so translation
> is done very quickly. For submission, you don't
> need to use utf8, I can integrate quite a few things.
> And of course I have an editor that can handle UTF-8 :-).
> 
> 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.  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.

Trying to convince potential implementors to not only ignore the spec
but implement something imcompatible with it looks (to say it kindly)
like an irrational move.  It's not going to win you many friends in 
http-wg :-\ (nor among the potential implementors, I suspect), and will
just create (or strengthen) the impression that those rabid i18n folks
will disregard any protocol when it fits them...

Besides, It won't work..

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

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

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

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

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.

> Lets make the internet principles of implementation priority
> and independet creativity work for decent and non-antiquated
> internationalization.

As an author of I-Ds yourself, whould you like your specifications to
be implemented with this kind of pick-and-choose independent creativity?


  Klaus

Received on Sunday, 15 December 1996 14:49:33 UTC