Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/28/97 08:20
AM ---------------------------
Scott wote:
We discussed this at the Wednesday call. The discussion wound up
being a requirements discussion. Which are the following requirements
are part of IPP requirements:
1. Receive all errors and events over a separate channel
from the job submission channel
2. Receive all errors and events over the job submission channel
synchronously (in every response to every request there might be
errors and events that have happened)
3. Receive all errors and events over the job submission channel
asynchronously (some async packet comming back indepented of the
job submission or query requests and responses)
If you realize that IPP allows for events and errors to be reported via our
simple notification attributes over some other channel using some other
mechanism, here is a solution to your scenario from the telecon:
RKD> I would like to see us express requirements from an end-user's point
RKD> of view, not from an implementation or architecture point of view,
RKD> which the above appear to be to me.
RKD> Are there any obvious differences in any of the above schemes as far
RKD> as the end user is concerned? If not, then any of the above will work
RKD> and we should pick the one that then best meets implementation and
RKD> architecture needs.
RKD> Here is one stab at the end-user requirement. Please feel free to
RKD> suggest changes:
RKD> When requesting an IPP operation, an end user always needs to see any
RKD> conditions which affect the outcome of that operation in a reliable
RKD> and timely fashion, and in a way which lets the end user modify or
RKD> cancel the request as appropriate.