All,
I am pushing hard for discovery of push capability because it is an absolute requirement in the enterprise environment. If there is consensus that it is such a burden, then we can make it optional instead of conditionally mandatory. I think the opposition to the text discovery text record is the minority. If I am wrong I'd like to hear from others.
The exact nature of Xerox's use cases is beyond the scope of public discussion other than to reiterate that we have a business need for scanned documents to be delivered directly from the scan service to the scan destination and not allowing the scan client to act as an intermediary. Xerox would have no problem with Push being mandatory but we realize for the low end it may be a burden. We would have no problem allowing Push or Pull or both, but realize that the PWG wants to insure some level of guaranteed interoperability so we support making Pull mandatory.
Xerox requests that Push be optional but want the feature discoverable.
Remote copy is not creating a copy like service using scan. It is a marketing term for scan to print where the scanner and printer are geographically separate. (As you may recall I was vehemently opposed to modeling copy as scan to print.) I do not consider scan to email an edge case given it is already supported by every MFD vendor in the PWG. The use of an IPP Scan client on a mobile device does not equate to the mobile device being the recipient of the scanned document. There are other capabilities that the mobile device brings such as all the personalized information (e.g., contacts) and superior UI. Capabilities like those as well as the current movement from PCs to mobile make implementing an IPP Scan Client on a mobile device desirable.
It is my preference to have a text record that is a comma separated list of schemes as described below (i.e. conditionally mandatory).
Key
Description
Default
push
A comma separated list using the following keywords: http, https, ftp, ftps, smb, ipp, ipps, mailto. Vendors may extend the set of values.
Push scan is not supported
Please voice your support or opposition.
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com<mailto:Peter.Zehler at Xerox.com>
Office: +1 (585) 265-8755
Mobile: +1 (585) 329-9508
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Wednesday, February 12, 2014 4:12 PM
To: Zehler, Peter
Cc: Ira McDonald; IPP at pwg.org
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?
Pete,
On Feb 11, 2014, at 3:45 PM, Zehler, Peter <Peter.Zehler at xerox.com<mailto:Peter.Zehler at xerox.com>> wrote:
Mike,
First, some workflows require push scan. That does not mean push scan == workflow. I do not consider scan to DropBox, SkyDrive or Flickr to be workflows but they are none the less useful "software optimizations". Although a "fire and forget" aspect of the feature might be considered more than just an optimization.
In the case of those services, I would expect you would need to include credentials in the URIs, and that's not something I think we want to encourage...
Second, I expect that certain workflow Apps will only show scanners that can potentially deliver scans directly to the destination. Pull only scanners are excluded from consideration.
Why would they exclude them? Are there security or other reasons?
As I said, I can live with a Boolean since that will narrow the field to at least the scanners capable of delivering scans directly to a destination.
If we really think push scanning is so important, we should make it required. If we think it is a useful optimization, it can stay recommended. Either way I don't see the need to include the schemes in the TXT record - you are standing/sitting in front of the MFD and it should just work!
The reason the schemes would be of interest is that finding a scanner capable of "remote copy" (i.e., scan to ipp/ipps) might be of interest.
Please, let's not bring that up again. It is useful for workflow but we are not trying to create a copy-like service interface through scan, just as we didn't want to do it with faxout or with print. We collectively chose to keep a separate copy service for that purpose, and there was no interest in doing an IPP Copy Service spec because initiating copy from a client is just an interesting edge case.
A scan-to-email scanner might also be interesting for a client to find.
Scan-to-email can be done a bunch of ways, but I would say using my mobile device to do a direct scan to email is an edge case. More likely I'll want to have a copy of the document on my device as well and that isn't something push scan will give me.
I would think that a push scanner could be depended upon to support http/https. Which leaves ftp, ftps and smb. I see some workflow solutions using hot folders that would benefit from that information but that is not a primary concern.
For write access, I would guess that SMB and FTP are going to be the general favorites over HTTP, as those services generally have write access enabled by default while HTTP requires special configuration or third-party solutions that have been configured accordingly.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140213/bf9f50e3/attachment.html>