I have comments on several of your replies to Jay.
>
> 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.
Is Jay's suggest eliminating some type of file referencing that is not
a URL? I believe that we do NOT want an IPP server to access print data
via a simple file reference (which is not a URL). This concept is
already in PSIS (XDPA) and it turns out to be a bad idea because the
client can easily pass in a path name that is either inaccessible to a
server or references a different file from what the client intended. I
like the URL file reference because it is unambiguous.
>
> 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.
However, it is the case that BSD protocol does return "printer status"
along with a list of jobs and their attributes. Printer status is
useful in this situation even though it may not fit into the model
in a clean way.
>
> 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.
>
Some people have commented that they like the default being first. I am
not so sure. I can see the case where the order of potential values should
be the same for each printer, but the default is different for each.
HTML solves this problem by having a special tag to mark the default value.