attachment-0002
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Randy,<div><br><div><div>On 2013-07-19, at 10:04 PM, Randy Turner <<a href="mailto:rturner@amalfisystems.com">rturner@amalfisystems.com</a>> wrote:</div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://27/"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Hi Bill,</div><div><br></div><div>RE: Item #1 below, starting with "The Device Owner…" , it seems like a complicated interface and sequence of steps that the owner will have to take to register his device for cloud access. If I'm doing one imaging device, it might seem tractable. If I'm doing 20 or 30 heterogeneous devices, it seems excessive. Have we modeled how this might look for an administrator, like what would the UI look like, or what the admin experience would be?</div></div></blockquote><div><br></div>The point here is to define a standard interface so that you can point a printer at a Cloud Imaging Control Service endpoint with credentials for the device owner and it can register whichever services (along with the corresponding device information) that are supported by the Cloud service and allowed by the owner.</div><div><br></div><div>(so the owner might want to register print and scan with a cloud, but if the cloud only supports print then that is all that gets registered...)</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>From Note 1b, I thought registration "caused" a corresponding cloud imaging service to be created? The device registers with some generic (non-specific) imaging cloud service, correct? and then once registered, the "corresponding" service is created. Or at least that's what I thought we were talking about at the last face-to-face.</div></div></blockquote><div><br></div>There was some resistance to requiring a service to be created. Instead, a service may be pre-existing that can be used, so the idea is that the Identify Services operation returns the endpoints that the Proxy uses for its Imaging Device(s). These may be existing services or new ones that are created.</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Also, from your "Note #2 below", It seems reasonable that the "Authorization" part of the cloud service is probably out of scope for the Cloud WG…but you've highlighted some examples of potential predicates for an authorization decision -- if anyone has any ideas regarding the types of authorization decisions that a service might want to make, I would urge the group to pass those along to the IDS team, especially whoever has the ball on a XACML dialect for imaging authorization.</div></blockquote><div><br></div>The idea is that the Cloud controls authorization/AAA for the Cloud Services and the Proxy controls which services along with AAA for the jobs being forwarded to the corresponding Imaging Device services/subunits.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I know that Mike has published the "Paid Extensions" stuff from IPP that uses some type of authorization ticket that says "I've paid for what I'm asking for", but I would hope that this type of authorization would be just another predicate check by a larger, overall authorization engine, and that there would be one (and only one) "Ok, we'll allow this operation" ticket or token that takes into account all authorization decisions (predicates, conditions, etc.)<br></div></div></blockquote><div><br></div></div>What is defined in the IPP Transaction-Based Printing Extensions would sit in the corresponding Cloud Imaging Service, since (right now at least) we don't have an interface between the Cloud Imaging Service and Proxy to relay Validate-Job operations or authorization codes. If there is interest in such an interface, I think it should be developed separately from the main model. There are uses beyond transactions - most of the Validate-Job/Document extensions in IPP provide additional response attributes/elements...</div><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>