IPP Mail Archive: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements
Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements
papowell@astart.com
Thu, 9 Oct 1997 19:09:00 -0700 (PDT)
> From jkm@underscore.com Thu Oct 9 08:56:53 1997
> Date: Thu, 09 Oct 1997 11:28:23 -0400
> From: Jay Martin <jkm@underscore.com>
> To: ipp@pwg.org
> CC: rturner@sharplabs.com, Ned Freed <Ned.Freed@innosoft.com>,
> Larry Masinter <masinter@parc.xerox.com>
> Subject: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements
>
> This is a multi-part message in MIME format.
> --------------578C7E2551A60BAD272EADE4
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Randy's comments are right on the mark, IMHO.
>
> The printer industry has been successfully dealing with auto-sensed
> data for quite sometime now. It should make no difference what the
> official MIME type is, whether it be "application/octet-string" or
> "something/go-fish". A rose by any other color, etc...
>
> Perhaps I'm missing something here, but it seems painfully obvious
> to me that we have put a big stake in the ground to support legacy
> printing systems as part of the philosophy/strategy of wide-scale
> IPP deployment. As such, auto-sensing is absolutely mandatory to
> for the interoperable implementations to succeed.
>
> The less baggage we attach to the auto-sense situation, the better.
> It just seems that the rest of the world has long embraced the MIME
> type "application/octet-stream" to be "unknown type, go fish", and
> I don't understand why we can't follow that lead. (Sorry if I'm
> not up on the latest, greatest IETF trends in this area.)
>
> ...jay
>
I agree with this: the application/octet-string is an obvious choice for
"I dunno what this is, but can you print it?"
Patrick Powell