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.