Especially when it comes to Print-By-Reference. If you think about it, we
need
new requests added to the model to possibly handle Print-By-Reference. I
think
everyone would agree that the bulk of the documents users are going to want
to print by reference are Web documents, and if our IPP servers are
required to
fetch these documents, then they better be HTTP compliant with regards to
these requests. And if we support HTTP for Print-By-Reference, then we
already have a core HTTP engine implemented (data types, methods, etc.) and
the rationale for straying from using HTTP all but disappears.
If we decide to use HTTP for IPP, then I think we could come up to speed
much
quicker in demonstrating working IPP prototypes, based on standard
technology.
And utilizing persistent connections I think the performance would be
acceptable.
We should in any case add an attribute to the printer object that
identifies the
URL schemes that the IPP service recognizes and supports for use in
Print-By-Reference requests.
On another note, regarding Roger and Keith's latest document for 'SendJob',
I
basically concur with most of what they are proposing. I would however like
the 'document-format' attribute to be optional on SendJob. Most of the
time,
clients would be unable to specify this (at least in initial
implementations). I'm
assuming here that initial implementations will come in the flavor of port
drivers
and not printer drivers.
I'm also not sure whether we need all of the document 'position' indicators
like
first, middle, and only. Seems like all we need is 'last' or some other
'end-of
document' indicator.
Randy