Not sure if the following statements are exactly relevant to this email thread…but the thread touched on some things I've been thinking about.
It's a bit risky to define a complete "cloud" printing model without having an over-arching "imaging" model first -- we might take liberties with the printing model that are too "printing" specific and are not generic enough to be applied to an imaging model -- so I like the idea of making sure that a higher-order set of actors and model objects map with a generic imaging cloud model.
I think the model document should "recognize" that there is authentication and authorization (most likely) in any cloud design that is actually implemented and deployed. However, we don't have to address specifics of AAA in the near term. We would just include AAA components in the model illustrations (the pictures) just to show that we know these would probably exist. But that's it for now.
The IDS group may want to tackle these AAA model "abstractions" and put some meat behind them about how this might work.
By the way, is there anyone still working on a XACML proposal for imaging services ? I think someone was looking into this last year…
I agree with Bill that we shouldn't be talking about device management, except for the transient "setup and configuration" that is implied by any job ticket information that requires a particular (temporary) setup of the rendering device.
R.
On Feb 7, 2013, at 12:29 PM, William A Wagner wrote:
> Larry,
> I was presenting an argument, not necessarily specifying a solution. I would like to have your thinking on why these actors/actions are needed in the model. And I still have the question on whether conditional accesses (service functions accessible depending on time, quantity etc) can reasonably be fully handled by the cloud environment outside for the PWG model. Perhaps user authorization not only limits client access to appropriate Cloud Print Servers, but allows access with some conditional restriction code that is enforced in the client (or in the Cloud Print Server?)
>> I agree that we want the print model to phase well into the general model, but I also would like to understand in what way these actions would apply more to a scan service (or any other imaging service) than to a print service. With respect to administrative/device controls, I think device controls (that is, changing end device configuration) are completely out of scope (unless we want to define a model for Cloud based management of a imaging device.) What constitute Administrative controls is squishy, but I think we need to decide whether administering any of the model components, or providing administrative data from any of the components, is reasonably an objective of the printing, scanning, etc model. Again, I pose this as a question, not a conclusion.
> Thoughts from the list please!
>> Thanks,
> Bill W.
> From: larryupthegrove [mailto:larryupthegrove at comcast.net]
> Sent: Thursday, February 07, 2013 11:53 AM
> To: 'William A Wagner'; cloud at pwg.org> Subject: RE: [Cloud] new actors summary
>> Bill,
> I appreciate your comments. I am trying to think longer term, to include scan operations and administrative/device controls.
>> My concerns about not identifying these tasks and/or owners deals with the acceptance of this standard in the marketplace. In the legacy network environments, imaging tasks are mostly controlled by the operating system vendor and the printer manufacturer. The OS vendor may publish a compatibility document, indicating approval.
>> I am ok with adding these type requirements back into the functional requirements, and adding the exclusions into the design requirements. I think the sale of these cloud imaging solutions may not be enhanced by the fact that only a part of solution is covered by the standards.
>> Larry
>> From: William A Wagner [mailto:wamwagner at comcast.net]
> Sent: Wednesday, February 06, 2013 3:32 PM
> To: 'larryupthegrove'; cloud at pwg.org> Subject: RE: [Cloud] new actors summary
>> Many thanks for these suggestions and the discussion. I think, considering Glen’s argument, that it might be better to start with considering what actors are responsible for these actions rather than defining new actors. For example:
> User access to device and features: Joe suggests that we have already considered this as out of scope for the print model, with questions of user identification and authorization implemented by other aspects of the Cloud Environment. Presumably, by the PWG Cloud Imaging model, the client connection with the Cloud Service establishes what Cloud Print Servers the user can access, and what end services he can use. Therefore, although it may be any one of several actors that is responsible for defining access rights, none of the components of the PWG Model should be defined as responsible for enforcing them; rather it becomes part of the Cloud Environment requirements (functional requirements) and must be clearly stated in those requirements. If this is agreed to, the question to be considered here is conditional access rights…access limited to certain functions, quantities, or times.
>> I would say that authorization or selection of:
> cloud services or connections
> Administrator access to device, logs, and other user controls
> Accounting functions
> Are probably appropriate actions for the administrator of the Print Manager…or maybe someone else. But I don’t think that these are part of the Cloud Printing model. These too are part of the environment and should be included in Functional requirements but I don’t think that we need to define the actor.
>> For the Cloud Service administrator, again I suggest that these configuration operation are all out of scope for the model, although they should be identified in the Function requirements section. And as such, it is not necessary to identify a Cloud Service Administrator actor .
>> Having indicated that I do not think that these actors need be identified, I would ask Larry if he added them since he needed them for the sequence diagrams or other parts of section 4.
>> Thanks,
> Bill W.
> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of larryupthegrove
> Sent: Wednesday, February 06, 2013 12:46 PM
> To: cloud at pwg.org> Subject: [Cloud] new actors summary
>>ftp://ftp.pwg.org/pub/pwg/cloud/white/New Actors.pdf
>ftp://ftp.pwg.org/pub/pwg/cloud/white/New Actors.docx
>> New Actors
> Device Owner – the person(s) or entity responsible for the authorization or selection of:
> 1. Any cloud services or connections (apply to IPP)
> 2. User access to device and features
> 3. Administrator access to device, logs, and other user controls
> 4. Accounting functions
>> Cloud Service Administrator – on behalf of the Device Owner, performs operations to:
> 1. Configures device access controls for use by Cloud Service – should be with
> 2. Configures device for Cloud Print Service access
> 3. Can start, stop , or modify all queues at the cloud service
> 4. Can retrieve any logs from the cloud service
> 5. Accounting configurations
>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean. _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20130207/32c53add/attachment-0002.html>