Because of an insufficient number of participants, today’s conference call is cancelled. Since IPP will not be meeting until March 3, we have rescheduled the next Cloud WG meeting to next Monday, February 24. Please review comment resolution and revised text before then. Emailed comments are solicited as well.
Thanks,
Bill Wagner
From: William A Wagner [mailto:wamwagner at comcast.net]
Sent: Monday, February 17, 2014 10:40 AM
To: 'cloud at pwg.org'
Subject: New Draft -Cloud Conference Call at 3PM ET
I have posted an update to the Cloud Imaging Requirements and Model specification at:
ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20140214.pdfftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20140214.docx
Most illustrations have been stored in *.emf format to reduce file size (I may have missed some).
I understand that today may be a holiday for some, but will have the conference call this afternoon as scheduled anyway to get comments on the changes. We may not get everything resolved, but may possibly get a few items out of the way.
Thanks,
Bill Wagner
From: William A Wagner [mailto:wamwagner at comcast.net]
Sent: Friday, February 14, 2014 3:10 PM
To: 'cloud at pwg.org'
Subject: Cloud Conference Call 17 Feb at 3PM ET
There will be a Cloud conference call on Monday 6 January at 3PM EST (Noon PDT).
AUDIO: Phone Bridge
Call-in toll-free number (US/Canada): 1-866-469-3239
Call-in toll number (US/Canada): 1-650-429-3300 (Primary)
Call-in toll number (US/Canada): 1-408-856-9570 (Backup)
Attendee Access Code: *******#
Attendee ID Code: # (empty)
If you need the Attendee Access code, please email me a request.
VIDEO: PWG WebEx.
Topic: IPP/Cloud WG
Date: Every Monday
Time: 3:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 682 763 393
Meeting Password: Printing123
-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ieee-isto.webex.com/ieee-isto/j.php?ED=152699422 <https://ieee-isto.webex.com/ieee-isto/j.php?ED=152699422&UID=1183762542&PW=NYTM5NTNhNjUy&RT=MiMxMQ%3D%3D> &UID=1183762542&PW=NYTM5NTNhNjUy&RT=MiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: Printing123
4. Click "Join".
NOTE that conference uses phone bridge as indicated above, not audio with PWG Webex
To view in other time zones or languages, please click the link:
https://ieee-isto.webex.com/ieee-isto/j.php?ED=152699422 <https://ieee-isto.webex.com/ieee-isto/j.php?ED=152699422&UID=1183762542&PW=NYTM5NTNhNjUy&ORT=MiMxMQ%3D%3D> &UID=1183762542&PW=NYTM5NTNhNjUy&ORT=MiMxMQ%3D%3D
-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ieee-isto.webex.com/ieee-isto/mc
2. On the left navigation bar, click "Support".
To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://ieee-isto.webex.com/ieee-isto/j.php?ED=152699422 <https://ieee-isto.webex.com/ieee-isto/j.php?ED=152699422&UID=1183762542&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAgN0HgWlP05sWLy7lRjCXMtc9FsW9s-XNPklCRd8QoYu&RT=MiMxMQ%3D%3D> &UID=1183762542&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAgN0HgWlP05sWLy7lRjCXMtc9FsW9s-XNPklCRd8QoYu&RT=MiMxMQ%3D%3D
Agenda:
(1) PWG IP Policy and Minute Taker
(2) Approve Cloud minutes from February Face-to-face (ftp://ftp.pwg.org/pub/pwg/cloud/minutes/cloud-f2f-minutes-20140204.pdf)
(3) Review updated Draft (will be posted this weekend) ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20140216.pdf
(4) Consider whether Cloud Imaging Model workgroup should have more projects (e.g., comparison of PWG model to existing Cloud Imaging Services)
Following are review comments from F2F minutes with my actions with regard to text, questions and comments. (Comments are underlined)
Review of Cloud Imaging Model
a. ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20140128.docx
b. Q: How does client discover cloud services? Added paragraphs on this and showed lines on diagram
A: Two ways:
1. Client-side account credentials point to cloud system control
service, and client uses ListAllServices operation to get a list
of available services (similar to CUPS-Get-Printers and
future IPP Get-Printers operation for IPP System Control
Service spec)
2. LDAP/DNS-SD/etc. discovery protocols for public services
(e.g. hotel managed printing services)
c. Q: Does the IDS group deal with client/proxy association/registration issues? No effect
A: Yes, that will be one of the items addressed by IDS
d. Q: Do we assume proxy can register with multiple cloud services?
A: Yes Fanout instance included see (comment 'i')
e. Q: Any kind of financial elements with proxy interface?
A: No, that is external to the model (i.e. there is a pre-existing business relationship that enables registration) no effect
f. Section 4.1.2.1: changes made
Line 727: "The proxy also periodically queries ..."
Line 728: "to check for waiting jobs" (drop "notification of")
Lines 729-734: Move "A failure to ..." after following paragraph, "failure to receive a query from the Proxy".
g. Section 4.1.2.2:
owner == Local Imaging System Owner changes made
h. Q: What about conformance requirements? no effect
A: Pretty loose for the model spec, binding specs will have the
usual SHOULD, MUST, etc.
Historically, MFD Model had conformance requirements for
operations and elements, but interoperability requirements tend to
just be in the binding specs (e.g. IPP)
i. Section 4.1.4: Changes made to text and diagram
⁃device -> equipment
May have one proxy talking to multiple Cloud Imaging Services of the same or different types.
j. Figure 4:Show one Proxy talking to multiple Cloud Imaging Services -changes made
k. Q: Can multiple proxies be chained? no effect
A: Conceptually yes. Fanout allows both direct (traditional Semantic Model/IPP interface) and indirect (the Proxy interface in the Cloud Imaging Model) usage, and this can be daisy-chained as needed. Question this. Proxy can interface with service which interfaces with downstream service, and conceivably proxy can interface with service that interfaces with proxy...but what would be the purpose?
l. Q: What about poll delays/responsiveness? Isn't directly talking to printer faster? no effect
A: Bindings will likely provide long-running "get" operations - you "poll" to wait for notifications, response comes as soon as event is available
Talking directly *is* faster, however the purpose of this model is to enable imaging when the client is unable to create a direct connection to the service due to firewall or other network restrictions
m. Section 4.2.1.2:
Yes, we need to be able to target a device to conform to SM/IPP fan-out
May change name/terminology here to follow SM ? No effect
n. Section 4.2.2, item 5:
Q: How to represent capabilities for multiple devices?
A: No way to report separate device capabilities as a single Local service
Solution: register multiple Local services, one per device
Solution: construct constraints that prevent combinations that are not supported (e.g. color, duplex, tabloid not supported by any one device)
Talk about implementation choice WRT intersection (only the common capabilities) vs. union (all capabilities) vs. separate local services - Don't understand the problem. Proxy will provide composite of capabilities and status as though there were a single service. Jobs will be directed to appropriate local service by proxy. User and Cloud service do not know nor care which specific local service is being used.
o. Section 4.2.2.3:
Q: What about race conditions, e.g. two proxies fetching the same job?
A: While we don't talk about it here, in IPPSIX we use a "first proxy to fetch wins" approach, with the other proxy getting a "not fetchable" error . Answer is reasonable, but why would Cloud System provide same job to multiple proxies? Presumably User has selected desired endpoint.
Add paragraph, "If the Job is no longer available to be fetched, an error is returned" (the model requires bindings to handle concurrency issues). Comment added. Indeed , general error comment added to assumptions
p. Section 4.2.2.9
Don't want best effort for registration, if everything isn't OK then the response is an error with a list of elements that are not supported - It was my intent that the Cloud Service did not have to accept all the features of the Local Service that the proxy reported as available. (Just as the Local service did not need to make all of its featuires accessable)
("I can't do scan") or missing ("I need your geo-location"). Obviously, errors will be provided in response to incomplete or erronious requests, and .text modified to reflect this. But I suggest that first example is unreasonable. Proxy will contact Cloud Imaging service specified by Cloud System Control Service for each local service the Proxy has listed for a Local System. Contacting the wrong Cloud Service would seem unlikely.
OK to ignore proxy info that the cloud doesn't care about (e.g. geo-location), do we need to report it? Yes, it is dsirable so that proxy does not need to update undesired info. I believe this is covered - is it necessary to make this process clearer?
IPP has successful-ok-ignored-or-substituted-attributes status code
What about reporting mobile printer geo-location in a moving car?
Might be useful to report attributes/elements that are not required (don't tell me about your geo-location) Yes , this was intent.
q. Section 4.2.2.11:
Should not allow proxy to deregister permanently, that is something you do through the cloud-specific interface, just like the initial setup prior to register. Assume request is to change de-register to suspend registration. This, at least, is necessary.
Q: Do we even need/want the operation?
A: Yes, because one proxy can register multiple systems
r. Section 4.2.2.13
Response is just success or error (document not found, etc.) No change
s. Section 4.2.2.13/4.2.2.14:
Q: Should we combine UpdateJobStatus and UpdateActiveJobs, to make a single UpdateJobs operation to update 1 to N jobs in one step?
A: No, see below
UpdateActiveJobs response, in all cases, returns list of job IDs and their updated states in the Cloud Imaging Service
New "invalid" job state for jobs that are not fetched or do not exist Question if this is optimum response. Why not just error message and list of fetched but cloud terminated jobs? Analogous to UpdateServiceElements, where response is error message with rejected or unwanted elements.
t. Section 4.2.2.15:
Eliminate GetCloudTerminatedJobs. OK, Function is now implicit in UpdateActiveJobs response.
u. GetServiceNotifications:
JobTerminated: Add list of terminated jobs and their states. OK.
v. Figure 5:
Add a second set of GetServiceNotifications requests after the responses OK
w. Figure 5:
Q: Can job states persist across re-registration?
A: Assume they can (not necessarily, but they could) and that the Proxy still does an UpdateActiveJobs to discover the fate of the old jobs. Cloud would move existing jobs to fetchable when the proxy doesn't include them in UpdateActiveJobs, as it does with any UpdateActiveJobs operation. - No Text Change
x. Figure 6:
Drop GetCloudTerminatedJobs OK
y. Figure 9:
Drop GetCloudTerminatedJobs OK
Add GetJobElements operation OK - understood that this is to allow optional Proxy record-keeping on Job activity and resolution.
GetServiceNotification includes No longer just a JobTerminated flag - includes job Id.
Thanks,
Bill Wagner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140217/c1155595/attachment.html>