Subject: IPP> MOD: Proposal to improve job submission in IPP 1.0

From: [email-masked]
Date: Fri, 2 May 1997 13:27:24 -0500

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

---

From: Randy Turner <[email-masked]>
Date: Fri, 02 May 1997 11:53:07 -0700

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

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]