My biases in these discussion.
I consult on, and implement print and imaging solutions
within the Enterprise and SMB communities. I need to be vendor neutral, as
my partners may already have equipment, or a particular vendor best fits
their needs. This includes devices, clients, operating systems, ERP
systems, cloud providers, and networks. My other standards work has been
specific protocols, and barcoding/RFID. I don't want to end up with
"compliant" solutions that only work with a certain client device, client
software, device OS, cloud provider, network type, or printer supplier. So
my main thinking points.
1. Printers (devices or SW implementations) meeting the standard
should be able to connect and follow the registration process with any cloud
service that claims to be compliant with this standard.
2. The security and firewall transversal scheme for compliant systems,
along with logging, should be sufficient that the networking/security
community regards this standard as an acceptable implementation of a
solution that may be hosted in a cloud.
3. Standard needs to supply sufficient detailed information to
developers of cloud services or client software so that the resultant
products can be included in a range of cloud print solutions.
4. A cloud print solution compliant with this standard should work on
either an internal cloud, with a hybrid cloud, or with a public cloud.
5. This standard should integrate seamlessly with any resultant
imaging/MFD standards to increase reuse.
So in example, for the registration process, the type of information needed
to communicate and use the functionality of the printer during the print
process (printer features, and capabilities), handle exception processing,
etc., needs to be in the standard. Whether the printer registers directly,
or there is an administrative method, or an email with the information is
sent to the cloud service should be an implementation detail for the cloud
service provider.
So I have done a cloud based print service that used LPR/LPD to send the
output to print device, it works, but I would hope it would not end up
compliant with this standard.
Larry Upthegrove
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Tuesday, October 02, 2012 10:57 AM
To: <cloud at pwg.org>
Subject: Re: [Cloud] Updated model and requirements for cloud printing
I too expect to contribute more to this group, as well as the IDS group,
soon - at the moment, I'm doing what I can to offer (hopefully) constructive
comments as I'm able to.
R.
On Oct 2, 2012, at 8:15 AM, Michael Sweet <msweet at apple.com> wrote:
Bill,
FWIW, I also agree that our Cloud Print Requirements and Model document
needs to have a section/chapter on the overall functional model - that's
what we worked on for a year of BOFs before forming the WG and provides the
big picture showing what the SM provides, what is new (the Cloud Print
Server/Manager interface), and what is (currently) outside the scope of the
effort (registration, association, etc.) Without this context it is hard
for anyone (even within our group :) to understand what the heck we are
doing.
I do expect that once I am settled in my new home I will be able to
participate more fully in the Cloud Imaging WG, particularly WRT
prototyping.
On 2012-10-02, at 10:52 AM, William A Wagner <wamwagner at comcast.net> wrote:
Hi Randy,
I personally do not have much disagreement with what you say. The question
of who is the 'audience' for this document is not something that we often
consider, largely because we do not know (just as I do not know how many
implementers are 'quite familiar' with the Semantic Model.)
I do think that the document should provide a reasonable overview of the PWG
Cloud Printing Model, including a reasonable identification of how the
elements we consider out of scope work within the model (section 3) and
then a detailed consideration and definition of the cloud specific, printer
specific areas.the diff areas (largely section 4). I am not sure that this
is the current thinking of the group. Larry has gotten unclear direction on
how to proceed with the document because the group's notion changes with
time, and certainly with the changing group member participation.
To an extent, working group management should work to establish and maintain
direction. However, there are some capable and vocal persons involved that
are quick to offer critiques but not committed to provide follow-up
support.
Bill Wagner
From: <mailto:cloud-bounces at pwg.org> cloud-bounces at pwg.org [mailto:cloud-
<mailto:bounces at pwg.org> bounces at pwg.org] On Behalf Of Randy Turner
Sent: Tuesday, October 02, 2012 1:46 AM
To: <mailto:cloud at pwg.org> cloud at pwg.org
Subject: Re: [Cloud] Updated model and requirements for cloud printing
Hi Bill,
Looking at the structure of the document, if I were an implementer that was
quite familiar with the Semantic model, I would really be looking at this
document hoping to get a quick idea of how different cloud printing is from
traditional printing -- I guess I'm lazy, but I would really like to "cut to
the chase" to save time and just look at the "diffs".
There's two reasons for this:
1. It's quicker to get through the document and avoids any possible
redundancy and duplication of content with other specs
and
2. It allows me to expedite the translation of the doc to a software design
doc to identify/ reuse any existing code as much as possible, with minimal
re-factoring (OO) for any new cloud interfaces.
I understand we have a document format, and we could include those sections,
but "ref" anything we've done before, and only highlight the diffs with new
document content.
In a previous email exchange, I think Mike and I were thinking that the
"client" view or perspective of the cloud wouldn't necessarily change, at
least with regards to printing operations and capabilities. You have to
CONFIGURE access to a cloud printer in your environment, but that's not
"printing".
However, Mike and I agreed that there is a possibility for "delta"
operations for the cloud-to-printer interface. "Delta" meaning things that
we haven't identified before in traditional network print servers.
Mike mentioned the fact that the differences from traditional network
printing reside in the "firewall" problem space, but then again, that's not
strictly "printing" either.
>From a firewall perspective, we need a high-level requirement that says both
the client-to-cloud interface, as well as cloud-to-printer interface is
firewall and "NAT" friendly, which probably means, at a minimum, that the
client initiates all communications with the cloud -- it also probably means
that printers always initiate communications with the cloud. Once the
printer-to-cloud connection is established, then the cloud can elect to
"push" documents to the printer, or the printer can always "pull" documents
from the cloud -- but the communications channel itself is instantiated by
the printer. This can just be a "recommendation", and not the ONLY way to
implement cloud printing.
We do have the concept of registration and association, which I don't think
we've tackled before -- these could be discussed as potential highlighted
differences in a cloud printing model -- although one could say that a
bonjour or MS-WSD printer announcement (multicast) could be a "registration"
type of event. ("I'm registering my existence with anyone who's
interested")
I don't think we're necessarily "done" yet, but I hope we can find a way to
keep this document focused on just the "deltas" from our previous work.
Given the fact that (I think) we have declared many cloud implementation
details (firewall, nat, transport, authentication, authorization, etc.) as
out of scope, I don't think our work will help create interoperable
("wire-interoperable") cloud printing implementations. I think the value we
will be adding will be documenting, at a high level, how the PWG semantic
model is affected by "the cloud" (if at all), and then highlighting the
high-level differences.
It may be that the cloud model document is purely "informative" and not
"normative", from a standards point of view.
R.
On Oct 1, 2012, at 10:05 PM, William A Wagner wrote:
Hi Randy,
Interesting comments. You really should participate in the working group.
Sec 3.5, which still needs to be done, is in satisfaction of the PWG spec
structure that requires a statement of design requirements, presumably
derived from the use cases. One could argue that, since there are no use
cases, there can be no requirements derived from the use cases. That could
be extended to say there is no need for the design. in which case we are
done. In fact, we are taking some short cuts, largely prompted by comments
from you and others that seem plausible. Yet we also believe that interface
to the printer is not the same as for ordinary network printing. So perhaps
the requirements may be limited to areas where we ( that being the working
group) expect the design requirements to differ from network printing.
Unfortunately, we never wrote a spec for Print Service, instead relying upon
the mass of IPP documents. So there is no Semantic Model print document
that can be referenced for the Client side requirements (which the group now
maintains is the same as for network printing).
Section 4 was an attempt to describe the model diagram. Terminology is in
section 2. A great deal of time was spent on the terminology section of the
MFD model document, which was intended to cover all of the major actor
elements in the Semantic Model. Of course, we are always inclined to tweak
these definitions in a new document and often forget what the group had
decided previously. Also, there are some errors in the MFD Model
definitions, and there sometimes is new insight that suggests a change. But
the MFD Model document is supposed to contain the basic definitions.
Bill Wagner
From: <mailto:cloud-bounces at pwg.org> cloud-bounces at pwg.org [
<mailto:cloud-bounces at pwg.org> mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Monday, October 01, 2012 9:38 PM
To: < <mailto:cloud at pwg.org> cloud at pwg.org>
Subject: Re: [Cloud] Updated model and requirements for cloud printing
Hi guys,
some notes regarding the recently published cloud model document:
-------------
Sorry to be a broken record here, but isn't section 3.5 just a repeat of our
desire to follow the semantic model with regards to printer operations?
Seems like a statement saying:
The following operations from the PWG semantic model [REF] are required for
cloud printing
1.
2.
3.
etc.
>From an earlier email exchange between Mike and I, it seems like everything
just "works the same" from the "client requirements" perspective.
--------------
Section 4.1 - Are the terms "User" and "Client" defined this way in other
PWG docs? Probably should be. We should have a separate document that
defines terminology for all PWG docs, and put these in it (if we don't
already)
If we already have these defined, then we should probably just reference
them in 4.1
--------------
Section 4.2.1 - Sequence diagrams can either be "abstract" or "concrete
protocol" diagrams. I can't tell which this is.
With the reference to user credentials being one way (no challenge) and the
labels "status, access token", it seems like this is somewhat suggestive of
a concrete sequence diagram. Abstract sequence diagrams are usually NOT
normative; they're typically informative, so are we trying to "suggest"
something with these diagrams?
---------------
R.
On Oct 1, 2012, at 4:04 PM, "larryupthegrove" <
<mailto:larryupthegrove at comcast.net> larryupthegrove at comcast.net> wrote:
I made the updates and corrections from today's meeting.
<ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20121002.pdf>
ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20121002.pdf
<ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20121002.docx>
ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20121002.docx
Items I would appreciate feedback and/or suggestions.
1. Two additional sequence diagrams.
a. Config change - seems it should be very short, I was going to add
short paragraph adding some descriptive text on covering both soft and hard
(tray) changes.
b. Exception handling - could result in aborting the job, or updating
client status and waiting. Should I try to show both?
2. Any updates to reference documents that should be included.
My cleanup effort on the Visio sequence drawings needs another pass to make
it look better, as well as getting the figures into the table of contents.
Larry
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean. _______________________________________________
cloud mailing list
<mailto:cloud at pwg.org> cloud at pwg.org
<https://www.pwg.org/mailman/listinfo/cloud>
https://www.pwg.org/mailman/listinfo/cloud
--
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. _______________________________________________
cloud mailing list
<mailto:cloud at pwg.org> cloud at pwg.org
<https://www.pwg.org/mailman/listinfo/cloud>
https://www.pwg.org/mailman/listinfo/cloud
__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
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/20121002/13ba8a4d/attachment-0002.html>