Subject: Re: IPP> IPP Requirements Scenarios

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 17 Jan 1997 10:10:51 PST

At 07:16 AM 1/17/97 PST, you wrote:
>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.
>

I would certainly like to see the referenced file case covered on IPP v1.0.
At least for the cases where no special access rights are required, such as
if the file is open to everybody on the Internet, or if the file is in the
same domain behind a firewall. More complex cases will be dependent on how
much in the way of security we want to provide for IPP v1.0.

Carl-Uno

---

From: [email-masked] (Robert Herriot)
Date: Fri, 17 Jan 1997 16:54:24 -0800

With regard to the conversation below, I have assumed that "more than
one request" refers to sending more than one document in a print
request.  I did not think that it referred to sending multiple operations
in a transmission. Though perhaps, this concept slid in when we
discussed having a "getAttributes" operation accompanying a "printJob"
operation in order to specify attributes to be in the result.  I think that
we should not allow a transaction to have multiple operations.

Bob Herriot 

> > 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.
> 
> 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
>

---

From: [email-masked] (Robert Herriot)
Date: Fri, 17 Jan 1997 16:54:22 -0800

Great job Roger!

I have comments on several of your replies to Jay.

> 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.

---

From: [email-masked]
Date: Mon, 20 Jan 1997 08:36:29 -0500

Classification:
Prologue:
Epilogue:

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/20/97 06:07
AM ---------------------------

        robert.herriot @ Eng.Sun.COM
        01/17/97 09:03 PM

<<RKD>> I agree that we should allow only URL references.

<<RKD>> I believe we should return anything the client asks for
<<RKD>> including printer and job status -- my only point in the
<<RKD>> previous note was some IPP configuations may include
<<RKD>> printers not capable of giving any status. In this case
<<RKD>> no printer status can be returned.  I suppose we probably
<<RKD>> need some way to tell this to a client.

---

From: [email-masked]
Date: Mon, 20 Jan 1997 08:39:40 -0500

Classification:
Prologue:
Epilogue:

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 01/20/97 06:02
AM ---------------------------

To: rturner @ sharplabs.com@internet, Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org@internet
Subject: Re: IPP> IPP Requirements Scenarios

>we should not allow a transaction to have multiple operations.

Bob, the operation I was trying to illustrate in the sceanrio is exactly the
getAttributes operation accompanying a PrintJob operation, which I thought
we had agreed upon. Are you now saying we should not do this???

---

From: [email-masked] (Robert Herriot)
Date: Tue, 21 Jan 1997 18:13:25 -0800

I am ambivalent about having multiple operations in a transaction.  The
protocol we choose may or may not accommodate multiple operations.  If
we decide that multiple operations per transaction is good, we need to
define what they mean.  For example, do they imply some atomicity, or
are they equivalent to the same operations in separate transactions in
sequence?

----- End Included Message -----