IPP> Proposal for IPP to meet IESG Language/CharSet requirements

IPP> Proposal for IPP to meet IESG Language/CharSet requirements

IPP> Proposal for IPP to meet IESG Language/CharSet requirements

papowell at astart.com papowell at astart.com
Thu Oct 9 22:09:00 EDT 1997


> 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



More information about the Ipp mailing list