For 'application/vnd.hp-PCL': if it is necessary to know the codeset
in order to properly interpret application/vnd.hp-pcl, then the
definition of application/vnd.hp-pcl is deficient. If you can't
convince HP to fix their registration, you could register an
alternative value. It may well be that the range of available
'codeset' for some printer types is different than the range
of registered Internet 'charset' values; after all, 'charset'
combines both the coded character set and the encoding scheme,
while some printer languages may employ a different mechanism
for mapping between embedded integers and visual representations.
For 'application/octet-stream': either this is for auto-detection
or it is not. If the sender knows enough about the sender's environment
to determine what 'charset' is used, shouldn't the sender also
know what document format is actually used? Under what circumstances
would one be known and not the other?
As for the discussion on Accept headers: it seems riskier to
layer on top of HTTP but then to declare that you're ignoring
some of the features. Presumably you're going to go through
proxy gateways and other HTTP-munging intermediaries, and if
so, it's very risky to claim that you're changing the semantics.
I'm not sure why you're focusing on the 'accept headers' here,
but not also supplying advice for any other HTTP header. Do you
support etags? COntent-ID? etc. etc. Accept headers are merely
advisory as it stands, and you're not adding any additional
requirements nor are you removing them. So why say anything
at all?
> We thought it was simpler to avoid the complexity of accept headers.
> What we have is complicated enough.
People are hoping to avoid complexity by reusing existing
HTTP implementations, and so any *change* from HTTP adds
complexity.
If you want to point out that Accept headers have no special
significance in IPP, and will likely be ignored by IPP printers,
well, that's fine. Accept headers are ONLY for client to
server, and the content negotiation you need for IPP is
for server to client, so they don't apply, anyway.
It would be great to extend HTTP to allow for reverse content
negotiation (e.g., for POST or PUT) but that's some other
work that will likely be ongoing.
We're trying to put together a separate working group on
'content negotiation' more generally; perhaps there will
be something done in time for IPP version 2, future versions
of HTTP, fax, etc.
Larry
-- http://www.parc.xerox.com/masinter