Subject: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements

From: [email-masked]
Date: Thu, 9 Oct 1997 19:09:00 -0700 (PDT)

> From [email-masked] Thu Oct  9 08:56:53 1997
> Date: Thu, 09 Oct 1997 11:28:23 -0400
> From: Jay Martin <[email-masked]>
> To: [email-masked]
> CC: [email-masked], Ned Freed <[email-masked]>,
>         Larry Masinter <[email-masked]>
> 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