Subject: IPP> IPP Requirements Scenarios

From: [email-masked]
Date: Fri, 17 Jan 1997 10:16:55 -0500

Classification:
Prologue:
Epilogue:

The following notes are in response to Jay's comments

1) You suggested replacing PUSH and PULL with

     The protocol must support these sources of client print data
      - print data is a file
      - print data is being generated on the fly by an application
      - print data is referenced by a URL

Answer:  don't have a problem in stating the requirement this way. However,
I'm not sure that we want to place getting a referenced file outside of the
scope of IPP v1.0.  I'd like some other comments on this.

2) With respect to the first print job submission scenario you asked,
 "has it been decided that a single IPP transaction can contain more
than one type of request?"
Answer:  Herriot, Isaacson, Hastings and I agreed on this in early
discussions of the first IPP draft.

3) In Scenario #2 should the "Print file" protocol line perhaps say
"Send File" to reduce the semantics?
Answer: Yes

4) You asked whether or not IPP should address correlation of
status from related components.
Answer:  Certainly the protocol must allow for the maximum amount
of information to be returned to the client that is possible.  However, in
many cases this will be an implementation exercise, or not posssible,
depending upon the configurations involved. For example, an IPP
Printer implemented in a server, supporting "vintage" printers, may not
have any means of reporting printer status -- only queue status.

5) You asked about the example of "copies = 1,2,3" in the first get status
scenario.
Answer:  The example was meant to specifically allow only three values
of copies, 1,2, or 3.  I am assuming that an administrator had set up this
printer so that no more than 3 copies of a document could be printed.
You are right, we also have to deal with ranges or open-ended specifications.

6) You commented on the psuedo http in the Listing-all-print-jobs example.
Answer:This is a hold over from the original charts that I plagerized for these
scenarios. I'll get around to fixing it eventually. We will deal with the
specific encoding issues in the "Protocols" rfc.

7) You asked if we needed to denote the difference between a "printer" and
a "spooler".
Answer: I've tried to cover teh case where a Printer does not spool in more
detail in the latest set of scenarios.

Jay, thanks for your comments, they have been helpful.

---

From: Randy Turner <[email-masked]>
Date: Fri, 17 Jan 1997 08:25:56 -0800

> discussions of the first IPP draft.

If you have a protocol wherein multiple operations are specified, each
with
a "state" dependency on the previous operation (meaning that the
sequence of
operations is part of the overall "stateful" request) then this could
complicate
things considerably; meaning, you might have to include some type of
two-phase
commit operation to verify that all of the operations in a particular 
transaction complete or none at all.

This may not have implications now if we have a very limited
transaction/request
set, but we will no doubt be extending this in the future. I'm not sure
why
a single request per transaction would be overly limiting in a first
implementation
of IPP.

Randy