I'll continue to voice my opposition for this on principle, since it makes for a bad user experience ("Why can't I select my printer as the scanner") and a support nightmare. But if Xerox wants to take that on, so be it.
Some feedback on the proposed name and description:
1. Instead of "push", how about "Scan2"? (marginally larger while clearly limiting to the scan destinations, pairs nicely with the existing "Scan" key in the Bonjour Printing specification)
2. For the description, it should say:
A comma-delimited list of destination URI schemes supported by the IPP Scan Service, including "ftp", "ftps", "http", "https", "ipp", "ipps", "mailto", and "smb". MUST contain the same values as reported by the "destination-uri-schemes-supported" attribute or be the empty string if Push Scanning is not supported.
3. For the default value:
"" (Push Scanning not supported)
I would also like to see some recommendations here for use of the discovery information, such as:
Clients using Bonjour for discovery can browse for the _scan subtype to limit the list of services to those with scanning capabilities. While additional filtering can be performed using TXT record key values, such filtering is not recommended for general purpose scan Clients since it can confuse and/or frustrate End Users.
(I realize we don't generally include such recommendations, but in this case I think we need to say something to help avoid the interoperability and perception issues it could cause.)
Finally, we may need to say something in the Client conformance section, since right now you could argue that a Client that doesn't support pull scan is non-conforming. I'm not sure how to address this directly, short of making a lot of conditional conformance requirements, e.g.:
Clients MUST support Pull and/or Push Scanning and SHOULD support both. If the Client supports Pull Scanning it MUST determine whether the IPP Scan Service supports it and the corresponding destination URI scheme. Clients SHOULD support Pull Scanning as a fallback when the IPP Scan Service does not support Push Scanning with the desired destination URI scheme.
Ultimately, IPP Scan should Just Work in all cases. Anything less will be seen as a failure to End Users, and I think we need to keep that in mind for all of the standards we define - happy users buy and use printers...
On Feb 13, 2014, at 8:06 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
>> 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).
>> 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> 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?
>> On Feb 11, 2014, at 3:45 PM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
>> 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
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4881 bytes
Desc: not available