Re: Accept-Charset support

On Sun, 8 Dec 1996, Koen Holtman wrote:

> Larry Masinter:
> >
> ># Content-Type: text/html;charset=utf-8
> ># Content-Features: utf-8-cs="<hebrew>" utf-8-cs="<latin-x>"
> >
> >There's no real point to this, though. The text/html;charset=utf8
> >is enough to tell you how to interpret the body, and the body itself
> >will tell you which repertoire(s) are used.          ^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes, it will; but the whole point of entity header fields seems to 
be to have essential metainformation available without/before peeking
into the body.

Attempt to define "essential":  Essential metainformation is
metainformation that enables a client to make decisions about what to do
with the content which have to be made (or should be made) before looking
at the content.  Examples for a Web browser: whether to render, or start
a file save dialog, or invoke an external viewer (and which one).

The example given earlier by Larry Masinter, about a browser understanding
HTML 3.5 tables but not the "border" parameter, would not be about
essential information; it is unlikely that a client has different
rendering processes available to choose from, of which one understands 
"border" and the other does not.

> Yes.  Consider the above a bad example.  I should have written:
> 
>  Accept-Charset: utf-8
>  Accept-Features: utf-8-cs="<hebrew>", utf-8-cs="<latin-x>", *
> 
> because we are really talking about how the user agent can make its
> capabilities known to the server. 

Ok but that character (sub-)repertoire would also be useful ("essential"
in many cases) for non-nogotiating clients.  [Of course you may think
there shouldn't be any non-negotiating clients left, but that probably
will take a while.]

> The content-features header is not really useful.  It is only there for
> symmetry with Accept-Features.  Even if it is present in a response, it is
> not supposed to list all features used by the content, but only the features
> that were negotiated on.  

That would make Content-Features less useful for carrying additional
information in other protocols, e.g. mail.

> You should be able to know which features to use
> by looking at the content itself.

I think charset (sub-)repertoire information should be available without
looking at the content.  That may be less of a concern for monolithic
Web browsers prevalent today.  But the protocol shouldn't be restricted
to that paradigm.

  Klaus

Received on Tuesday, 10 December 1996 09:21:01 UTC