[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
Tue Feb 11 20:09:25 UTC 2014


Pete,

First, support for push scan != support for a workflow solution.

Second, how do you anticipate this being used with discovery? Do you think that users will be using a special workflow scanning application that only shows compatible MFDs that it discovers through DNS-SD/LDAP and does not support pull-scan only MFDs?

(Bear with me, I'm not trying to be difficult, just trying to wrap my head around what the use case/requirements are here. A list of push schemes doesn't feel like the right answer to me...)


On Feb 11, 2014, at 1:12 PM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:

> Mike,
>  
> My definition of constrained network scan client with minimal local storage  is a dual-core 1GHz Snapdragon processor, a 4-inch WVGA screen, 512MB of memory and 2GB of storage.  But accommodating low end clients was not my point. 
>  
> The need Xerox has to discover a Push scan service are scenarios such as I mentioned below.  This is not a capability that can be implemented by a client.   A pull from and MFD and then a push to a repository is not equivalent to an MFD pushing to a repository.   I view this as an enterprise scanning requirement.  Consumer and SMB targeted products can simply just implement pull and avoid the push related overhead.  But we need a scan solution that scales. Using discovery to filter basic relatively static capabilities is required.  For printing that is things like color printing and supported PDLs.  For Scanning it is document feed capabilities and , for me, if it can deliver a scan directly to a workflow (i.e., Push).
>  
> Pete
>  
> 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: Tuesday, February 11, 2014 11:49 AM
> To: Zehler, Peter
> Cc: Ira McDonald; IPP at pwg.org
> Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?
>  
> Pete,
>  
> Please provide your definition of a constrained network scan client with minimal local storage.
>  
>  
> On Feb 11, 2014, at 11:38 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> 
> 
> All,
> The use case of the constrained client with minimal local storage should be accommodated.  However the use case important to Xerox is where the client must have the scanner deliver the scanned documents directly to the destination.  (e.g., scanning a contract and delivering is securely to the destination.)  The ability to discover scanners that support push without interrogating all the scanners in an enterprise environment is needed.  We eliminated seven of the text records from the discovery message.  This leaves 4 mandatory, 2 conditional, and 2 optional.  Adding this one should not be an undue burden.  I can live with a Boolean but would prefer a list of schemes.  A list fully populated with the defined values would be “http,https,ftp,ftps,smb,ipp,ipps,mailto” which probably comes down to about 45 bytes for the text record.
> Pete
>  
> 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: Ira McDonald [mailto:blueroofmusic at gmail.com] 
> Sent: Tuesday, February 11, 2014 10:55 AM
> To: Michael Sweet; Ira McDonald
> Cc: Zehler, Peter; IPP at pwg.org
> Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?
>  
> Hi Mike,
> 
> Crossed wires?
> 
> The mobile client may have very limited local storage and therefore want
> the MFD to push a large scan output file directly to a network server.  That's
> the use case for the boolean in the TXT record (at least I thought that was
> what Smith and Pete were concerned about).
> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic at gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
>  
> 
> On Tue, Feb 11, 2014 at 10:13 AM, Michael Sweet <msweet at apple.com> wrote:
> Ira,
>  
> On Feb 10, 2014, at 5:31 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> Hi Mike and Pete,
> 
> What about a simple TXT record discovery attribute for Push capability that's boolean?
> Since a bunch of URI schemes are conditionally mandatory anyway, that gets 90% of
> the discovery need.
>  
> What would be the use case?
>  
> It's one thing to need to find a color printer - you can't use software to print color on a B&W printers - but for scan if the MFD doesn't support push, the (mobile) client certainly *can* do it...
>  
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>  
>  
>  
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>  

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140211/8320db75/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/20140211/8320db75/attachment.p7s>


More information about the ipp mailing list