IPP Mail Archive: Re: IPP> Re: MOD - RESEND: Proposal for IPP to meet IESG Language and

Re: IPP> Re: MOD - RESEND: Proposal for IPP to meet IESG Language and

Ned Freed (Ned.Freed@innosoft.com)
Thu, 09 Oct 1997 00:05:30 -0700 (PDT)

> > For example, 'application/octet-stream'
> > and 'application/vnd.hp-PCL'. While PCL has an optional instruction
> > inside the document data that specifies the codeset, it is optional,
> > even when the codeset is different from US-ASCII (or HP Roman-8).

> 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

Our website uses cookies on your device to give you the best user experience. By using our website, you agree to the placement of these cookies. To learn more, read our privacy policy. Read Privacy Policy