Randy, I think we all agree with your observation that not all use cases
necessary should be addressed, and that the use cases from which
requirements are derived, if not compelling in themselves, should highlight
what we expect to be the compelling requirements that we need to address.
However, the IPP Everywhere spec does need use cases as well as the Cloud
spec. And there are some areas where either approach might be used, with
perhaps just a slight twist in circumstances changing whether Cloud or IPP
Everywhere is preferable.
Yes, there is work in sorting out the use cases, and a session at the May
face to face has been allotted for that task. I suspect the thinking is that
this is constructive work, and that a boarder view and differentiation of
scenarios will give better insight into the requirements of each effort. At
any rate, I suggest that this is an interesting alternative to the approach
of presupposing the requirements and then dreaming up some possibly
plausible scenario that illustrates the need.
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 9:55 PM
To: cloud at pwg.org
Subject: Re: [Cloud] Analysis of Cloud Printing use-cases
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.
_______________________________________________
cloud mailing list
cloud at pwg.orghttps://www.pwg.org/mailman/listinfo/cloud
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.