At 12:05 AM 10/9/97 PDT, Ned Freed wrote:
>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
>
Ned,
FYI, many existing proprietary products successfully supports the
auto-detection feature. It may obviously not always work, but works most of
the time. A scenario where this is very helpful, is if the user gets a file
of some unknown file type e.g. as attachment in a message or found on a web
page and wants to attempt printing it. In another scenario, a user might
know that a file is Postscript, but not whether it is Postscript 1, 2 or 3.
The auto-sensing can often help sort that out once the file arrives at the
printer.
We obviously do not want to make IPP less powerful than existing products
in this respect. It seems to me though, that we should define our own MIME
type for a document file that we want to have auto-sensed.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com