An Updated draft to the Cloud Imaging Model is posted at :
ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20140305-rl.pdfftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20140305.pdfftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20140305.docx
( also may be retrieved at http:// addresses)
Although (we hope) that this document is nearing prototype status, there are
several question that have arisen, or that I have, that should be addressed.
1. There is a requirement that the Cloud Imaging System maintain a log
in the format of the PWG Common Log Format.
a. Does the Cloud System retain the log or do the individual Cloud
Services?
b. Are the job events and parameters in the PWG Common Log Format Spec
sufficient for a Cloud Service/System?
2. It was requested that DocumentFormatAccepted and CompressionAccepted
be added as optional elements to the FetchDocument operation. The terms are
derived from IPP and do not appear in the Semantic Model. It is understood
that these are "preferred" values, not supported values.
a. Should "preferred" values be added to the Semantic Model?
b. The model requires that the Proxy communicate the significant elements
and values of a local service (Accessible Element Set) to the corresponding
Cloud Service and update them as necessary. Therefore preferred as well as
supported values would be known to the Cloud Service. Why should they be
included in specific FetchDocument requests?
c. Or do we have a misunderstanding or disagreement with respect to
communicating the Accessible Element Set of Local Service capabilities and
description elements to the Cloud Service?
3. The Model description should refer to elements in the Semantic Model,
not IPP.
a. Should the Cloud Model explicitly identify Semantic Model elements to
be included in Operations Requests and Responses? This may require defining
new elements for inclusion in SM3.
b. Is it necessary/desirable to ensure inclusion of elements
corresponding to all IPP SIX attributes in IPP versions of the operations?
(not include a mapping in the document, but certainly generating one in a
worksheet)
4. It was requested that the GetJobElements operation be added to the
Proxy/Cloud interface, presumably to allow the Proxy to maintain a Job Log.
Although the intent of this operation is that same as for the
GetJobElements operation in the Client-Cloud interface, the access policy
restrictions are different. Specifically, for the Proxy interface, the Cloud
Service must deny access if the requested job is not one that that Cloud
Service has provided to the identified Local Service.
a. Are there other potential access restrictions as well for the Proxy
version?
b. Should the Proxy interface version of this operation have a different
name, so that defining the access and potential error response information,
which is different for the proxy version, does not overly complicate the
description of the operation?
We had planned to have the next Cloud conference call on Monday 10 March, at
which time the above issues would be considered as well as review of the
current draft . It was hoped that this would allow a Prototype version of
the draft to be generated. However, Michael will not be able to join this
call, and he has been the major commenter on this draft. Although the
conference call would be constructive if others would like to comment on the
draft, but could not be a conclusive review without Michael. Therefore,
should cancel the March 10 conference call? Regardless, I would very much
appreciate mail list discussion of the draft and the above issues.
Thank You,
Bill Wagner
_____
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140305/f95947b5/attachment.html>