[Cloud] Update to Cloud Requirements and Model

[Cloud] Update to Cloud Requirements and Model

[Cloud] Update to Cloud Requirements and Model

William A Wagner wamwagner at comcast.net
Mon Nov 25 18:46:14 UTC 2013


I have posted an update to the Cloud Requirements and Model document at 

               ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20131125.pdf 

ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20131125.docx

(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. 4.2.1.2: must -> MUST for items 3 and 4 – Reworded to avoid use of  conformance terms.

d. 4.2.1.2 IdentifyDevice

Q: Do we want the Cloud Imaging Service to be able to cancel 

identify operations?

A: Maybe

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

g. 4.2.2.1:

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.

 

Thanks,

Bill Wagner

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


More information about the cloud mailing list