> From jkm at underscore.com Thu Oct 9 08:56:53 1997
> Date: Thu, 09 Oct 1997 11:28:23 -0400
> From: Jay Martin <jkm at underscore.com>
> To: ipp at pwg.org> CC: rturner at sharplabs.com, Ned Freed <Ned.Freed at innosoft.com>,
> Larry Masinter <masinter at 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