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