HTTP "Warning" (was: Charset support)

On Tue, 17 Dec 1996, Martin J. Duerst wrote:
> 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.

It was not meant as a proposal, but rather a prediction what might
happen.  Proxies continue sending English text, clients take over
localization of those well-defined messages.

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

There are five where "the number is the message".  The description
for 99 reads "The warning text may include arbitrary information to be
presented to a human user, or logged", so in that case the real
information would be in the warning text - not just the words "Misc.
Warning."
 
> > # 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.

RFC1522 encoding is yucky.  There are length restrictions that seem
arbitrary for HTTP and make no sense there - from RFC2047: "An
'encoded-word' may not be more than 75 characters long..."  "... each
line of a header field that contains one or more 'encoded-word's is
limited to 76 characters."  There is a rule that whitespace between 
encoded-words is insignificant, but not between an encoded-word and
a normal word.

The HTTP 1.1 sentence "If a character set other than ISO-8859-1 is used, 
it MUST be encoded in the warn-text using the method described in 
RFC 1522."  doesn't talk about *how* the RFC 1522 method has to be applied,
so it seems all the arcane rules from (now) RCF2047 have to be applied.

There is also an inconsistency between HTTP 1.1 and RFC 1522/2047 which
makes HTTP's use of the method not-really-1522 - see
 <http://www-uk.hpl.hp.com/people/ange/archives/http-wg-archive/1671.html>
and
 <http://www-uk.hpl.hp.com/people/ange/archives/http-wg-archive/1676.html>.
(I didn't follow up on that exchange then.)  Does the "moving target of 
MIME" (from Roy Fieldings's response) still apply?

Another insufficiency of the current warning header hasn't been mentioned:
the suggested heuristics for a clients selecting between several warning
headers include (14.45)
  o  Warnings in the user's preferred character set take priority over
     warnings in other character sets but with identical warn-codes and
     warn-agents.
But there is not way to flag the language.  So a client program in general
has no way to know whether the text of a given message is comprehensible
by the user.
 
My conclusion:  It is very likely that nobody will implement Warning+1522
anytime soon.  It has been stated (severl time, I believe) that when
HTTP advances to Draft Standard, every feature which doesn't have two
interoperable implementations will have to be dropped.  So maybe that
is the way Warning+1522 will be resolved...  

   Klaus

PS. A precedent for iso-8859-1 in TEXT:
    www.alis.com returns response "404 Pas trouvé".

Received on Tuesday, 17 December 1996 12:40:20 UTC