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.
I agree that PWG needs to create a model. But if an Epson Cloud Print
Solution wants to use Zeta-Zed-92 communication protocol between a CPS
and a CPM who is to know. Both entities can be instantiated by Epson
(or through an Epson service for non-Epson Cloud Print Solutions). The
communication must meet certain conditions but does not have to be IPP.
In my architectural concept, that communication is denoted as a
connection with no constrains/conditions on the CPS/CPM and is not the
thrust of the architecture. The architecture needs to focus on all the
components; i.e. how does a transform service get registered, are
transform service private or public, are transform service (like
printers) associated with Users, what is needed to support print client
in all environments, what is the API between the client and CPS's, how
to support federation of jobs between two Cloud Print Solutions, on and
on; done of which are IPP related but needs standardization. We can
simply state that from the PWG point-of-view the CPS/CPM communication
is IPP and move on to the rest of the Cloud Print Solution. If there is
not interest in the rest of the solution, then we can rename the project
to "IPP for CPS to CPM communication" or "IPP for Cloud".
I have wondered about the interoperability question; what needs to be
interoperable, are the front-ends. That is, how to submit job, job
format and how to get State, Status and Error (SSE).
From a User's point-of-view what else do they need or want.
They want to register themselves and printers they own along with
association of owned and available printers.
>From Google Cloud Print point-of-view what else do they need or want.
They want to provide the user with a mechanism to set attributes for a
print job based on the capabilities of the selected printer
>From Cloud Print Provider point-of-view what else do they need or want.
They want to receive print jobs for a specific printer (CPS), execute
the job and return SSE to the User (or caller for embedded solutions)
A print vendor wants to support all common and agreed upon set of
external (exposed) job, capabilities, SSE APIs. But is the CPS/CPM
communication actually an exposed API?
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)
I not sure yet, but if vendors supplies (instantiates) a CPS with
defined front-end API, then the CPS/CPM communication issue is mute.
For example, Google Cloud Print can request from an Epson Service a CPS
for Model XYZ printer. YES, there is a security question, etc.; but
they are solvable.
I am worried that a printer will have support multiple CPS/CPM
communication protocol!!!!! A big issue, both in cost and complexity,
for print vendors. Right now a network printer has to support GCP
I/F, AirPrint, Microsoft, and others. Next it will be IPP-Everywhere;
and, unless everyone in the world agrees to use IPP-Everywhere, the
print vendor will still have to support multiple I/F's. If print
vendors support the front-end APIs of a CPS, they let their CPS
instantiation determine the communication with individual printers.
That is, I may have a print with a single I/F but different I/F's among
different printers.
And like all other protocol, they change over time.
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
I am not sure that it is feasible; I need to examine how a processed job
in the Cloud is sent, via IPP, to the CPM/Printer.
Glen
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]
<mailto:%5bmailto:cloud-bounces at pwg.org%5d> 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]
<mailto:%5bmailto:jmurdock at sharplabs.com%5d>
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]
<mailto:%5bmailto:cloud-bounces at pwg.org%5d> 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%20drawing
supdate20120607.pdf
ftp://ftp.pwg.org/pub/pwg/cloud/white/Cloud%20Print%20sequence%20drawing
supdate20120607.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 MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner <http://www.mailscanner.info/> , 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/6b77f615/attachment-0002.html>