I wouldn't have aggregated the Cloud use-case set with IPP Everywhere -- it will just create work for someone to sort all
this out because these services exist at different levels of abstraction. IPP Everywhere (the protocol) could be used to solve part of the Cloud Printing problem space, but it's a tool not a "service".
Also, please keep in mind when thinking about use-cases, there's an old marketing rule that says "Just because you can construct a use-case, doesn't mean you should support it" -- or to paraphase, "Just because you can construct a use-case, doesn't mean you should"
The use-cases that will "sell" this concept of Cloud Printing/Imaging need to be compelling and solve a clear and useful scenario. We should NOT market a Cloud Printing solution based on fringe use-cases. I believe the Pareto Principle (the 80/20 rule) applies here. 80% of the value of a Cloud Printing/Imaging Service will come from 20% of the use-case features.
It's like the iPhone -- the device has tons of features but it is successful because most people only use a handful of the capabilities of the device, at best. And Apple put the lion's share of their design and engineering into these few features. And they did it very well.
The features/use-cases for Cloud Printing/Imaging need to be obvious, compelling, and of high-value. It may help to start with a short description of a business plan for a Cloud Service and figure out what the take-rate (or popularity) of the service might be -- and obviously if it makes money. Then work backward from the plan to envision the details of how the service would work.
I think we need just three or four high-value types of service use-cases, and these use-cases can be distilled down to the key technology and capabilities that a Cloud Service should provide.
Randy
On Apr 27, 2011, at 10:53 AM, William Wagner wrote:
> I think we largely agree with Randy, and it was understood that the use
> cases submitted were to be considered for Cloud and/or IPP Everywhere
> applicability, since we needed use cases for each.
>> There are several circumstances however where printing to a local printer
> might still best use Cloud Printing. One is where the client is using Cloud
> Computing services. Although the real use case of QuickBooks check printing
> did not involve a Cloud based service, one could conceive of a situation
> (and the user in this case is considering it) where it might. In that case,
> it would be the Cloud based service that is the client, acting on behalf of
> the end user. Or the cloud based service somehow relays the print file to
> the user, who then sends it to the printer; but with this alternate
> approach, how does the service know the printer characteristics to format
> the job...?)
>> Another case where cloud printing would be necessary, even when the user and
> printer are physically co-located, is where there is no ability for the user
> to connect to the local network (or perhaps there is no local network).
> There are various scenarios for that, including perhaps situations where
> guest users are not allowed for security or regulatory purposes. Indeed,
> this would be a network remote although physically local user. Several of
> the submitted use cases could easily be cast into this mode.
>> Thanks,
> Bill Wagner
>> -----Original Message-----
> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
> Randy Turner
> Sent: Wednesday, April 27, 2011 1:10 AM
> To: cloud at pwg.org> Subject: [Cloud] Analysis of Cloud Printing use-cases
>>> My summary analysis of the use-cases (so far) is that the bulk of these
> use-cases are not "compelling" enough to utilize cloud services. And one or
> more of these use-cases seem somewhat contrived. From my perspective, any
> time the client wants to print to local ("on the same network") printing
> services, Cloud printing is really not needed. There are too many
> ad-hoc/guest printing services that can achieve this functionality, and
> these methods are far less complex than erecting a cloud printing service to
> do this.
>> On the other hand, any time the printing destination is "remote" and
> somewhat "virtual" from the perspective of the client, this is where I think
> Cloud Printing shows the most value.
>> For instance, in the "Doctor sends a prescription to a drug store for a
> patient" scenario, I would assume that the drug store has "registered" a
> destination with a cloud provider (the destination can be temporary or
> permanent), and the destination is just a name, it's a "virtual" printing
> destination. The Doctor is told (via email to his PDA) what the destination
> "virtual" name will be. The Doctor subsequently types up a prescription and
> sends it to the virtual destination. He doesn't really know if it's a
> printer, printer-to-fax gateway, or some other kind of device. The remote
> pharmacy has registered the necessary information with the Cloud Provider
> and the Doctor doesn't care (assuming there's a trust relationship between
> doctors and pharmacies in the Cloud).
>> This type of Cloud "imaging" service (could be more than printing, probably
> would be, something like an imaging "pivot" service that pivots the source
> among a number of different virtual destinations, each destination being
> potentially a different type of imaging device...print-to-fax gateway,
> print-to-email gateway, traditional printer, etc.
>> The way I see Cloud Imaging, the more the "source" of an imaging job is
> isolated from the "destination" for the imaging job, the more value a Cloud
> Imaging Provider can offer. By "isolated", I mean that the client knows
> little or nothing about the destination of the print job (isolated in
> knowledge), and nothing about "where" the destination is (isolated
> "geographically")
>> Years ago, Kinkos broached the idea of "Cloud Printing" by tying together
> all their geographic locations into a virtual printing network, and
> subscribers could send their complex print jobs into the Kinkos cloud, and
> Kinkos would deliver the complete, finished bundle to the Kinkos location
> closest to the zip code of the job submitter (subscriber). This is
> something similar to what I am thinking about, but the concept of Cloud
> Printing (especially an Cloud "Imaging" Provider) could go beyond Kinkos.
>> To me, if the source and destination are on the same LAN, Cloud Printing
> becomes far less compelling, however, device discovery and IPP Everywhere
> become more compelling.
>> I will try and add to the list of use-cases published thus far with a couple
> of more concrete scenarios to which I'm referring in the above text.
>>> Randy
>>> --
> 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.