On May 9, 2011, at 2:15 PM, Ira McDonald wrote:
>> Glen - correct me please if I'm all wet here...
>> On reflection, I think Glen's comment at the end of today's Cloud call about
> delayed Design Requirements (in the individual IPP EW or MFD Svc specs),
> was pointing out that our existing specs often have Design Requirements of
> the form:
>> (a) Protocol <abc> must/should support an <xyz> operation...
> (b) Protocol <abc> must/should support a <fgh> feature or property...
>> That is, the target protocol (IPP Everywhere, MFD SOAP, etc.) receives
> the requirement.
and FWIW my plan of attack for the use case whitepaper is to make the design requirements a part of each use case as a subsection. When we actually incorporate a use case into a spec we can collate the design requirements in the form we normally use in that spec.
> Which raises another question. Should the Cloud Imaging Model include
> actual abstract operations (higher-level than current MFD Model spec)?
> - These would get mapped to concrete operations in Cloud Print IPP
> Binding and Cloud Print SOAP Binding.
>> I think the answer should be yes.
Yes, absolutely. The binding documents can then use the name and semantics from the model with the corresponding protocol binding info.
Michael Sweet, Senior Printing System Engineer, PWG Chair
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...