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

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

One way to process changes to HTTP/1.1 in preparation for the move
from Proposed to Draft Standard which seems appropriate for anything
that is not a minor editorial difference is that those who wish to see
the change should submit an internet drafts describing the change and
its justification. If we can reach 'rough consensus' in the working
group that the change is justified, then the result can be either
processed as a separate RFC (before the revised HTTP/1.1 is issued) or
merged into the main HTTP/1.1 draft. But having a complete Internet
Draft with a complete proposal is the first step.

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

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

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

Larry

Received on Monday, 16 December 1996 15:07:18 UTC