[IPP] IPP Scan - Is Push scanning mandatory?

[IPP] IPP Scan - Is Push scanning mandatory?

[IPP] IPP Scan - Is Push scanning mandatory?

Michael Sweet msweet at apple.com
Wed Feb 12 21:12:09 UTC 2014


On Feb 11, 2014, at 3:45 PM, Zehler, Peter <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/20140212/058ecf12/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140212/058ecf12/attachment.p7s>

More information about the ipp mailing list