Subject: [IPP] IPP Scan - Is Push scanning mandatory?

From: "Zehler, Peter" <[email-masked]>
Date: Mon, 10 Feb 2014 19:59:42 +0000

All,

I have conflicting notes.  I have some Push scan related attributes marked as conditionally mandatory while Pull and Push scan are listed as required.

My opinion is that Push and Pull scanning are mandated and therefore the Push related attributes are also mandatory.  For Push scanning the "http", "https", "ftp" and  "ftps URI schemes MUST be supported.

Any objections?

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]<mailto:[email-masked]>
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

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 10 Feb 2014 15:07:24 -0500

Pete,

I thought we were requiring pull scan and recommending push scan because low-end devices couldn't retry a push automatically. Any push-related attributes would be conditionally required if the service supports push.  And any retry-related attributes would be conditionally required for services that do output spooling.

On Feb 10, 2014, at 2:59 PM, Zehler, Peter <[email-masked]> wrote:

> My opinion is that Push and Pull scanning are mandated and therefore the Push related attributes are also mandatory.  For Push scanning the “http”, “https”, “ftp” and  “ftps URI schemes MUST be supported.
>  
> Any objections?
>  
> Peter Zehler
> 
> Email: [email-masked]

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Zehler, Peter" <[email-masked]>
Date: Mon, 10 Feb 2014 20:13:46 +0000

Mike,

That works for me and for some internal requests.  The additional request for having Push optional would be to include a discovery attribute to locate Scanners with push capability.

What do you think about a comma separated list of push URL schemes and an empty list indicates a Pull only scanner?

Peter Zehler

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Monday, February 10, 2014 3:07 PM
To: Zehler, Peter
Cc: [email-masked]
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?

Pete,

On Feb 10, 2014, at 2:59 PM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:

All,

Any objections?

Peter Zehler

_______________________________________________
ipp mailing list
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 10 Feb 2014 15:29:16 -0500

Pete,

I'm not sure it makes much sense to include the push schemes in the TXT record since you need to load the hardcopy to be scanned on a particular device - probably better to browse for _ipp._tcp,_scan and then do a Get-Printer-Attributes to get the values you are looking for, *if* you really wanted an application that could help a user find a MFD with push scan capabilities.

The more likely use case is that you browse to find the MFD you just loaded the hardcopy in, send an Identify-Printer to confirm, and then send a Get-Printer-Attributes to get the MFD capabilities (which might include whether push scan to an email address is possible, for example).  For that you don't need the push schemes in the TXT record...

---

From: Ira McDonald <[email-masked]>
Date: Mon, 10 Feb 2014 17:31:50 -0500

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.

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: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Feb 10, 2014 at 3:29 PM, Michael Sweet <[email-masked]> wrote:

> Pete,
>
> I'm not sure it makes much sense to include the push schemes in the TXT
> record since you need to load the hardcopy to be scanned on a particular
> device - probably better to browse for _ipp._tcp,_scan and then do a
> Get-Printer-Attributes to get the values you are looking for, *if* you
> really wanted an application that could help a user find a MFD with push
> scan capabilities.
>
> The more likely use case is that you browse to find the MFD you just
> loaded the hardcopy in, send an Identify-Printer to confirm, and then send
> a Get-Printer-Attributes to get the MFD capabilities (which might include
> whether push scan to an email address is possible, for example).  For that
> you don't need the push schemes in the TXT record...
>
>
> That works for me and for some internal requests.  The additional request
> for having Push optional would be to include a discovery attribute to
> locate Scanners with push capability.
>
>
>
> What do you think about a comma separated list of push URL schemes and an
> empty list indicates a Pull only scanner?
>
>
>
>
>
> Peter Zehler
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Michael Sweet
> *Sent:* Monday, February 10, 2014 3:07 PM
> *To:* Zehler, Peter
> *Cc:* [email-masked]
> *Subject:* Re: [IPP] IPP Scan - Is Push scanning mandatory?
>
>
>
> Pete,
>
>
>
> I thought we were requiring pull scan and recommending push scan because
> low-end devices couldn't retry a push automatically. Any push-related
> attributes would be conditionally required if the service supports push.
>  And any retry-related attributes would be conditionally required for
> services that do output spooling.
>
>
>
>
>
> I have conflicting notes.  I have some Push scan related attributes marked
> as conditionally mandatory while Pull and Push scan are listed as required.
>
>
>
> My opinion is that Push and Pull scanning are mandated and therefore the
> Push related attributes are also mandatory.  For Push scanning the "http",
> "https", "ftp" and  "ftps URI schemes MUST be supported.
>
>
>
> Any objections?
>
>
>
> Peter Zehler
>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 10 Feb 2014 22:51:23 +0000

Hi there,

I agree that Push should be optional.

Would we imagine that a client would filter on the Push URI schemes it supported?  If so, Pete’s key with a value listing the supported schemes is preferable.

For advertising Push via DNS-SD, the design decision should come down to balancing the size of the TXT record against the desire to discover or filter this capability using purely the values in the TXT record vs. having to do a follow-up interrogation, which is generally expensive and not desirable.

Also, should IPP Scan include a way for the MFD to find Push scan destinations?

Smith

/**
    Smith Kennedy
    ATB Wireless Architect - PPS
    Hewlett-Packard Co.
*/

On 2014-02-10, at 3:31 PM, Ira McDonald <[email-masked]> 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.
> 
> Cheers,
> - Ira
> 
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 11 Feb 2014 10:13:35 -0500

Ira,

> Since a bunch of URI schemes are conditionally mandatory anyway, that gets 90% of

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...

---

From: Michael Sweet <[email-masked]>
Date: Tue, 11 Feb 2014 10:28:10 -0500

Smith,

> Would we imagine that a client would filter on the Push URI schemes it supported?  If so, Pete’s key with a value listing the supported schemes is preferable.

See my other message to Ira; I don't see clients doing this, if for any other reason that having the printer push the content to a destination is simply a software optimization - the client is perfectly capable of pulling the content and forwarding it to the destination on its own.

> For advertising Push via DNS-SD, the design decision should come down to balancing the size of the TXT record against the desire to discover or filter this capability using purely the values in the…

I generally think we should limit capabilities in the TXT record to those that cannot be easily simulated in software such as color support or things that have obvious utility/convenience to end users such as auto-duplex, auto-document-feeder, etc.

Push scan support can be easily simulated in software and may be preferable to MFD-provided push support for things like emailing confidential documents - the client has no idea what security policies are in place for the MFD's email gateway but it *will* know the user's email gateway configuration.

> Also, should IPP Scan include a way for the MFD to find Push scan destinations?

That is an interesting idea, but I think it should be out-of-scope for IPP Scan since it applies to any destination URI (not just push scan), would be fairly involved on its own, and there are existing definitions of Bonjour and LDAP services that can be used by an implementation (think LDAP email directories that most MFDs already support today...)

---

From: Ira McDonald <[email-masked]>
Date: Tue, 11 Feb 2014 10:55:21 -0500

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

On Tue, Feb 11, 2014 at 10:13 AM, Michael Sweet <[email-masked]> wrote:

> 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...
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 11 Feb 2014 11:18:09 -0500

Ira,

> the MFD to push a large scan output file directly to a network server.

Today's mobile clients (ones that would be used for scanning anyways) start with 8GB of onboard storage (flash).  At those capacities, a client can store approximately 65,000 pages worth of B&W documents at 200dpi ("super-fine" fax quality) or 4,000 photos at 600dpi - that isn't very limited in my book.

And if for some reason you don't have enough available local storage space you can still stream it from the MFD to the destination.

---

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 11 Feb 2014 16:38:16 +0000

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

From: Ira McDonald [mailto:[email-masked]]
Sent: Tuesday, February 11, 2014 10:55 AM
To: Michael Sweet; Ira McDonald
Cc: Zehler, Peter; [email-masked]
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

mailto: [email-masked]<mailto:[email-masked]>

On Tue, Feb 11, 2014 at 10:13 AM, Michael Sweet <[email-masked]<mailto:[email-masked]>> wrote:
Ira,

On Feb 10, 2014, at 5:31 PM, Ira McDonald <[email-masked]<mailto:[email-masked]>> 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.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 11 Feb 2014 11:49:04 -0500

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 <[email-masked]> 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
>

---

From: Ira McDonald <[email-masked]>
Date: Tue, 11 Feb 2014 11:57:19 -0500

Hi Mike,

I also want to hear Pete's definition of constrained network clients.

In TCG work on mobile devices, we are careful to accomodate very low-end
"feature phones" (under $100 street price) that dominate the emerging
countries
markets.  These devices definitely do *not* have 8GB, high-speed CPUs, or
large batteries.

Radio usage controls battery life.  Acting as a pull and forward agent for
large
files is a seriously poor idea for very low-end phones.

Cheers,
- Ira

On Tue, Feb 11, 2014 at 11:49 AM, Michael Sweet <[email-masked]> wrote:

> 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
>
> *From:* Ira McDonald [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, February 11, 2014 10:55 AM
> *To:* Michael Sweet; Ira McDonald
> *Cc:* Zehler, Peter; [email-masked]

---

From: Michael Sweet <[email-masked]>
Date: Tue, 11 Feb 2014 12:37:30 -0500

Ira,

On Feb 11, 2014, at 11:57 AM, Ira McDonald <[email-masked]> wrote:
> "feature phones" (under $100 street price) that dominate the emerging countries

But are you going to initiate a scan from a low-end feature phone?  Would you want to?

*If* that class of device is really important to support (which I question), then we should make push scan unconditionally required.  However, if we decide to set the bar high enough that the client is capable of viewing web pages and images, sending emails, etc., then I don't think push scan is necessary.

In either case, I don't think the answer is to add another TXT record key for a capability that can be implemented by a client.

> Radio usage controls battery life.  Acting as a pull and forward agent for large

Do some scans and check the sizes.  I recently scanned 65 pages worth of reports to have a digital copy, and it fit in 8MB. That doesn't take a long time to send even over bad Wi-Fi/cellular links.

---

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 11 Feb 2014 18:12:59 +0000

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

From: Michael Sweet [mailto:[email-masked]]
Sent: Tuesday, February 11, 2014 11:49 AM
To: Zehler, Peter
Cc: Ira McDonald; [email-masked]
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?

Pete,

On Feb 11, 2014, at 11:38 AM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:

All,

Peter Zehler

Cc: Zehler, Peter; [email-masked]<mailto:[email-masked]>

Hi Mike,
Crossed wires?

---

From: Michael Sweet <[email-masked]>
Date: Tue, 11 Feb 2014 15:09:25 -0500

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...)

---

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 11 Feb 2014 20:45:50 +0000

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.

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.

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.  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.  A scan-to-email scanner might also be interesting for a client to find.   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.

Peter Zehler

From: Michael Sweet [mailto:[email-masked]]
Sent: Tuesday, February 11, 2014 3:09 PM
To: Zehler, Peter
Cc: Ira McDonald; [email-masked]
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?

Pete,

On Feb 11, 2014, at 1:12 PM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:

Mike,

Pete

Peter Zehler

From: Michael Sweet [mailto:[email-masked]]
Sent: Tuesday, February 11, 2014 11:49 AM
To: Zehler, Peter
Cc: Ira McDonald; [email-masked]<mailto:[email-masked]>
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?

Pete,

All,

Peter Zehler

Hi Mike,
Crossed wires?

---

From: Michael Sweet <[email-masked]>
Date: Wed, 12 Feb 2014 16:12:09 -0500

Pete,

On Feb 11, 2014, at 3:45 PM, Zehler, Peter <[email-masked]> 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.

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Wed, 12 Feb 2014 21:24:44 +0000

> 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.

Resource constrained all-in-one devices may not able to support push.  So push should not be a “required” facility of IPP Scan.

Smith

---

From: "Zehler, Peter" <[email-masked]>
Date: Thu, 13 Feb 2014 13:06:35 +0000

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

From: Michael Sweet [mailto:[email-masked]]
Sent: Wednesday, February 12, 2014 4:12 PM
To: Zehler, Peter
Cc: Ira McDonald; [email-masked]
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?

Pete,

On Feb 11, 2014, at 3:45 PM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:
Mike,

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.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 13 Feb 2014 09:30:41 -0500

Pete,

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 <[email-masked]> wrote:

> 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. 
>

---

From: "Soma Meiyappan" <[email-masked]>
Date: Fri, 14 Feb 2014 15:07:31 -0800

Gentlemen,

The proposed Scan2 seems to bear a resemblance to FaxOut's send-from-glass capabilities. Of course, one may consider a slight difference in scan capabilities between a scan service and a faxout service for the scan service to be a more suitable host for non-fax digital sends. However, should we consider any potential duplication of features between IPP services and a confusion between clients/servers on the service where this functionality will be made available? I agree that it does not prevent device manufacturers from implementing similar functionality through both IPP services. But I wanted to hear your thoughts on this.

Thanks and Regards,
Somasundaram.
Senior Staff Engineer,
Conexant Systems Inc.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Thursday, February 13, 2014 10:31 PM
To: Peter Zehler
Cc: [email-masked]
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?

Pete,

On Feb 13, 2014, at 8:06 AM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:

All,

Key

Description

Default

push

Peter Zehler

Pete,

Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer **************************** 

"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." 

********************************************************************** 

---------------------------------------------------------------------

---

From: Michael Sweet <[email-masked]>
Date: Tue, 18 Feb 2014 08:09:44 -0500

Soma,

On Feb 14, 2014, at 6:07 PM, Soma Meiyappan <[email-masked]> wrote:
> Gentlemen,
>  
> The proposed Scan2 seems to bear a resemblance to FaxOut’s send-from-glass capabilities. Of course, one may consider a slight difference in scan capabilities between a scan service and a faxout service for the scan service to be a more suitable host for non-fax digital sends. However, should we consider any potential duplication of features between IPP services and a confusion between clients/servers on the service where this functionality will be made available? I agree that it does not prevent device manufacturers from implementing similar functionality through both IPP services. But I wanted to hear your thoughts on this.

This does come up from time to time.

FaxOut has certain legal requirements that Scan does not. So, you'll find in the Scan spec a prohibition to support tel:, fax:, and other facsimile schemes because the Scan service does not support the things required for it.

And while we don't have a similar prohibition in the FaxOut service for non-fax schemes, the addition of fax headers to the scanned documents may make using FaxOut as a replacement for Scan-to-Email (for example) less likely, unless the user truly wants to meet some arbitrary legal requirement (i.e. faxed documents are acceptable, digital documents are not...)

*If* there is a use case for discovery of fax services that can deliver using a particular URI scheme, we could add a corresponding "Fax2" TXT key, however nobody has asked for it...  (and FWIW, I would argue it would be more useful than the Scan2 key, since at least then you are discovering a delivery capability that cannot be easily reproduced in software...)

---

From: "Soma Meiyappan" <[email-masked]>
Date: Wed, 19 Feb 2014 01:22:27 -0800

Hi Mike,

Please find my thoughts inline with the prefix  [Soma]

Regards,
Somasundaram.

From: Michael Sweet [mailto:[email-masked]]
Sent: Tuesday, February 18, 2014 9:10 PM
To: Soma Meiyappan
Cc: Peter Zehler; [email-masked]
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?

Soma,

On Feb 14, 2014, at 6:07 PM, Soma Meiyappan <[email-masked]<mailto:[email-masked]>> wrote:
Gentlemen,

[Soma] When US federal TCPA law talks about fax headers/cover-page for fax machines/senders, should it be interpreted as being applicable for images transmitted through tel: and fax: schemes only and not to mailto:, ipp:, etc..., which inherently involve digital formats with richer meta-data capabilities? Document sent using these digital formats can identify the sender through a username that is embedded in the file (be it a PDF, TIFF or JPEG). If the IPP FaxOut specification should be interpreted such that the same content (incl the header) should be sent to all destinations (irrespective of the  destination scheme), then it makes the case for "push-scan" in IPP Scan stronger.
If the MFD's FaxOut processing can format the scanned data according to the destination scheme, then one can imagine the MFD sending the scanned data without fax like headers for destinations of specific schemes like mailto:, ipp:, http:. If this holds, then for a "push-scan" like workflow, the user will anyways provide digital destinations like mailto:, http:, etc.... only for the "FaxOut from glass job" and the same content from glass is both fax'ed and shared/archived through other schemes using IPP's FaxOut thereby making the case for "push-scan" in IPP Scan service weaker.

*If* there is a use case for discovery of fax services that can deliver using a particular URI scheme, we could add a corresponding "Fax2" TXT key, however nobody has asked for it...  (and FWIW, I would argue it would be more useful than the Scan2 key, since at least then you are discovering a delivery capability that cannot be easily reproduced in software...)
[Soma] If the case for PushScan exists and if a device supports it, then I can see Scan2 (or Fax2) in TXT record being useful especially with the discovery features in Wifi-Direct/P2P and in a kiosk like environment where the IPP client may not have other network connectivity. Anyways, I do not want to revisit that discussion on Scan2 TXT key now. While I will be concerned about the TXT record length if we were to include the schemes for the key, I hope that we will not breach the often used 400/512 byte limit for compatibility reasons.