The cloud portion of the model could be simplified to only a single module
that does everything. I think it would be challenging to follow.
We should make it more clear that the Cloud Print Service, Cloud Print
System Service, and any other components used to help explain the model are
only representations of a possible implementation.
I think that including a representation of some type of database/registry
makes sense, as it could help explain the existence of rules that determine
which users have access, to which printers, which features can be used, and
possibly what printers can register. I'm not sure on calling the Cloud
Print System Service a registry, as I think that conveys static and not
performing actions.
If the sequence drawings can be agreed to so the Cloud-Client and
Cloud-Printer interfaces can proceed, the names in the boxes can be resolved
later.
I don't have any issues with creating drawing(s) that show a more complex
implementation or a simpler implementation to place in the Appendix.
Larry
From: Murdock, Joe [mailto:jmurdock at sharplabs.com]
Sent: Friday, June 08, 2012 2:09 PM
To: Petrie, Glen; larryupthegrove; ptykodi at tykodi.com
Cc: cloud at pwg.org
Subject: RE: [Cloud] Updated Mapping and Model Drafts
I agree. However, the PWG does need to provide more than just a model. We
do need to provide a well-defined standard interface for the CPS, CPSS and
CPM to provide interoperability between vendors, otherwise why are we
bothering? I agree that that interface does not need to be IPP (I'd argue
for a SOAP based model, but that's just me), but since we do have a Semantic
Model that provide all of the pieces we need, we should use what we can of
that.
So,
1) I agree on your example 1, but we do need to define a set of
standard binding. I thing we ultimately need to provide an environment
where each vendor could provide printer and a compatible Cloud Print Manager
(and yes it should be a Cloud Print Manage, not because it necessarily in
the Cloud, but because it's providing Cloud Printing functionality)
2) Example 2 should be perfectly feasible with our model. Nothing
we're proposing prevents that. And if a particular CPS/CPSS/CPP vendor
wants to use proprietary interface between their internal processing
services, fine. But they should still provide a PWG-compatible binding to
either IPP or SOAP/SM and REST/SM
From: Petrie, Glen [mailto:glen.petrie at eitc.epson.com]
Sent: Friday, June 08, 2012 1:34 PM
To: Petrie, Glen; Murdock, Joe; larryupthegrove; ptykodi at tykodi.com
Cc: cloud at pwg.org
Subject: RE: [Cloud] Updated Mapping and Model Drafts
Joe,
As far as the overall generic model is concerned; my hope is that the PWG
can create a very generic model (that is not constrained by any existing PWG
Candidate Standards) and, then, show where and how the PWG Candidate
Standards fulfill (or maybe don't fulfill) each major components and/or
protocol of the solution. Example, the communication between a CPS and the
Print Cloud Manager (really should be called a Printer Manager since it is
not in the Cloud) does not have to IPP ! But, IPP, fulfill the need and it
is easy to show how. Example 2; what if a CPS want all print job processing
to be done in the cloud (SAAS) versus in the at or beyond the Printer
Manager; that should be a possible solution also of the generic PWG Cloud
model. PWG would note that the CPS can be implemented as an IPP print queue
and, again, easy to show how.
Glen
_____
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Petrie, Glen
Sent: Friday, June 08, 2012 1:15 PM
To: Murdock, Joe; larryupthegrove; ptykodi at tykodi.com
Cc: cloud at pwg.org
Subject: RE: [Cloud] Updated Mapping and Model Drafts
Joe,
</
There is nothing to prevent, and actually a lot to recommend/require, a
Cloud Print Provider from supporting multiple Cloud Print System Services,
based on a variety of performance, contractual and legal agreements/reasons.
It is not unusual that a customer's requirement for a cloud service be that
the customer's data never reside on or be processed on a service that does
not reside in a specified country. With a multinational Cloud Print
Provider, this would necessitate they provide multiple Cloud Print System
Services on multiple pieces of physical hardware that resides in multiple
countries).
/>
According to the definition in the model the Cloud Print System Service
(CPSS) "creates Cloud Print Services (CPS) and enumerates CPS available to
authenticated Cloud Print Users".
Thus, you want the Cloud Print Provider (CPP) (the environment) to have
multiple services that create CPS's and can enumerate CPS's; which, if I
follow your use-case, span multiples countries. I don't really understand.
A single CPSS could create the CPS in any country. Your statements states
that the customer's data must be in a specific country; ok! The CPSS does
not possess customer's data, a CPS does (may); where the CPS resides in the
country of interest.
</
In this scenario, a user/company/printer/other service needs to have a well
know endpoint to start with (the Cloud Print Provider), from which it can be
redirect as necessary to the appropriate system service, and ultimately the
proper print service, based on information associated with a user's account.
If we combine the Cloud Print Provider and the Cloud Print System Service
this account-base separation and redirection is no longer possible.
/>
According to the definition in the model the Cloud Print Provider "is the
environment in which the CPSS and CPS's reside. " So from this definition,
there would have to be multiple CPPs; one for each constrained environment.
I actually don't understand your use-case. Any CPP (Epson's, HP's,
Google's, Ford's, etc.) is just the environment (the collection of cloud
print software entities). Assuming it is public in a world wide sense (and
not private where everything is "contained"); then there will always be
single specific world wide entry points for registration, user accounts, and
so forth. It is fairly likely that the entry points processing software
does nothing more than redirect to one of many, many, many Cloud Print
Registry (CPR) that can communicate with each other and share information
(i.e. a user and printer registration data base). (Either for load balancing
or in your case for domain constraint.) Any one of the CPR can instantiate
a CPS and, if necessary, on a specific domain server or in a specific
country.
I believe you are really discussing implementation and deployment details
versus a model.
</
I also don't like the idea of renaming the Cloud Print Provided as the Cloud
Print Registry, as registering a printer is only a small portion of it job.
It does not register a user, rather it authenticates a user account that was
previously setup via a marketing/sale organization.
/>
What does marketing/sales organization have to do with User registration? I
did not go to my or Google's sales or marketing group to register in the
Google Cloud Print (Provider). Or do you associate a User with company.
Example, Ford Motor Company wants an HP Cloud Print; so that sales and
marketing provide the "User" (Ford) with an account (actually, a complete
Cloud Print Solution). I believe the term User means an individual but
could be a group. An indeed a CPR could register Users; that is an
implementation of the Cloud Print Solution.
</
It does not register a Cloud Print System Service, rather it creates one or
more Cloud Print Systems as dictated by the same marketing/sales
organizations (based on customer requirements), with additional input from
an IT organization. It does not even really register a printer, rather it
creates a Cloud-based Printer Service to receive and handle jobs for that
printer
/>
Again, I believe your model is that a Cloud Print System Service is Cloud
Print Bundle that is sold to companies. While, I believe the model,
generically, describes any Cloud Print Solution.
We all understand (at least I hope so) that "Printer registration" implies
creation of a CPS representing the physical (maybe not even a physical)
printer. If the CPSS creates CPS and it does not register the CPS; then
who does. It makes perfect sense that if the CPSS instantiates a CPS it
should register is some data base. And, since, the CPSS (by definition) is
supposed to enumerate CPS for a User; it does have to have access to both a
User data base and CPS data base and association data for both the User and
the collection of CPS's.
glen
_____
From: Murdock, Joe [mailto:jmurdock at sharplabs.com]
Sent: Friday, June 08, 2012 12:21 PM
To: larryupthegrove; ptykodi at tykodi.com; Petrie, Glen
Cc: cloud at pwg.org
Subject: RE: [Cloud] Updated Mapping and Model Drafts
I don't agree with combine the Cloud Print Provider and the Cloud Print
System Service functionality.
There is nothing to prevent, and actually a lot to recommend/require, a
Cloud Print Provider from supporting multiple Cloud Print System Services,
based on a variety of performance, contractual and legal agreements/reasons.
It is not unusual that a customer's requirement for a cloud service be that
the customer's data never reside on or be processed on a service that does
not reside in a specified country. With a multinational Cloud Print
Provider, this would necessitate they provide multiple Cloud Print System
Services on multiple pieces of physical hardware that resides in multiple
countries). In this scenario, a user/company/printer/other service needs to
have a well know endpoint to start with (the Cloud Print Provider), from
which it can be redirect as necessary to the appropriate system service, and
ultimately the proper print service, based on information associated with a
user's account. If we combine the Cloud Print Provider and the Cloud Print
System Service this account-base separation and redirection is no longer
possible.
I also don't like the idea of renaming the Cloud Print Provided as the Cloud
Print Registry, as registering a printer is only a small portion of it job.
It does not register a user, rather it authenticates a user account that was
previously setup via a marketing/sale organization. It does not register a
Cloud Print System Service, rather it creates one or more Cloud Print
Systems as dictated by the same marketing/sales organizations (based on
customer requirements), with additional input from an IT organization. It
does not even really register a printer, rather it creates a Cloud-based
Printer Service to receive and handle jobs for that printer
And yes, of course the term "Printer" in all of these diagrams should really
be read as "Imaging". It may be appropriate to do that now, and just limit
the scope of Imaging to be printing for now.
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
larryupthegrove
Sent: Thursday, June 07, 2012 2:44 PM
To: ptykodi at tykodi.com; 'Petrie, Glen'
Cc: cloud at pwg.org
Subject: RE: [Cloud] Updated Mapping and Model Drafts
Glen raises some interesting points for the next discussion. The challenge
is that the activities in the cloud are provider dependent, so there could
be a wide variety of implementations.
I would like to leave client, but possibly add a cloud print client as part
of the association. Long term I could see cloud print provider becomes
cloud imaging provider, and "print" gets replaced with "scan", "fax", etc.
Then we can reuse a lot of the diagrams and work.
I updated the sequence drawings, adding a Print sequence and an Enumeration
sequence.
ftp://ftp.pwg.org/pub/pwg/cloud/white/Cloud%20Print%20sequence%20drawingsupd
ate20120607.pdf
ftp://ftp.pwg.org/pub/pwg/cloud/white/Cloud%20Print%20sequence%20drawingsupd
ate20120607.vsd
Larry Upthegrove
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org]
<mailto:%5bmailto:cloud-bounces at pwg.org%5d> On Behalf Of Paul Tykodi
Sent: Thursday, June 07, 2012 1:05 PM
To: 'Petrie, Glen'
Cc: cloud at pwg.org
Subject: RE: [Cloud] Updated Mapping and Model Drafts
Hi Glen,
I like your choice of the name registry. I find myself continually getting
confused as to the actual tasks undertaken by some of the components that
live within the Cloud in our current model.
At least for me, the use of the word registry really helped with the
conceptual understanding.
Thanks.
Best Regards,
/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC
Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail: ptykodi at tykodi.com
WWW: <http://www.tykodi.com/> http://www.tykodi.com
From: cloud-bounces at pwgorg [mailto:cloud-bounces at pwg.org]
<mailto:%5bmailto:cloud-bounces at pwg.org%5d> On Behalf Of Petrie, Glen
Sent: Thursday, June 07, 2012 12:05 PM
To: Petrie, Glen; William A Wagner; cloud at pwg.org
Subject: RE: [Cloud] Updated Mapping and Model Drafts
Bill,
In fact, considering the functions of the Cloud Print System Service, the
Cloud Print System Service should be called the Cloud Print Registry. This
is where the User, Print Services, Transforms, etc are registered. It is
the place where User-to-'Print Service' association is done. It is the
place where a lot of the security and access functionality is done (i.e User
login, access token, etc.). Now in the model diagram, the arrow going to
the "cloud-boundary" now go the Cloud Print Registry.
[ I believe using system service in the name here will be a big problem
later when we define an MFD and have the MFD system service.]
Glen
_____
From: Petrie, Glen
Sent: Thursday, June 07, 2012 7:46 AM
To: Petrie, Glen; 'William A Wagner'; 'cloud at pwg.org'
Subject: RE: [Cloud] Updated Mapping and Model Drafts
Bill,
Can the methods of the Cloud Print Provider be moved to the Cloud Print
System Service; thus, leaving the Cloud Print Provider as an environment
(basically, the collection of all Cloud Print entities in a specific cloud
implementation).
Glen
_____
From: Petrie, Glen
Sent: Thursday, June 07, 2012 7:42 AM
To: Petrie, Glen; 'William A Wagner'; 'cloud at pwg.org'
Subject: RE: [Cloud] Updated Mapping and Model Drafts
Bill,
Comment on Cloud Print Provider.
In the current definition, the Cloud Print Provider is defined as an
environment but then it methods. If the Cloud Print Provider provides
methods and can perform operations then it a software entity and not just an
environment.
Glen
_____
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org]
<mailto:%5bmailto:cloud-bounces at pwg.org%5d> On Behalf Of Petrie, Glen
Sent: Thursday, June 07, 2012 7:16 AM
To: William A Wagner; cloud at pwg.org
Subject: RE: [Cloud] Updated Mapping and Model Drafts
Bill,
I was reviewing the definition of the Client and I believe the Client does
not provide the association function. It must be a Cloud entity, such as
the Cloud Provider or the Cloud Print Provider (i.e. Google Cloud Print),
that creates and maintains the association between the User and one or more
Printers (Cloud Print Services). The Client (acting as a proxy for the
User) may or may-not actually display the list of User Associated Printer
Service (i.e. the Client may be an embedded Client).
The Client is the software component that implements the interface between
the User and the Cloud Print Provider to create an Association; and to
enumerate available Cloud Print Services. The Client is also implements the
interface between the User and the selected Cloud Print Service to submit a
Print Job and to query Job and Printer Status.
I would like to suggest the following
The Client is the software proxy implementing an interface between the User
and the Cloud Print Provider for selection of a specific Cloud Print Service
from an enumeration list of User associated Cloud Print Services . The
Client provides an interface for setting job elements which are communicated
with the specific Cloud Print Service The Client obtains and provided the
User with job queries and Printer status.
I would like to also suggest that we name "Client" as "Cloud Print Client"
since this is a specific type of generic Client that provides the interface
specifically between the User and the Cloud Print solution.
Glen
_____
From: cloud-bounces at pwgorg <mailto:cloud-bounces at pwg.org>
[mailto:cloud-bounces at pwg.org] <mailto:%5bmailto:cloud-bounces at pwg.org%5d>
On Behalf Of William A Wagner
Sent: Wednesday, June 06, 2012 7:34 PM
To: cloud at pwg.org
Subject: [Cloud] Updated Mapping and Model Drafts
Interim level, definitely work-in-progress drafts reflecting considerations
during the June face-to-face meeting are posted as follows:
ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmap10-20120604.pdfftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmap10-20120604-rev.pdfftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmap10-20120604-rev.docx
and
ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20120606.pdfftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20120606-rev.pdfftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20120606-rev.docx
Note that un-redlined versions of MS Word documents may be obtained from
redline versions.
Comments are appreciated.
Thanks,
Bill Wagner
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20120608/6d0332c9/attachment-0002.html>