Let me first state that I think a protocol along the lines of what Roger
and Keith
are suggesting would work, with some additional "filling out" as they
would
normally do if they were to formally spec. this out in a document. It
does
however bring us back to the decision whether or not to use HTTP or a
completely new protocol.
All of the operations and benefits of the protocol suggested could be
accomplished by tightly coupling IPP semantics to HTTP. The "fleshing
out"
of a formal proposal that details Roger and Keith's design would
(IMHO) duplicate alot of what HTTP is already providing. Not that one
way is any better than the other, but like what was suggested by
someone in an earlier protocol telecon, "Do we want to create
another protocol that is 80-100% semantically equivalent to HTTP?"
I think chunking of a multipart message could be done effectively,
similar to what Steve Zilles and I were discussing at the last telecon,
and the feature of being able to return intermediate status between
"SendDocument" operations could be provided by allowing clients to
send jobs using multiple POST operations.
Like I mentioned earlier, I will have a document that references these
mechanisms, and references how Bob Herriot's proposal would have to
change if we were to be HTTP 1.1 compliant. I will have this document
out by the end of the day (today, Friday).
Randy
Keith_Carter at aussmtp.austin.ibm.com wrote:
>> 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
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com