> 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.
I agree.
> 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.
A codeset parameter would also be a possibility.
> 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?
I agree with the logic here as well. But as far as application/octet-stream
goes, I suggest that before any attempt is made to standardize the processing
of this type that some consideration be given to IETF interoperability rules
for standards-track protocols. The IETF doesn't let standards advance with
demonstrable interoperability problems or without multiple interoperable
implementations. And any idea that the addition of a charset parameter is
sufficient to make complete arbitrary binary data renderable, even with the
best auto-detection logic in the world in place, just isn't going to fly.
As such, I strongly recommend that any attempt to standardize handling of
application/octet-stream, either with supplemental information or without, and
either with auto-detection or without, be abandoned. This would be OK as
an informational document or as an experimental one, but not in a standard.
Ned