Randy,
I like your second point that " Cloud Imaging is a "business ". But it
would sure help all those businesses to have a standard protocol to
interact with backend services and devices that can penetrate firewalls.
An industry wide agreed upon model is useful to simplify the integration
of heterogeneous backend devices, services and protocols. End Users
need not know the rigorous semantic definitions of job tickets, but the
transforming process does. I am less convinced that job submitters
need a standard protocol. While I can see advantages of a portal that
supports a standard protocol for submission via automata, I see the
primary interaction of Cloud Imaging job submitters to be through a
rich web environment.
Pete
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
-----Original Message-----
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Thursday, April 28, 2011 12:08 AM
To: cloud at pwg.org
Subject: Re: [Cloud] Analysis of Cloud Printing use-cases
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.
_______________________________________________
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.