I have posted an update to the Cloud Requirements and Model document at
(also accessible at http://xxx)
This update reflects comments from the November 18 conference call reviewing Cloud Imaging Requirements and Model ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20131115-rl.pdf.
Extracting from the minutes of that call, actions/comments are in red.
b. Page 28: Still have signal duration listed for Identify Printer - Replaced with IdentifyActions
c. 18.104.22.168: must -> MUST for items 3 and 4 – Reworded to avoid use of conformance terms.
d. 22.214.171.124 IdentifyDevice
Q: Do we want the Cloud Imaging Service to be able to cancel
How to do it with IPP?
‘cancel’ keyword for identify-actions? OK
IIG2: provide guidance on recommended durations, each
identify-printer operation replaces the previous actions (if not
expired), what to do for display (replace, alternate, ???
discuss in IPP WG)
Action: Mike to post adding identify-actions = ‘cancel’ and
‘identifying-printer’ printer-state-reasons to IPP list
e. Global: fix lowercase musts OK
f. Global: check spelling OK
Lines 894-897 should be numbered list OK
Expand a bit on the kinds of notifications that are supplied: jobs are
fetchable, identify device is pending, jobs were canceled, etc. OK
Line 950: end -> cancel, capitalize identify actions OK
Item 4: Include job elements instead of separate UpdateJobState
operation Job State should be adequate
Item 5: IdentifyActions instead of DeviceIdentifyRequest OK
GetSystemNotifications should return basic event information, like IPP Get-Notifications: job state changes include new job state, job UUID, service URI Only include job state changes as indicated. Isn't Job UUID sufficiently unique so that service URI is unnecessary?
o I remain uncomfortable with this change. GetSystemNotify was not intended to parallel IPP Get-Notification. Indeed, I am not overjoyed at the GetSystemNotifications name because it is as much a send system notifications as it is a get system notifications operation. It is directed to System Control Service, not individual imaging services and was intended only to flag to Proxy that Job status should be checked for identified Imaging Services. Communicating Job specific status at the System Control Service level seems inappropriate to me. The need to add this job specific information to the GetSystemNotifify comes from the objection to a Cloud Imaging Service responding with its Job State in response to an Update Job State operation. I am inclined to think that this response is still necessary, although adding GetJobState would be a (cumbersome) alternative.
identify actions include new set of actions OK
h. Table 2:
Add GetJobElements, GetDocumentElements (standard SM
operations) Question need for these if job status changes are now reported in GetSystemNotitications
On another point, considering that the who PJT mapping effort was started as a response to Google Cloud Print using PPDs and MSPS for printer capability and job tickets, I was surprised that there was virtually no interest in considering the current Google Cloud Print documentation as a Cloud WG project. I wonder of this reflects the opinion of just the few work group members who attended the conference call or whether it is consensus among all members.
-------------- next part --------------
An HTML attachment was scrubbed...