Subject: [IPP] Where is the Cloud Print Manager in the PWG: Cloud Model

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 6 Apr 2012 08:34:36 -0700

Ira, Pete,

I believe it was stated in the last conference call that the Cloud Print
Manager in the cloud model diagram "is not in the cloud".   Is this
true?  If so, where is it "located"?  

Glen

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Fri, 06 Apr 2012 09:00:26 -0700

[Adding [email-masked] since this is a cloud discussion]

Glen,

In the original BOF-generated functional model, the Cloud Print Manager is either located in the Printer or attached to the Printer (e.g. in the local print server).  The Cloud Print Manager manages communications between the lower-level printer interface and the Cloud Print Provider.

Based on our last telecon, we have introduced a Cloud Print Service into the model which is the service in/under the Cloud Print Provider (which acts as a System Control Service in the Semantic Model sense) that manages the jobs/queue in the cloud for the Cloud Print Manager.  The rough ASCII art diagram in my mind looks like this:

                   Cloud Print Provider
    Client  <--->  Cloud Print Service  <--->  Cloud Print Manager <---> Printer(s)

Thus, Clients and Cloud Print Managers talk directly to the Cloud Print Provider and corresponding Cloud Print Service, but never directly to each other, and only the Cloud Print Manager actually talks directly with the Printer(s) (physical or logical) it is registering/sharing with the Cloud Print Provider/Service.

There can potentially be multiple logical or physical printers behind the Cloud Print Manager (think traditional fan-out configurations and reprographic services) and those printers *may* be addressable using the IPP/SM output device attributes/elements, but there is only a single Cloud Print Service per Cloud Print Manager and to the Client it will appear to be a single "queue" with one or more output devices associated with it.

On Apr 6, 2012, at 8:34 AM, "Petrie, Glen" <[email-masked]> wrote:

> Ira, Pete,
>  
> I believe it was stated in the last conference call that the Cloud Print Manager in the cloud model diagram “is not in the cloud”.   Is this true?  If so, where is it “located”? 
>  
> Glen
>  
> 
> -- 
> believed to be clean. _______________________________________________
> ipp mailing list
> [email-masked]

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 6 Apr 2012 10:34:40 -0700

Mike,

Thanks for the update.   I was reviewing the diagram again and I had
noted there was no actual print entity "in the cloud"; that is, as an
SAAS in cloud terminology; so adding the Cloud Print Service at least
provides a cloud print SAAS.

Some more discussion ----------

I am still having a problem with the use of a Cloud Print Manager (in
the printer) concept (an the name) in the general context of being a
cloud citizen and with associating a User with an individual Print
Service (Printers).  That is, it is not modeled from User's, use-case or
Cloud Provider developers' point of view.  As currently defined, the
current Cloud Print Manager is an artifact of a particular
implementation (like DocuPrint; maybe even CUPS) for a fan out with a
single controller (Print Servcie?); from a reference model or
architecture point of view it should not matter if there is such an
entity providing this function.  This means your simple diagram reduces
to 

                         Cloud Print Provider

    Client  <--->  Cloud Print Service <---> Printer

With """"""maybe""""" the Printer = [ Cloud Print Manager <--->
Printer(s) ]  as seen from Cloud Print Provider

Actually, I see no reason to add the Print qualifier to the Provider;
that is,

                             Cloud Provider

    Client  <--->  Cloud Print Service <---> Printer

This model states that a Client, as a proxy for the User, can access a
Print Service, of the User's Cloud Provider, to print to a User's
register print device. 

This model can be used to represent several different solutions or
implementations:

1.	The "Cloud Provider" is Print Cloud (like HP's or Epson's or)

                          Print Cloud Provider

    Client  <--->  Cloud Print Service <---> Printer

	a.	A good and bad model - requires other Cloud Solution to
federate with Print Cloud Provider.   This would be a big development
effort for print vendors. 

2.	Cloud Print Services are integrated into a Cloud Provider like
Google Cloud

                             Cloud Provider

    Client  <--->  Cloud Print Service <---> Printer

	a.	Again, good and bad.   Good for print vendor in that the
Cloud Provider manages Print Service; bad for the same reason.

3.	The Cloud Print Service is a "mini-cloud" or a "plug-in cloud"
(but still in the Cloud) that is callable by a Cloud Provider. 

                             Cloud Provider

    Client  <--->    \             \           

                              \            \

  \ Cloud Print Service <---> Printer

Where there is cloud around both Cloud Print and Cloud Print Service

	a.	Yes, this looks like model in the current specification
but with some slight differences.

                                                               i.
The Cloud Print Services are in the cloud; thus, they are cloud SAAS 

1.      Yes, the Print Service could be in the physical printer but
virtually linked ("registered") in the Cloud

                                                             ii.      A
printer is associated with a single Cloud Print Service

1.      From the User's and the Cloud Provider's point-of-view, one
Print Service is associated with one Printer.   The User and Cloud
Provider developers never know about fan-out, fin-in, fan-up, fan-down
or any kind of fan; they know there an associated Print Services for a
specific Printer.  

a.       Internally, an individual "Print Service" can support 2,
700,039 Printers; that is something the print vendor does as part of
their implementation detail.   It will not affect the API's the Cloud
Provider developers uses to print to the printer.  And has nothing to do
with the PWG Cloud Print specification.

2.      From the User's and the Cloud Provider's point-of-view, one
Print Service (associated with one Printer) has its own queue.   

a.       If a print vendor wants to have individual queues (the "bucket"
of Print Jobs) for each printer or have one giant queue (a big "bucket")
that individual printers pull jobs from, this again, is a print vendor
implementation detail.   And has nothing to do with the PWG Cloud Print
specification.

                                                           iii.
From the Cloud Provider's point-of-view, the above definitions makes all
Cloud Print Service interfaces look the same; that it,

1.      An individual Printer is registered and has an associated a
single Print Service

2.      The Cloud Provider only talks to the Printer's Print Service for
all APIs and actions. 

3.      Print Jobs are submitted to the Print Service for the target
printer (no matter how the queue is implemented)

                                                           iv.
Thus, the goal of the PWG Cloud activity is to define the API's and data
for the Cloud Provider to/from a Cloud Print Service

1.      I know - use IPP

a.       I don't think IPP will be used by everyone.   (Who is using it
now for Cloud?)  What "will be used" is the PWG:PJT, which does not
require IPP to be useful.   PWG:PJT make federation of the Print Jobs
very simple.  In general PWG:PJT is a perfect candidate for cloud print.

So the final model is something like

                             Cloud Provider                    |-------
a Directory/Registry of Vendor Print Clouds

    Client  <--->    \             \ < -------------------- register
Printers (and its Print Service) to a User 

                              \            \

                                      \ Vendor M Print Cloud
\ Vendor N Print Cloud

                                                Print Service <--->
Printer                                            Print Service <--->
Printer

                                                Print Service <--->
Printer                                            Print Service <--->
Printer

                                                Print Service <--->
Printer                                            Print Service <--->
Printer

                                                Print Service <--->
Printer                                            Print Service <--->
Printer

                                                Print Service <--->
Printer                                            Print Service <--->
Printer

                                                Print Service <--->
Printer                                            Print Service <--->
Printer

glen

 

________________________________

From: Michael Sweet [mailto:[email-masked]] 
Sent: Friday, April 06, 2012 9:00 AM
To: Petrie, Glen
Cc: Peter Zehler; Ira Mcdonald; [email-masked]; [email-masked]
Subject: Re: [IPP] Where is the Cloud Print Manager in the PWG: Cloud
Model

Glen,

In the original BOF-generated functional model, the Cloud Print Manager
is either located in the Printer or attached to the Printer (e.g. in the
local print server).  The Cloud Print Manager manages communications
between the lower-level printer interface and the Cloud Print Provider.

Based on our last telecon, we have introduced a Cloud Print Service into
the model which is the service in/under the Cloud Print Provider (which
acts as a System Control Service in the Semantic Model sense) that
manages the jobs/queue in the cloud for the Cloud Print Manager.  The
rough ASCII art diagram in my mind looks like this:

                   Cloud Print Provider

    Client  <--->  Cloud Print Service  <--->  Cloud Print Manager <--->
Printer(s)

Thus, Clients and Cloud Print Managers talk directly to the Cloud Print
Provider and corresponding Cloud Print Service, but never directly to
each other, and only the Cloud Print Manager actually talks directly
with the Printer(s) (physical or logical) it is registering/sharing with
the Cloud Print Provider/Service.

There can potentially be multiple logical or physical printers behind
the Cloud Print Manager (think traditional fan-out configurations and
reprographic services) and those printers *may* be addressable using the
IPP/SM output device attributes/elements, but there is only a single
Cloud Print Service per Cloud Print Manager and to the Client it will
appear to be a single "queue" with one or more output devices associated
with it.

On Apr 6, 2012, at 8:34 AM, "Petrie, Glen" <[email-masked]>
wrote:

Ira, Pete,

Glen

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. _______________________________________________
ipp mailing list
[email-masked] <mailto:[email-masked]> 
https://www.pwg.org/mailman/listinfo/ipp
<https://www.pwg.org/mailman/listinfo/ipp>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 06 Apr 2012 10:50:35 -0700

Glen,

On Apr 6, 2012, at 10:34 AM, "Petrie, Glen" <[email-masked]> wrote:
> ...
> single controller (Print Servcie?); from a reference model or architecture point of view it should not matter if there is such an entity providing this function.  This means your simple diagram reduces to
>  
>  
>                          Cloud Print Provider

I would be OK with this as long as we clarify in the terminology/model discussion that Printer can be Physical or Logical printer (like IPP/SM) and then provide an explicit example/use case where a Logical Printer acts as the interface with the Cloud Print Provider for an existing Physical Printer.  This addresses the canonical "printer proxy" configuration that is used for Google Cloud Print and other cloud printing solutions and preserves our ability to hand-wave the implementation details between the proxy/manager and physical printer.

---

From: "larryupthegrove" <[email-masked]>
Date: Fri, 6 Apr 2012 13:19:18 -0700

Glen,

I'm struggling with a number of statements, I agree the connection between
the user and the cloud is one part of the model, and the other part is the
connection of the cloud to a logical print something or other (within my
system).   Since the model started as an imaging model, I believe the cloud
to print connection should also be usable for a scan to cloud, with
different elements.

As a user and implementer I'm focusing on where the connection to the cloud
originates, and where the connection from the cloud is terminates.

So where you have in the last drawing - Vendor M and Vendor N, are those
print services from different print vendors or?

Larry

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Petrie, Glen
Sent: Friday, April 06, 2012 10:35 AM
To: Michael Sweet
Cc: [email-masked]; [email-masked]
Subject: [Cloud] RE: [IPP] Where is the Cloud Print Manager in the PWG:
Cloud Model

Mike,

Thanks for the update.   I was reviewing the diagram again and I had noted
there was no actual print entity "in the cloud"; that is, as an SAAS in
cloud terminology; so adding the Cloud Print Service at least provides a
cloud print SAAS.

I am still having a problem with the use of a Cloud Print Manager (in the
printer) concept (an the name) in the general context of being a cloud
citizen and with associating a User with an individual Print Service
(Printers).  That is, it is not modeled from User's, use-case or Cloud
Provider developers' point of view.  As currently defined, the current Cloud
Print Manager is an artifact of a particular implementation (like DocuPrint;
maybe even CUPS) for a fan out with a single controller (Print Servcie?);
from a reference model or architecture point of view it should not matter if
there is such an entity providing this function.  This means your simple
diagram reduces to 

                         Cloud Print Provider

With """"""maybe""""" the Printer = [ Cloud Print Manager <---> Printer(s) ]
as seen from Cloud Print Provider

Actually, I see no reason to add the Print qualifier to the Provider; that
is,

                             Cloud Provider

This model states that a Client, as a proxy for the User, can access a Print
Service, of the User's Cloud Provider, to print to a User's register print
device. 

                          Print Cloud Provider

a.	A good and bad model - requires other Cloud Solution to federate
with Print Cloud Provider.   This would be a big development effort for
print vendors. 

                             Cloud Provider

a.	Again, good and bad.   Good for print vendor in that the Cloud
Provider manages Print Service; bad for the same reason.

3.	The Cloud Print Service is a "mini-cloud" or a "plug-in cloud" (but
still in the Cloud) that is callable by a Cloud Provider. 

                             Cloud Provider

    Client  <--->    \             \           

                              \            \

a.	Yes, this looks like model in the current specification but with
some slight differences.

                                                               i.      The
Cloud Print Services are in the cloud; thus, they are cloud SAAS 

                                                             ii.      A

1.      >From the User's and the Cloud Provider's point-of-view, one Print
Service is associated with one Printer.   The User and Cloud Provider
developers never know about fan-out, fin-in, fan-up, fan-down or any kind of
fan; they know there an associated Print Services for a specific Printer.  

a.       Internally, an individual "Print Service" can support 2, 700,039
Printers; that is something the print vendor does as part of their
implementation detail.   It will not affect the API's the Cloud Provider
developers uses to print to the printer.  And has nothing to do with the PWG
Cloud Print specification.

2.      >From the User's and the Cloud Provider's point-of-view, one Print
Service (associated with one Printer) has its own queue.   

a.       If a print vendor wants to have individual queues (the "bucket" of
Print Jobs) for each printer or have one giant queue (a big "bucket") that
individual printers pull jobs from, this again, is a print vendor
implementation detail.   And has nothing to do with the PWG Cloud Print
specification.

                                                           iii.      From
the Cloud Provider's point-of-view, the above definitions makes all Cloud
Print Service interfaces look the same; that it,

1.      An individual Printer is registered and has an associated a single
Print Service

2.      The Cloud Provider only talks to the Printer's Print Service for all
APIs and actions. 

3.      Print Jobs are submitted to the Print Service for the target printer
(no matter how the queue is implemented)

                                                           iv.      Thus,
the goal of the PWG Cloud activity is to define the API's and data for the
Cloud Provider to/from a Cloud Print Service

1.      I know - use IPP

a.       I don't think IPP will be used by everyone.   (Who is using it now
for Cloud?)  What "will be used" is the PWG:PJT, which does not require IPP
to be useful.   PWG:PJT make federation of the Print Jobs very simple.  In
general PWG:PJT is a perfect candidate for cloud print. 

                             Cloud Provider                    |------- a
Directory/Registry of Vendor Print Clouds

                              \            \

                                      \ Vendor M Print Cloud
\ Vendor N Print Cloud

                                                Print Service <---> Printer
Print Service <---> Printer

                                                Print Service <---> Printer
Print Service <---> Printer

                                                Print Service <---> Printer
Print Service <---> Printer

                                                Print Service <---> Printer
Print Service <---> Printer

                                                Print Service <---> Printer
Print Service <---> Printer

                                                Print Service <---> Printer
Print Service <---> Printer

glen

 

  _____  

From: Michael Sweet [mailto:[email-masked]] 
Sent: Friday, April 06, 2012 9:00 AM
To: Petrie, Glen
Cc: Peter Zehler; Ira Mcdonald; [email-masked]; [email-masked]
Subject: Re: [IPP] Where is the Cloud Print Manager in the PWG: Cloud Model

Glen,

In the original BOF-generated functional model, the Cloud Print Manager is
either located in the Printer or attached to the Printer (e.g. in the local
print server).  The Cloud Print Manager manages communications between the
lower-level printer interface and the Cloud Print Provider.

Based on our last telecon, we have introduced a Cloud Print Service into the
model which is the service in/under the Cloud Print Provider (which acts as
a System Control Service in the Semantic Model sense) that manages the
jobs/queue in the cloud for the Cloud Print Manager.  The rough ASCII art
diagram in my mind looks like this:

                   Cloud Print Provider

Thus, Clients and Cloud Print Managers talk directly to the Cloud Print
Provider and corresponding Cloud Print Service, but never directly to each
other, and only the Cloud Print Manager actually talks directly with the
Printer(s) (physical or logical) it is registering/sharing with the Cloud
Print Provider/Service.

There can potentially be multiple logical or physical printers behind the
Cloud Print Manager (think traditional fan-out configurations and
reprographic services) and those printers *may* be addressable using the
IPP/SM output device attributes/elements, but there is only a single Cloud
Print Service per Cloud Print Manager and to the Client it will appear to be
a single "queue" with one or more output devices associated with it.

Ira, Pete,

I believe it was stated in the last conference call that the Cloud Print
Manager in the cloud model diagram "is not in the cloud".   Is this true?
If so, where is it "located"? 

Glen

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. _______________________________________________
ipp mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.pwg.org/mailman/listinfo/ipp>
https://www.pwg.org/mailman/listinfo/ipp

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

---

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 6 Apr 2012 14:47:32 -0700

Glen,

I'm struggling with a number of statements, I agree the connection
between the user and the cloud is one part of the model, and the other
part is the connection of the cloud to a logical print something or
other (within my system).   Since the model started as an imaging model,
I believe the cloud to print connection should also be usable for a scan
to cloud, with different elements.

[gwp] The User connects to either the Cloud Provider's Print Client (a
Cloud Print Client) or an independent Print Client that connects to the
Cloud Provider.  The key is that connection is the User to a Print
Client. 

[gwp] Other imaging service would following exactly the same model
without loss of generality; namely,   

            User <-----> Print Client          <=> Print Service
<------> Physical Printer

            User <-----> Scan Client           <=> Scan Service
<------> Physical Scanner 

User <-----> Transform Client <=> Transform Service <------> "Physical"
Transforms

Users    register

Service register

Users <=> services are associated 

As a user and implementer I'm focusing on where the connection to the
cloud originates, and where the connection from the cloud is terminates.

[gwp]  As an user you are should have the following concerns

Assumption: The User is a member (registered) with the Cloud Provider -
i.e. has a User account. 

1.	Does my (the User's) Cloud Provider support (have
APIs/interfaces) to support an internal or external Print Client
2.	How do I (the User) "install" (register) my (the User) Physical
Printer with the Cloud Provider under my (the User) account
3.	Can/How to set up default Print Settings
4.	Can/How to allow others to use my Physical Printer.

Complete actions:

1.	I (the User) have "installed" (registered) my Physical Printer
in my account with my Cloud Provider.

Usage:

1.	Using an internal/external Print Client, I (the User) can select
an individual Physical Printer from my of installed Physical Printers
2.	I (the User) can "create" a Print Job for my document using the
capabilities of the selected Physical Printer. 

So the User does not know about or care Print Service; the User only
understands the Physical Printer they want to use.

The User certainly does not know how printing is "handled" within the
Cloud and beyond. 

The User "just wants to print".

[gwp]  As an implementer you are should have the following concerns

First of all: What are you the implementer of?

1.	An application developer invoking a print action from a print
menu selection

	a.	The application will actually invoke a Print Client 

2.	An internal/external Print Client developer capturing Print
Intent and creating a Print Job.
3.	A printer vendor developer wanting to provide Cloud Print
support for my printers.
4.	A Cloud Provider developer wanting to support Printing.

In all the implementer cases above you want the APIs for interfacing
with the Print Service associated with a Physical Printer.   And you
don't know, want to know or care "where" the Print Service is; you only
want to know how to access it and that it uses a common (defined,
standardized) set of API for printing.   You don't know, want to know or
care how the Print Service communicates with the Physical Printer; only
that the Print Service can communication with the Physical Printer.  The
Print Service will support the implementer (ultimately the User) by
providing capability information, Print Job submission, reporting
Printing Status, State & Error information and there is likely some
security issues.   Note that Print Service does not know, want to know
or care if specific User has access to the Physical Printer or not; that
is job of the Cloud Provider to support (secure) association.   If a
print vendor provides a fully implement Cloud; then that Cloud is
classified as a Cloud Provider. 

So, does the implementer know if there is fan-out or fan-in; that there
is "Print Manager"?  No.

Does implementer know about common or individual queues? No, the Print
Service API provides Print Jobs info (queue info) for the specific
Physical Printer.  (Yes, there may be a system rollup; but that is an
admin operation.)

-------------------

In summary: Users see Print Clients

                        Implementers see Print Services 

So Print Client <=> Print Services !!!!

Also, how does all of this work with federation between Clouds?!?!?! (If
allowed) A Print Service of any Cloud Provider could be "registered"
with the Users' Cloud Provider.  This is a complete transparent
functionality (yes, there a security issues) but the User set their
Print Intent and the Print Client sends the Print Job the User's Cloud
Provider who federates (forwards) the Print Job to the other Cloud
Provider and, so, forth. 

Yes

Larry

Mike,

 

 

                         Cloud Print Provider

                             Cloud Provider

                          Print Cloud Provider

 

                             Cloud Provider

 

                             Cloud Provider

    Client  <--->    \             \           

                              \            \

                                                               i.

                                                             ii.      A

1.      >From the User's and the Cloud Provider's point-of-view, one
Print Service is associated with one Printer.   The User and Cloud
Provider developers never know about fan-out, fin-in, fan-up, fan-down
or any kind of fan; they know there an associated Print Services for a
specific Printer.  

2.      >From the User's and the Cloud Provider's point-of-view, one
Print Service (associated with one Printer) has its own queue.   

                                                           iii.

                                                           iv.

1.      I know - use IPP

 

                             Cloud Provider                    |-------

                              \            \

                                      \ Vendor M Print Cloud
\ Vendor N Print Cloud

                                                Print Service <--->

                                                Print Service <--->

                                                Print Service <--->

                                                Print Service <--->

                                                Print Service <--->

                                                Print Service <--->

glen

 

<mailto:%5bmailto:[email-masked]%5d>  

Glen,

 

                   Cloud Print Provider

 

Ira, Pete,

Glen

believed to be clean.

---

From: "larryupthegrove" <[email-masked]>
Date: Fri, 6 Apr 2012 16:02:39 -0700

I’ll spend some time working through your notes and get a better
understanding.

The implementation scenario I’m trying to work with is the following:

Company has on-site ERP system, with output directed to 350 locations, 1700
printers (18 models, 7 different manufacturers).  Current print
Infrastructure is combination of UNIX and Windows print servers.  Company
has decided to move their ERP to the cloud, and eliminate if possible any
print infrastructure.  So a solution could be put everything in the cloud at
XXXX, using the same system/print infrastructure and send print using 9100,
LPR/LPD, and IPP to the individual devices. 

Since the ERP software is generating its own reports, I could assume a
“super user” status, that they own and can print to any device.  Users would
have to send their local documents to the cloud, to be printed at a
specified device.

Larry

From: Petrie, Glen [mailto:[email-masked]] 
Sent: Friday, April 06, 2012 2:48 PM
To: larryupthegrove; Michael Sweet
Cc: [email-masked]; [email-masked]
Subject: RE: [Cloud] RE: [IPP] Where is the Cloud Print Manager in the PWG:
Cloud Model

Glen,

I’m struggling with a number of statements, I agree the connection between

[gwp] The User connects to either the Cloud Provider’s Print Client (a Cloud
Print Client) or an independent Print Client that connects to the Cloud
Provider.  The key is that connection is the User to a Print Client. 

[gwp] Other imaging service would following exactly the same model without
loss of generality; namely,   

            User <-----> Print Client          ó Print Service
<------> Physical Printer

            User <-----> Scan Client           ó Scan Service
<------> Physical Scanner 

User <-----> Transform Client ó Transform Service <------> “Physical”
Transforms

Users    register

Service register

Users ó services are associated 

As a user and implementer I’m focusing on where the connection to the cloud
originates, and where the connection from the cloud is terminates.

Assumption: The User is a member (registered) with the Cloud Provider – i.e.
has a User account. 

1.	Does my (the User’s) Cloud Provider support (have APIs/interfaces)
to support an internal or external Print Client
2.	How do I (the User) “install” (register) my (the User) Physical
Printer with the Cloud Provider under my (the User) account
3.	Can/How to set up default Print Settings
4.	Can/How to allow others to use my Physical Printer.

Complete actions:

1.	I (the User) have “installed” (registered) my Physical Printer in my
account with my Cloud Provider.

Usage:

1.	Using an internal/external Print Client, I (the User) can select an
individual Physical Printer from my of installed Physical Printers
2.	I (the User) can “create” a Print Job for my document using the
capabilities of the selected Physical Printer. 

The User certainly does not know how printing is “handled” within the Cloud
and beyond. 

The User “just wants to print”.

1.	An application developer invoking a print action from a print menu
selection

2.	An internal/external Print Client developer capturing Print Intent
and creating a Print Job.
3.	A printer vendor developer wanting to provide Cloud Print support
for my printers.
4.	A Cloud Provider developer wanting to support Printing.

In all the implementer cases above you want the APIs for interfacing with
the Print Service associated with a Physical Printer.   And you don’t know,
want to know or care “where” the Print Service is; you only want to know how
to access it and that it uses a common (defined, standardized) set of API
for printing.   You don’t know, want to know or care how the Print Service
communicates with the Physical Printer; only that the Print Service can
communication with the Physical Printer.  The Print Service will support the
implementer (ultimately the User) by providing capability information, Print
Job submission, reporting Printing Status, State & Error information and
there is likely some security issues.   Note that Print Service does not
know, want to know or care if specific User has access to the Physical
Printer or not; that is job of the Cloud Provider to support (secure)
association.   If a print vendor provides a fully implement Cloud; then that
Cloud is classified as a Cloud Provider. 

So, does the implementer know if there is fan-out or fan-in; that there is
“Print Manager”?  No.

Does implementer know about common or individual queues? No, the Print
Service API provides Print Jobs info (queue info) for the specific Physical
Printer.  (Yes, there may be a system rollup; but that is an admin
operation.)

-------------------

So Print Client ó Print Services !!!!

Also, how does all of this work with federation between Clouds?!?!?! (If
allowed) A Print Service of any Cloud Provider could be “registered” with
the Users’ Cloud Provider.  This is a complete transparent functionality
(yes, there a security issues) but the User set their Print Intent and the
Print Client sends the Print Job the User’s Cloud Provider who federates
(forwards) the Print Job to the other Cloud Provider and, so, forth. 

So where you have in the last drawing – Vendor M and Vendor N, are those
print services from different print vendors or?

Yes

Larry

Mike,

Thanks for the update.   I was reviewing the diagram again and I had noted
there was no actual print entity “in the cloud”; that is, as an SAAS in
cloud terminology; so adding the Cloud Print Service at least provides a
cloud print SAAS.

I am still having a problem with the use of a Cloud Print Manager (in the
printer) concept (an the name) in the general context of being a cloud
citizen and with associating a User with an individual Print Service
(Printers).  That is, it is not modeled from User’s, use-case or Cloud
Provider developers’ point of view.  As currently defined, the current Cloud
Print Manager is an artifact of a particular implementation (like DocuPrint;
maybe even CUPS) for a fan out with a single controller (Print Servcie?);
from a reference model or architecture point of view it should not matter if
there is such an entity providing this function.  This means your simple
diagram reduces to 

                         Cloud Print Provider

With “”””””maybe””””” the Printer = [ Cloud Print Manager <---> Printer(s) ]
as seen from Cloud Print Provider

                             Cloud Provider

This model states that a Client, as a proxy for the User, can access a Print
Service, of the User’s Cloud Provider, to print to a User’s register print
device. 

1.	The “Cloud Provider” is Print Cloud (like HP’s or Epson’s or)

                          Print Cloud Provider

a.	A good and bad model – requires other Cloud Solution to federate
with Print Cloud Provider.   This would be a big development effort for
print vendors. 

                             Cloud Provider

 

3.	The Cloud Print Service is a “mini-cloud” or a “plug-in cloud” (but
still in the Cloud) that is callable by a Cloud Provider. 

                             Cloud Provider

    Client  <--->    \             \           

                              \            \

                                                               i.      The

1.      Yes, the Print Service could be in the physical printer but
virtually linked (“registered”) in the Cloud

                                                             ii.      A

1.      >From the User’s and the Cloud Provider’s point-of-view, one Print
Service is associated with one Printer.   The User and Cloud Provider
developers never know about fan-out, fin-in, fan-up, fan-down or any kind of
fan; they know there an associated Print Services for a specific Printer.  

a.       Internally, an individual “Print Service” can support 2, 700,039
Printers; that is something the print vendor does as part of their
implementation detail.   It will not affect the API’s the Cloud Provider
developers uses to print to the printer.  And has nothing to do with the PWG
Cloud Print specification.

2.      >From the User’s and the Cloud Provider’s point-of-view, one Print
Service (associated with one Printer) has its own queue.   

a.       If a print vendor wants to have individual queues (the “bucket” of
Print Jobs) for each printer or have one giant queue (a big “bucket”) that
individual printers pull jobs from, this again, is a print vendor
implementation detail.   And has nothing to do with the PWG Cloud Print
specification.

                                                           iii.      From
the Cloud Provider’s point-of-view, the above definitions makes all Cloud
Print Service interfaces look the same; that it,

2.      The Cloud Provider only talks to the Printer’s Print Service for all
APIs and actions. 

                                                           iv.      Thus,
the goal of the PWG Cloud activity is to define the API’s and data for the
Cloud Provider to/from a Cloud Print Service

1.      I know – use IPP

a.       I don’t think IPP will be used by everyone.   (Who is using it now
for Cloud?)  What “will be used” is the PWG:PJT, which does not require IPP
to be useful.   PWG:PJT make federation of the Print Jobs very simple.  In
general PWG:PJT is a perfect candidate for cloud print. 

                              \            \

                                      \ Vendor M Print Cloud
\ Vendor N Print Cloud

glen

 

  _____  

Glen,

 

                   Cloud Print Provider

 

Ira, Pete,

I believe it was stated in the last conference call that the Cloud Print
Manager in the cloud model diagram “is not in the cloud”.   Is this true?
If so, where is it “located”? 

Glen

---

From: "William Wagner" <[email-masked]>
Date: Fri, 6 Apr 2012 22:31:42 -0400

Will there be a IPP call on Monday? It is listed in the last IPP minutes,
but not mentioned in the Cloud/IPP minutes.

Thanks, Bill Wagner

---

From: Ira McDonald <[email-masked]>
Date: Sat, 7 Apr 2012 10:30:29 -0400

Hi Bill,

Yes, there will be an IPP WG meeting this Monday.

Review updated LDAP Printer Schema and (if
available) updated IPP Everywhere, plus F2F
planning.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Apr 6, 2012 at 10:31 PM, William Wagner <[email-masked]>wrote:

> but not mentioned in the Cloud/IPP minutes.****
>
> Thanks, Bill Wagner ****
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: Ira McDonald <[email-masked]>
Date: Sat, 7 Apr 2012 17:07:13 -0400

Hi,

I strongly urge that we keep the first class object Cloud
Print Manager in the functional model.  How the CPM
communicates with actual Print Devices (Printers) is
now and SHOULD remain completely out-of-scope.

Cheers,
- Ira

On Fri, Apr 6, 2012 at 4:19 PM, larryupthegrove <[email-masked]

> Glen,****
> ** **
> different elements.****
> ** **
> As a user and implementer I’m focusing on where the connection to the
> cloud originates, and where the connection from the cloud is terminates.**
> **
>
> ** **
>
> print services from different print vendors or?****
>
> ** **
>
> Larry****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Petrie, Glen
> *Sent:* Friday, April 06, 2012 10:35 AM
> *To:* Michael Sweet
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [Cloud] RE: [IPP] Where is the Cloud Print Manager in the PWG:
> Cloud Model****
>
> ** **
>
> Mike,****
>
> ** **
>
> cloud print SAAS.****
> ** **
> ** **
> Some more discussion ----------****
>
> ** **
>
> Provider developers’ point of view.  As currently defined, the current
> Cloud Print Manager is an artifact of a particular implementation (like
> DocuPrint; maybe even CUPS) for a fan out with a single controller (Print
> Servcie?); from a reference model or architecture point of view it should
> not matter if there is such an entity providing this function.  This means
> your simple diagram reduces to ****
>
> ** **
>
> ** **
>
>                          Cloud Print Provider****
>
>     Client  <--->  Cloud Print Service <---> Printer****
>
> ** **
>
> With “”””””maybe””””” the Printer = [ Cloud Print Manager <---> Printer(s)
> ]  as seen from Cloud Print Provider****
>
> ** **
>
> is,****
> ** **
>                              Cloud Provider****
>     Client  <--->  Cloud Print Service <---> Printer****
>
> ** **
>
> Print Service, of the User’s Cloud Provider, to print to a User’s register
> print device. ****
>
> ** **
>
> implementations:****
> ** **
>    1. The “Cloud Provider” is Print Cloud (like HP’s or Epson’s or)****
>
>                           Print Cloud Provider****
>
>     Client  <--->  Cloud Print Service <---> Printer****
>
>    1. A good and bad model – requires other Cloud Solution to federate
>       print vendors. ****
> ** **
> ** **
> ** **
>    1. Cloud Print Services are integrated into a Cloud Provider like
>    Google Cloud****
>
>                              Cloud Provider****
>
>     Client  <--->  Cloud Print Service <---> Printer****
>
>    1. Again, good and bad.   Good for print vendor in that the Cloud
>       Provider manages Print Service; bad for the same reason.****
>
> ** **
>
> ** **
>
> ** **
>
>    1. The Cloud Print Service is a “mini-cloud” or a “plug-in cloud” (but
>    still in the Cloud) that is callable by a Cloud Provider. ****
>
> ** **
>
>                              Cloud Provider****
>
>     Client  <--->    \             \           ****
>
>                               \            \****
>
>   \ Cloud Print Service <---> Printer****
>
> Where there is cloud around both Cloud Print and Cloud Print Service****
>
> ** **
>
>    1. Yes, this looks like model in the current specification but with
>       some slight differences.****
>
> **                                                               i.      *
> *The Cloud Print Services are in the cloud; thus, they are cloud SAAS ****
>
> **1.      **Yes, the Print Service could be in the physical printer but
> virtually linked (“registered”) in the Cloud****
>
> **                                                             ii.      **A
> printer is associated with a single Cloud Print Service****
>
> **1.      **>From the User’s and the Cloud Provider’s point-of-view, one
> Print Service is associated with one Printer.   The User and Cloud Provider
> developers never know about fan-out, fin-in, fan-up, fan-down or any kind
> of fan; they know there an associated Print Services for a specific
> Printer.  ****
>
> **a.       **Internally, an individual “Print Service” can support 2,
> 700,039 Printers; that is something the print vendor does as part of their
> developers uses to print to the printer.  And has nothing to do with the
> PWG Cloud Print specification.****
>
> **2.      **>From the User’s and the Cloud Provider’s point-of-view, one
> Print Service (associated with one Printer) has its own queue.   ****
>
> **a.       **If a print vendor wants to have individual queues (the
> “bucket” of Print Jobs) for each printer or have one giant queue (a big
> “bucket”) that individual printers pull jobs from, this again, is a print
> vendor implementation detail.   And has nothing to do with the PWG Cloud
> Print specification.****
>
> **                                                           iii.      **From
> Print Service interfaces look the same; that it,****
>
> **1.      **An individual Printer is registered and has an associated a
> single Print Service****
>
> **2.      **The Cloud Provider only talks to the Printer’s Print Service
> for all APIs and actions. ****
>
> **3.      **Print Jobs are submitted to the Print Service for the target
> printer (no matter how the queue is implemented)****
>
> **                                                           iv.      **Thus,
> Cloud Provider to/from a Cloud Print Service****
>
> **1.      **I know – use IPP****
>
> **a.       **I don’t think IPP will be used by everyone.   (Who is using
> it now for Cloud?)  What “will be used” is the PWG:PJT, which does not
> require IPP to be useful.   PWG:PJT make federation of the Print Jobs very
> simple.  In general PWG:PJT is a perfect candidate for cloud print. ****
>
> ** **
>
> So the final model is something like****
>
> ** **
>
> Directory/Registry of Vendor Print Clouds****
>
> Printers (and its Print Service) to a User ****
>
>                               \            \****
>
>                                       \ Vendor M Print Cloud
>                                   \ Vendor N Print Cloud****
>
>                                                 Print Service <--->
> Printer****
> Printer****
> Printer****
> Printer****
> Printer****
> Printer****
> ** **
> glen****
> ** **
> ** **
> ** **
> ** **
> ------------------------------
>
> *From:* Michael Sweet [mailto:[email-masked]]
> *Sent:* Friday, April 06, 2012 9:00 AM
> *To:* Petrie, Glen
> *Cc:* Peter Zehler; Ira Mcdonald; [email-masked]; [email-masked]
> *Subject:* Re: [IPP] Where is the Cloud Print Manager in the PWG: Cloud
> Model****
>
> ** **
>
> [Adding [email-masked] since this is a cloud discussion]****
>
> ** **
>
> Glen,****
>
> ** **
>
> lower-level printer interface and the Cloud Print Provider.****
>
> ** **
>
> acts as a System Control Service in the Semantic Model sense) that manages
> the jobs/queue in the cloud for the Cloud Print Manager.  The rough ASCII
> art diagram in my mind looks like this:****
>
> ** **
>
> ** **
>
>                    Cloud Print Provider****
>
> Printer(s)****
> ** **
> Print Provider/Service.****
>
> ** **
>
> Print Service per Cloud Print Manager and to the Client it will appear to
> be a single "queue" with one or more output devices associated with it.***
> *
>
> ** **
>
> ** **
>
> wrote:****
> ** **
> Ira, Pete,****
>  ****
> If so, where is it “located”? ****
>
>  ****
>
> Glen****
>
>  ****
>
>
> --
> https://www.pwg.org/mailman/listinfo/ipp****
>
> ** **
>
> __________________________________________________****
>
> Michael Sweet, Senior Printing System Engineer, PWG Chair****
>
> ** **
>
>
> --
> believed to be clean. ****
>
> --

---

From: Michael Sweet <[email-masked]>
Date: Sat, 07 Apr 2012 15:56:22 -0700

Bill,

Yes, at the usual time.  Assuming that Ira will post an official agenda, this is the planned agenda based on our last meeting:

0. Administrivia
1. Status of everything
2. Review of LDAP Printer Schema
3. Review of IPP Everywhere
4. Next Steps

On Apr 6, 2012, at 7:31 PM, William Wagner wrote:

> Will there be a IPP call on Monday? It is listed in the last IPP minutes, but not mentioned in the Cloud/IPP minutes.
> Thanks, Bill Wagner

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair