Roger deBry and I want to propose a change to the IPP Model that
delineates job and document boundaries through IPP operations rather than
relying on an underlying protocol to do so. In our opinion, recent email
has indicated that chunking and multi-part MIME will complicate IPP
implementations. We believe using IPP operations will simplify IPP
implementations. We would like to discuss this proposal at the IPP Model
call on Friday, May 2.
Rather than write alot of words at this point, here is an example of
submitting a job with 3 documents. The first document, DOC1, uses
multiple writes to send to the Printer. The second document, DOC2, is a
reference to a URL. The third document, DOC3, can be sent in single
write.
CreateJob (Printer URL, job-template attributes and values)
SendDocument (Job URL, document-name=DOC1, document-part=first,
data-length=500, <data>)
SendDocument (Job URL, document-name=DOC1, document-part=middle,
data-length=500, <data>)
SendDocument (Job URL, document-name=DOC1, document-part=middle,
data-length=500, <data>)
SendDocument (Job URL, document-name=DOC1, document-part=last,
data-length=150, <data>)
SendDocument (Job URL, document-name=DOC2, document-URL=<url>)
SendDocument (Job URL, document-name=DOC3, document-part=only,
data-length=100, <data>)
EndJob (Job URL)
CreateJob is the operation suggested in proposals from Randy Turner and
Bob Herriot. SendDocument and EndJob are new operations.
For SendDocument, the document-part attribute allows an IPP Client to
specify the part of the document data that is being sent as follows:
first = first set of data sent for a document
middle = set 2 to n-1 of data sent for a document
last = last set (n) of data sent for a document
only = only set of data sent for a document
document-part=first must be paired with document-part=end.
document-part=middle is optional but can only be sent after
document-part=first and before document-part=last. document-part=only
can be sent once per document object. document-part=only cannot be sent
between document-part=first and document-part=last.
The benefits of this proposal are as follows:
1. An IPP Server can easily distinguish document boundaries based
on a standard Model operation.
2. An IPP Server can easily distinguish end-of-job based on a standard
Model operation.
3. An IPP Server has the opportunity to respond with status at several
points throughout the transmission of a job (i.e. provide status
in the response to SendDocument and EndJob).
4. The IPP Operations map more easily to APIs that IPP Applications
might use to submit IPP requests.
If the IPP working group agrees with this proposal, then Roger and/or I
will write a more thorough description for the IPP Model spec which the
IPP working group can subsequently review.
Enjoy,
Keith