ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20120330.docx
Is the document we were discussing. Other discussion notes are in the
meeting minutes and BOF presentations at http://www.pwg.org/cloud/index.html
Larry Upthegrove
From: Nishino，Tetsuya(西野徹也) [mailto:tetsuya.nishino at dc.kyocera.com]
Sent: Monday, April 02, 2012 9:25 PM
To: larryupthegrove; 'Petrie, Glen'; ipp at pwg.org
Subject: RE: [IPP] A different function model for discuss
Hi All,
Can someone send me a link so that I can understand the diagram with the
print manager, the cloud printer, printers and so on?
Thanks,
Tetsu
=========================================================
KYOCERA Document Solutions Inc.
R&D Department 63, Software 1 R&D Division, Corporate Software R&D Division
Tetsuya Nishino
2-14-9, Tamagawadai, Setagaya-ward, Tokyo, 158-8610 Japan
Tel:+81-03-3708-3846 / Fax:+81-03-3708-0423
(tetsuya.nishino at dc.kyocera.com <mailto:ntetsuya.nishino at dc.kyocera.com> )
http://www.kyoceradocumentsolutions.com
=========================================================
New Document Solutions for your Business.
"KYOCERA Document Solutions Inc." reborn on April 1.
"KYOCERA MITA Corporation" is now called " KYOCERA Document Solutions Inc."
----------------------------------------------------------------------------
-
_____
From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of
larryupthegrove
Sent: Tuesday, April 03, 2012 9:39 AM
To: 'Petrie, Glen'; ipp at pwg.org
Subject: RE: [IPP] A different function model for discuss
All,
The reason I see for having a “Print Manager” is for the purpose of having
a standard for connecting a printer (logical or physical) to the cloud
provider.
So the simplest implementation would reflect just a user connecting to the
cloud provider. The cloud provider “owns” the printers, so there isn’t
any outgoing connection to model.
Examples would be Staples, Mimeo.com, Vistaprint.com
Second implementation would be devices not owned by the cloud provider.
Current implementations include mail protocols, FTP, IPP, route via Dropbox,
Box, Google cloud print, etc. So a standard should address a common
solution that works for a variety of implementations. So having a cloud
print manager at , or as part of, each device makes sense to me.
The third implementation would be a more robust print manager, which would
control multiple devices off of a single connection. My example would be
IBM InfoPrint manager or similar output manager.
So I see two parts to this, one between the user and the cloud provider, and
one between the cloud provider and some common point that works for multiple
implementations. Since in a large number of cases the print data has to
transverse into a private network, that common point should be capable of
being hosted within a private network.
Just my thoughts…
Larry
From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Petrie,
Glen
Sent: Monday, April 02, 2012 3:38 PM
To: ipp at pwg.org
Subject: [IPP] A different function model for discuss
All,
After today’s meeting, I thought I would try to draw a slightly different
representation of the functional model diagram than what is in the current
model document. In the current model it is very unclear what and where the
“Cloud Print Manager” is (is in its own cloud or is it proxy (so not
really a cloud service) or in the printer (so not really a cloud service)).
Why does the (Print) Client “register” with the Cloud Provider instead of
just using the Cloud Print Provider.
In the functional model attached, I propose the more cloud centric model
which places service, security and other functionality in the Cloud. The
model is not specifically concerned with interfaces such as using IPP; it is
meant to be more a very top level view. In the attached model the Client
uses or accesses the Cloud Provider for printing services. The User
interacts with the Cloud Print Provider to select a Print Service associated
with the User. The Cloud Print Provider then sends Capability information
(which likely has no secure information) to the Client. The Print Client
creates Print Job Ticket (with a Print Content reference) which is sent to
the Print Service (or Print Service Manager) for printing. The Print
Service accepts (or rejects the Print Job). The Print Service prints the
Print Job and sends status info to the Print Status Service. Federated
printing also work quit well with this model.
Glen
--
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/ipp/attachments/20120402/33c31c4d/attachment-0001.html>