Randy,
I've been participating in various capacities with with IETF and PWG since 1998. Back then I was vocal about printers supporting standard PDLs and basic print intent such as media size, duplex, etc. I saw them as necessary for supporting printing from every platform (at the time I was selling a printing solution and maintaining thousands of drivers), because I saw a growing diversity of platforms that my customers wanted to support and it just wasn't feasible for me to deploy printer drivers. There was MAJOR resistance to any standardization at the time - everyone thought *their* solution was the right one, or that *they* didn't want the IETF/PWG dictating that they put in their printers. But after only (!) 15 years we now have IPP Everywhere, and I think we can finally say we can easily print from any platform.
However, mobile platforms and much more complicated networks are the new threat to printing - now instead of needing to deploy drivers you need to deploy N solutions to allow all of your devices to reach all of your printers. Again we have resistance to and fear of standardization and putting requirements on printers - this shows up in arguments over scope, format and organization of use cases, and so forth.
Personally, I don't want to spend 15 years on Cloud Imaging like I did on IPP Everywhere. I think we are VERY close to a complete functional model, and with IPPSIX we have a complete binding for printing that will enable cross-network printing from any platform to any printer. As someone working for an OS vendor, my goal (and my marching orders) are to promote and develop standard interfaces for printers so that we can support all printers out-of-the-box. Drivers are not an option in future architectures, and we are not repeating that game for Cloud.
Some specific comments to your post are inline below...
On 2013-06-04, at 2:13 AM, Randy Turner <rturner at amalfisystems.com> wrote:
> ...
> Looking at the document, it appears that we have already "designed" how the system is supposed to work, so I'm not sure if use-cases or requirements even need to be documented at this point.
We've been working on this since the first June 2010 Cloud Printing BOF - almost exactly 3 years. During Cloud Printing BOFs we defined the basic use cases, design requirements, and the beginnings of a functional model for printing. And after that we spent another year on defining "common use cases" for multifunction services in order to have a more complete view of what the whole MFD "system" needs to be capable of doing.
So yes, in a large sense we do already know what the "system" needs to do. But we've also spent a lot of time debating the format of use cases, whether exceptions should be documented as use cases, and whether use cases should describe the solution. A lot of time and effort has been lost focusing on this one section of the document, and AGAIN we are focusing on it, just in a different way.
> ...
> In my experience, the order of operations goes something like:
>> 1. BOF (ok, this sounds like something useful, let's get started)
Yup, did that.
> 2. Use-Cases
Did that too.
> 3. Requirements (somewhat detailed, derived from use-cases)
Spent a lot of time on this.
> 4. Functional Specification (how the system is supposed to work, which is much of what we have done to date)
This was largely the focus of the Cloud Printing BOFs and subsequent discussions until we got mired in use case rewrites.
> 5. Design Document (for implementers)
This is largely done in schema already, with pending corrections and wrapping up with descriptive text. And over in IPP land we have IPPSIX which goes into much greater detail for actually implementing things at a protocol level.
> ….
> To maximize our efficiency in getting this document done, I would recommend that we change the name to:
>> "Cloud Imaging Model and Functional Specification" since we seem to already know how the system is supposed to work (in some detail).
Cloud has always been defining a functional model. The current title, "Cloud Imaging Requirements and Model" already reflects this. True, we're defining elements, groups, objects, and operations in XML schema to add to Semantic Model 2.0, but an XML schema is not, by itself, a binding. That's something the SM workgroup probably needs to tackle at some point (a formal, PWG standard SOAP binding based on SM 2.0) complete with at least one reference implementation.
In the meantime, we are closely tracking the Cloud Imaging Requirements and Model for IPP in order to develop IPPSIX. This work necessarily also influences the functional model (as implementations often do) as we discover edge cases and try to solve and generalize implementation problems (such as exposing Imaging Device, changing Manager to Proxy, etc.)
So with all due respect, I don't think a name change is the bike shed we need to paint. In the coming months I think we should be working on (in no particular order):
1. The editorial changes requested for section 3 (slimming down use cases, separate section for exceptions); this is something that can happen in parallel by a few members (Bill, Randy, Larry?) with the results presented at a future meeting (concall or F2F)
2. Reconcile the current section 4 content with the proposed changes from IPPSIX - exposing Imaging Devices
3. Continue discussion and definition of the Cloud Imaging System object and System Control Service - how is it the same as SM System Object and System Control Service, how is it different
4. Continue discussion of how document input services differ from document output services, how the Cloud Imaging System might provide and advertise intermediate storage for such services, e.g., where to store scanned documents so that Proxy and Client can upload and download them.
5. Work with SM WG on changes to document input services (based on #4) and SOAP bindings
_________________________________________________________
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.