Hi Michael,
Point taken about the SHOULD and SHOULD not.
Print data streams that are not MIME registered are a serious
problem for interworking - the vendors should be registering
them.
Lastly, I think that a Printer object CANNOT only support
'application/octet-stream' - because the formats actually
decoded for 'application/octet-stream' PDL detection are
supposed to be a (subset of) the explicit formats listed
in 'document-format-supported' attribute. If a Printer
object lists only 'application/octet-stream' then interworking
is guaranteed never to work.
Cheers,
- Ira McDonald
-----Original Message-----
From: Michael Sweet [mailto:mike@easysw.com]
Sent: Thursday, March 30, 2000 8:07 AM
To: McDonald, Ira
Cc: 'harryl@us.ibm.com'; Hastings, Tom N; anthony.porter@computer.org;
ipp@pwg.org; venky@teil.soft.net
Subject: Re: IPP> Document-format attribute.. [ipp-mod] clarification
"McDonald, Ira" wrote:
>
> Hi folks,
>
> I agree with Harry that we should further revise this paragraph
> to indicate that a client MUST specify a particular document
> format when known and MUST NOT use 'application/octet-stream'
> instead.
Um, that probably won't work too well, since many printer-specific
data streams do not have registered MIME types (e.g. Canon, ALPS,
EPSON, Lexmark, etc.), and a generic print server (e.g. JetDirect,
Axis print server, etc.) probably won't know enough to be able to
enumerate the supported MIME types for the actual device.
SHOULD and SHOULD NOT are probably more appropriate if we are
trying to "encourage" rather than "enforce".
Also, the application/octet-stream information should probably be
updated to reflect a special case for printer objects that list
only application/octet-stream for document-format-supported.
That is, if a client knows the MIME type but the printer object
only supports application/octet-stream, then the printer object
is just acting as a "dumb" printer buffer and the client must
only use the default document format or pass
application/octet-stream.
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Thu Mar 30 2000 - 12:30:32 EST