Re: Accept-Charset support

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

I agree that the issue is over what constitutes "essential". However,
the process hasn't been taken to its logical limit. If you have two
different postscript viewers, one of which does a good job with Type 1
fonts and another of which does a good job with Truetype fonts, you
might wish to claim that it is "essential" that you know which class
of fonts are in a postscript document before deciding which external
viewer to invoke. If both of these viewers only deal with Postscript
level 1, but you have a Postscript level 2 printer, then you might
want to claim that it is "essential" to know the postscript level
before deciding whether to attempt to view the document or to save it
to a file and then print it.

In these cases, though, the nature of the fonts used in the document
and the level of Postscript used are not considered "essential",
presumably because the decision is based on a limitation on the
external viewer rather than something intrinsic about the data stream.

With the now freely available Bitstream unicode font and other pieces
of technology being developed for dynamic delivery of fonts, perhaps
we might want to view the inability to view sub-repertoires of 10646
as limitations of particular implementations rather than an intrinsic
property. 

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

The problem is that in general it is impossible to list all of the
features that _might_ be useful. It's for that reason that
'content-features' as a general entity header field, to be sent with
each transmission, doesn't make a lot of sense. I can imagine limiting
its use to exactly those features that were the subject of
negotiation, and only in those cases where there were multiple
renderings available and the features in question characterized the
differences between the renderings.

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

If there's no negotiation, then there's really no decision to be made:
attempt to render the document. Expect the rendering program to fail
gracefully.

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

You need to look at the protocol from the point of view of the
information providers, not the consumers. If providers have multiple
renderings of a single document, then they'll want to convey the
information about how to distinguish the renderings. From this comes
feature negotiation.  However, if a provider has a single rendering,
it's unreasonable to expect that they label the rendering with
anything other than the information that's necessary to interpret the
rendering. That's what is _essential_. Since most documents won't be
labelled with non-essential information (character subrepertoires),
clients will HAVE to be able to cope with documents that don't have
that labelling (look in the body).

I'm not a fan of the 'everything not mandatory is forbidden' school:
we might ALLOW a content-features tag anywhere, and if sub-repertoires
of 10646 are useful feature designations, so be it. I just wouldn't
want to REQUIRE it, or even encourage it.

Larry

Received on Tuesday, 10 December 1996 07:40:21 UTC