IPP> IPP Requirements Scenarios

IPP> IPP Requirements Scenarios

IPP> IPP Requirements Scenarios

Robert Herriot robert.herriot at Eng.Sun.COM
Fri Jan 17 19:54:22 EST 1997

Great job Roger!

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.

More information about the Ipp mailing list