On May 9, 2011, at 2:15 PM, Ira McDonald wrote:
> Hi,
>> 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...
> OR
> (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...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20110509/11c7abee/attachment-0001.html>