IPP> IPP Requirements Scenarios

IPP> IPP Requirements Scenarios

IPP> IPP Requirements Scenarios

Randy Turner rturner at sharplabs.com
Fri Jan 17 11:25:56 EST 1997


rdebry at us.ibm.com 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.
> 
> 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



More information about the Ipp mailing list