- From: Klaus Weide <kweide@tezcat.com>
- Date: Tue, 10 Dec 1996 01:48:51 -0600 (CST)
- To: Koen Holtman <koen@win.tue.nl>
- cc: www-international@w3.org, http-wg@cuckoo.hpl.hp.com
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 02:48:48 UTC