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
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
--------------578C7E2551A60BAD272EADE4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id LAA26449; Thu, 9 Oct 1997 11:14:09 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA14278; Thu, 9 Oct 1997 11:14:08 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 9 Oct 1997 11:13:10 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA14144 for ipp-outgoing; Thu, 9 Oct 1997 11:03:14 -0400 (EDT)
Message-ID: <343CF123.E6DCC6A5@sharplabs.com>
Date: Thu, 09 Oct 1997 07:58:44 -0700
From: Randy Turner <rturner@sharplabs.com>
Reply-To: rturner@sharplabs.com
Organization: Sharp Labs of America
X-Mailer: Mozilla 4.02 [en] (Win95; I)
MIME-Version: 1.0
To: Ned Freed <Ned.Freed@innosoft.com>
CC: Larry Masinter <masinter@parc.xerox.com>, ipp@pwg.org
Subject: Re: IPP> Proposal for IPP to meet IESG Language/CharSet requirements
References: <3.0.1.32.19971007180400.010e76b0@garfield>
<3.0.1.32.19971008160920.00c696e0@garfield> <01IOL0HKRCLI9JD7O7@INNOSOFT.COM>
Content-Transfer-Encoding: 7bit
Sender: ipp-owner@pwg.org
Content-Type: text/plain; charset=us-ascii
Ned Freed wrote:
> > 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 that in the "application/octet-stream" case, 99.9% of the clients willnot know the charset, or anything else about the
document(s) to be printed.
>
>
> 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
While I understand the spirit of the comments related to standardization of
"application/octet-stream", it is not our responsibiltiy to enforce absolute
interoperability onto an existing printing environment that inherently has an
interoperability problem. There are a million non-pathological scenarios
wherein a user has an existing file that is to be printed and may or may not
know the format of the file. In my experience with MIME, this has been
how mail clients tag attachments when they're not sure the format of a
particular attachment. This is exactly how we would use
the "application/octet-stream" in the IPP case.
In order to make our use of "application/octet-stream" more palatable to
the IESG, we could use proper wordsmithing to come up with something
I think would work. IPP could not dictate what "application/octet" stream
means to a server that receives such a document, but only say that it is
implementaiton dependent what happens when a server receives such a
document, and maybe provide examples (such as auto-sense). In this
case we're not officially standardizing how "application/octet-stream"
is to be handled by a server, only suggesting. And while this may indeed
present interoperability problems, I think it is worth keeping the use of
"application/octet-stream" at least mentioned in the documents. With
proper wordsmithing, I don't think IPP implementations will use
"application/octet-stream" any different than it is being used today in
the SMTP/MIME world.
Randy
--------------578C7E2551A60BAD272EADE4--