> > 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