[Cloud] workgroup last call - updated draft

[Cloud] workgroup last call - updated draft

William A Wagner wamwagner at comcast.net
Mon Dec 22 04:43:41 UTC 2014

Seasons Greetings!

I have posted a new draft of the Cloud Model specfiication at:




This draft is for workgroup last call, with comments to be addressed at
January 12 Cloud Conference call. After resolution of workgroup comments,
updated draft will be put into PWG Last Call to overlap with the February
Face-to-face meetings.


This posted draft addresses comments from the December 15 conference call
and from a listing of editorial comments from Michael Sweet (many thanks for
the detailed review). Several issues are still up for discussion and they
are noted as comments in the above cited draft.


Michaels comments were, for the most part accepted. A few that were not are
listed below with my reasons. These are open to discussion by the workgroup.
(Line numbers refer to December 8 draft.)


- Section 2.2:   - Cloud Computing: spaces before "a". <WW> This is a direct
quote and I believe an ellipsis  is the correct way of indicating that there
is unrepresented text in the original.<WW>


-Section 3.2.3: Is this in-scope? FaxModem in Cloud and scanner in MFD? <WW>
This is an example of a possible use case.  Indeed, it seems one of the few
configurations of Cloud support of FaxOut. I see no reason why it should not
be a valid use case. <WW>


- Section 3.3.2:   Isn't selection of an alternate imaging service (moving
the job) out of scope. <WW> This is something that a Cloud Imaging Service
could reasonably do when the originally selected local service is unusable,
in certain configurations. I see no reason why it should not be a valid use


-Section 3.5.2:- Line 623-624: logging "selected Cloud Imaging Service"
(drop Local Imaging Service) <WW> Isn't the Local service operating on a job
a significant thing to log?<WW>


- Section Line 847:  With respect to the advantages of
asynchronous notification, which is alluded to but not specified in this
model,  do we want to mention long/blocking poll operations? <WW>Some
reasonable advantages of asynchronous notification are given. It is unclear
to me that the specified polling would necessarily be long or blocking.<WW>


- Section  - Line 856: "synchronization" instead of "synchronism"?
<WW> I suggest that synchronism is the state and synchronization is the
process by which synchronism is achieved. So I thing that "synchronism" is
appropriate here.<WW>

- Section   - Lines 871-873: Jobs can't go from "processing" to
"pending", but they might go from processing to processing-stopped <WW>
Correct. Furthermore, since loss of communication is determined by the
Proxy, Job state change in the Local Service should follow what can be done
by an outside client. Table added.<WW>


- Section Table 3: Add DeregisterService operation?<WW> No, Local
Services are not registered. If a service in a Local System is to be removed
with respect to a Cloud System, the Local System  is re--registered without
the subject service.<WW>

- Section  - Line 1463-1472: Why the numbers in parenthesis?
<WW> These are intended to represent numerical coding  value of
IdentifyActions element. Perhaps this is  too much detail?


- Global: settle on consistent term for  "document data", "Document Data",
"DocumentData", or "Digital Data". <WW> Text is adjusted as follows.
DocumentData is used when referring to the Semantic Model Element in a
operation. Document Data is used  when generally referring to the data
stream defining a Document, and defined in the terminology section. "digital
data" is used when  referring to that form of data, which may or may not be
Document Data.<WW>


Many thanks to all.

Bill Wagner







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20141221/acdd4fb4/attachment.html>

More information about the cloud mailing list