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: 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.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 MailScanner, and is
> believed to be clean. _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>> --
> This message has been scanned for viruses and
> dangerous content by 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.
>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean. _______________________________________________
> cloud mailing list
>cloud at pwg.org>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 MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20121002/6629dc52/attachment-0002.html>