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.