I don't think anyone suggesting presupposing the requirements and dreaming up
scenarios to match...
I think we started out doing the right thing, gathering compelling use-cases and then distilling requirements (possibly overlapping) from these
use-cases.
I was trying to emphasize two points:
1. We need more compelling use-cases
and
2. IPP Everywhere is, at the end of the day, a protocol -- In my opinion, Cloud Imaging is a "business"
R.
On Apr 27, 2011, at 8:27 PM, William Wagner wrote:
> 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.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.