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: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Tuesday, October 02, 2012 1:46 AM
To: 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: 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: <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" <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 MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20121002/88a0a85f/attachment-0002.html>