After consideration of my latest document, and talking to some folks
(potential IPP users), I believe that HTTP 1.1 would be sufficient to meet
the
requirments of IPP. I was actually thinking that we could possibly go the
route
of being HTTP-like, and kinda filling in with our own special requirements
for
IPP where HTTP failed to meet our expectations. But I don't see any thing
that
we want to do, that HTTP cannot do.
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