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 No= rth Inc
http://sites.google.com/site/blueroofmusic=
http://sites.google.com/site/highnorthinc
mailto: bluero= ofmusic@gmail.com
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 <msweet@apple.com> wrote:

Pete,

I'm not su= re 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 - probab= ly better to browse for _ipp._tcp,_scan and then do a Get-Printer-Attribute= s to get the values you are looking for, *if* you really wanted an applicat= ion 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 m= ight 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...<= /div>

On Feb 10, 2014, a= t 3:13 PM, Zehler, Peter <Peter.Zehler@xerox.com> wrote:

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.

Wh= at do you think about a comma separated list of push URL schemes and an emp= ty list indicates a Pull only scanner?

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xe= rox.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: ipp-bounces@pwg.= org [mailto:ip= p-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Monday, February 10, 2014 3:07 PM
To: Zehler, Peter
Cc: IPP@pwg.org=
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?<= /u>

Pete,

I thought we were requiring pull scan and recom= mending push scan because low-end devices couldn't retry a push automat= ically. 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 spo= oling.

On Feb 10, 2014, at 2:59 PM, Zehler, Peter <= Peter.Zehler@xe= rox.com> wrote:

All,
&n= bsp;
I have conflicting notes. = ; I have some Push scan related attributes marked as conditionally mandator= y while Pull and Push scan are listed as required.

My op= inion is that Push and Pull scanning are mandated and therefore the Push re= lated attributes are also mandatory. For Push scanning the “htt= p”, “https”, “ftp” and “ftps URI = schemes MUST be supported.

Any o= bjections?

=
Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xe= rox.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

______________________________= _________________
ipp mailing list
ipp@pwg.org
http= s://www.pwg.org/mailman/listinfo/ipp

___________________________________________________= ______
Michael Sweet, Senior Printing System Engineer, PWG Chair

_________________________________________________________
Michael Sweet,= Senior Printing System Engineer, PWG Chair

___________________________________________= ____
ipp mailing list
ipp@pwg.org
http= s://www.pwg.org/mailman/listinfo/ipp

--089e013a11021afb4204f214e99f-- --===============0704495132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0704495132==-- From ipp-bounces@pwg.org Mon Feb 10 14:50:17 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73D21A08AB for ; Mon, 10 Feb 2014 14:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2CQ5r4WDYSo for ; Mon, 10 Feb 2014 14:50:01 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 71E261A05F2 for ; Mon, 10 Feb 2014 14:50:01 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 818649627; Mon, 10 Feb 2014 23:08:47 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by www.pwg.org (Postfix) with ESMTPS id E04BB9625 for ; Mon, 10 Feb 2014 23:08:45 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id j1so7680276iga.3 for ; Mon, 10 Feb 2014 14:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H19BnsH7NwbpZRggAZX2lWJSItnB3fRurND1qBu6Fkk=; b=P2o8oBUAEHUHG2VseqD9gff/ghBhNSwqc/Tu1v1WV9dZLgd5cXcXdexOR9kcTkgzyy OwU9CUv1uxkmYvOEPgGXMtwygU+VlanZ4MHpAjhJazfi6aZVFoOXn66FODhOGUjFmd1t L5VRW9GViaZvzRZwqd1EpdTrG0yf1nbK/citBGQ1f8YYZF17sftYHWk0NNVJIQdlbTLA vyKOHroJ8nWHdDXQwaFI2m3xqZXBKPpsRyjidpXw8Bc7drCN1GmAFoVPnRkTHHsMR6xp Dgk7r2dirbkfVaESWPDwSrbUIggPSMv9yxkkbe/LdS8bfFl9YV6+urawwnkWr54yJeYZ nPJQ== X-Received: by 10.50.230.20 with SMTP id su20mr17083687igc.18.1392072597960; Mon, 10 Feb 2014 14:49:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.1.207 with HTTP; Mon, 10 Feb 2014 14:49:37 -0800 (PST) In-Reply-To: <0F93490C-1E5A-4828-A2A0-5E18F940F276@apple.com> References: <0F93490C-1E5A-4828-A2A0-5E18F940F276@apple.com> From: Ira McDonald Date: Mon, 10 Feb 2014 17:49:37 -0500 Message-ID: To: Michael Sweet , Ira McDonald Cc: "" Subject: Re: [IPP] IPPScan vs IPPSIX issue for "document-format-accepted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0929372665==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0929372665== Content-Type: multipart/alternative; boundary=f46d04289aebb4006c04f2152825 --f46d04289aebb4006c04f2152825 Content-Type: text/plain; charset=ISO-8859-1 Hi, I concur with Mike about common use of document-format-accepted and operation/service-specific defaults for document-format. 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@gmail.com 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 1:33 PM, Michael Sweet wrote: > Pete, > > I will make sure to update the definition of document-format-accepted to > state it is an ordered list of formats to accept. > > The default value can be operation-specific, so I don't see the need to > create a new operation attribute just for scan - let's keep it > document-format-accepted for both IPPSIX and IPP Scan and document the > default value in the corresponding operations that use it. > > Thanks! > > > On Feb 10, 2014, at 1:00 PM, Zehler, Peter wrote: > > All, > > > > In IPP Scan the "document-format-accepted" operational attribute is an > *ordered* list of the preferred document format for the Scan Service to > emit for the Documents within a Job. The default behavior for this > attribute, if left unspecified, will be to emit the Document data in the > format specified by the "document-format-default" > > In IPP SIX no mention is made of the list being ordered. The default > value in IPP Scan is "document-format-default" whereas the default value in > IPP SIX is "document-format-supported". (That does not make sense to me.) > > > > I have changes the IPP Scan operational attribute name to > "scan-output-document-format-accepted" > > > > Pete > > > > Peter Zehler > > Xerox Research Center Webster > Email: Peter.Zehler@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 > > > > IPP Scan: > > 8.1.1 scan-output-document-format-accepted" (1 set of mimeMediaType) > > The OPTIONAL "scan-output-document-format-accepted" operation attribute > SHOULD be supplied by the client. It identifies the acceptable formats of > the Document data to be emitted by the IPP Scan Service for the Job. It is > an ordered list starting with the preferred format. The IPP Scan Service > MUST use the first supported value in the list. The default value that MUST > be used, if left unspecified by the request, is the value of the > "document-format-default". > > IPP SIX: > > The Proxy OPTIONALLY supplies this attribute. The Infrastructure Printer > MUST support this attribute. It identifies the acceptable formats of the > Document data to fetch. The default is the value of the > "document-format-supported" Printer attribute reported by the Proxy in a > previous Set-Output-Device-Attributes (section 5.7) request. > > _________________________________________________________________ > > > > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > > --f46d04289aebb4006c04f2152825 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

I concur with Mike ab= out common use of document-format-accepted and

operation/service-= specific defaults for document-format.

Cheers,

- Ira<= br>

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mo= bility Solutions WG
Chair - Linux Foundation Open Printing WG
Secreta= ry - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated E= xpert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094=
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434=

<= /div>

On Mon, Feb 10, 2014 at 1:33 PM, Michael= Sweet <msweet@apple.com> wrote:

Pete,

I will make su= re to update the definition of document-format-accepted to state it is an o= rdered list of formats to accept.

The default valu= e can be operation-specific, so I don't see the need to create a new op= eration attribute just for scan - let's keep it document-format-accepte= d for both IPPSIX and IPP Scan and document the default value in the corres= ponding operations that use it.

Thanks!

On Feb 10, 2014, at 1:00 PM, Zehler, Peter <Peter.Zehler@xerox.com&g= t; wrote:

All,

In IPP Scan the “documen= t-format-accepted” operational attribute is an ordered list of the preferred document format for the Scan Service t= o emit for the Documents within a Job. The default behavior for this = attribute, if left unspecified, will be to emit the Document data in the fo= rmat specified by the "document-format-default"

In IPP SIX no mention is made of the list being orde= red. The default value in IPP Scan is "document-format-default&q= uot; whereas the default value in IPP SIX is "document-format-supporte= d". (That does not make sense to me.)

I hav= e changes the IPP Scan operational attribute name to “scan-output-doc= ument-format-accepted”

Pete

Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler@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

IPP Scan:
8.1.1 &nb= sp; scan-output-document-format-accepted” (1 set of mimeMediaTy= pe)

The OPTIONAL “scan-output-document-format-= accepted” operation attribute SHOULD be supplied by the client. = It identifies the acceptable formats of the Document data to be emitted by the IPP Scan = Service for the Job. It is an ordered list starting with the preferred form= at. The IPP Scan Service MUST use the first supported value in the li= st. The default value that MUST be used, if left unspecified by the request, is the value of the "document-for= mat-default".

IPP SIX:<= u>
The P= roxy OPTIONALLY supplies this attribute. The Infrastructure Printer MUST su= pport this attribute. It identifies the acceptable formats of the Document data to fetch. The default is the value of the "document-format-suppo= rted" Printer attribute reported by the Proxy in a previous Set-Output= -Device-Attributes (section 5.7) request.
_________________________________________________________________=

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg= .org/mailman/listinfo/ipp

_________________________________________________________
Michael Sweet,= Senior Printing System Engineer, PWG Chair

_______________________________________________
ipp mailing list
ipp@pwg.org
http= s://www.pwg.org/mailman/listinfo/ipp

--f46d04289aebb4006c04f2152825-- --===============0929372665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0929372665==-- From ipp-bounces@pwg.org Mon Feb 10 14:52:40 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7CC1A0892 for ; Mon, 10 Feb 2014 14:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDiKwsq81Ii9 for ; Mon, 10 Feb 2014 14:52:34 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id CF7EE1A08AA for ; Mon, 10 Feb 2014 14:52:34 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id F38FB9627; Mon, 10 Feb 2014 23:11:20 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by www.pwg.org (Postfix) with ESMTPS id 29F159625 for ; Mon, 10 Feb 2014 23:11:19 +0000 (UTC) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id 3003C1400F; Mon, 10 Feb 2014 22:52:32 +0000 (UTC) Received: from G9W3615.americas.hpqcorp.net (16.216.186.50) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Feb 2014 22:51:24 +0000 Received: from G9W0739.americas.hpqcorp.net ([169.254.10.90]) by G9W3615.americas.hpqcorp.net ([16.216.186.50]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 22:51:24 +0000 From: "Kennedy, Smith (Wireless Architect)" To: Ira McDonald , Michael Sweet , "" Thread-Topic: [IPP] IPP Scan - Is Push scanning mandatory? Thread-Index: Ac8mmqBi8q2KEu3cQD+WG+3VxxvtAAAARYQAAAA47QAAAIqUAAAER9UAAACupAA= Date: Mon, 10 Feb 2014 22:51:23 +0000 Message-ID: <90F1DBF2-B67E-41DF-91DA-8B3EE5D4479F@hp.com> References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [16.216.12.28] MIME-Version: 1.0 Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2043067594==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============2043067594== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_C789ED98-D8D4-428C-9F02-6ACFC392820E"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_C789ED98-D8D4-428C-9F02-6ACFC392820E Content-Type: multipart/alternative; boundary="Apple-Mail=_7D22435A-1603-4225-B054-06E9B3AC7AEB" --Apple-Mail=_7D22435A-1603-4225-B054-06E9B3AC7AEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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=92s 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 wrote: > Hi Mike and Pete, >=20 > 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. >=20 > Cheers, > - Ira >=20 >=20 > 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@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 >=20 >=20 > On Mon, Feb 10, 2014 at 3:29 PM, Michael Sweet = wrote: > Pete, >=20 > 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. >=20 > 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... >=20 >=20 > On Feb 10, 2014, at 3:13 PM, Zehler, Peter = wrote: >=20 >> Mike, >>=20 >> =20 >> 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.=20 >>=20 >> =20 >> What do you think about a comma separated list of push URL schemes = and an empty list indicates a Pull only scanner? >>=20 >> =20 >> =20 >> Peter Zehler >>=20 >> Xerox Research Center Webster >> Email: Peter.Zehler@Xerox.com >> Office: +1 (585) 265-8755 >>=20 >> 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 >>=20 >> =20 >> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of = Michael Sweet >> Sent: Monday, February 10, 2014 3:07 PM >> To: Zehler, Peter >> Cc: IPP@pwg.org >> Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? >>=20 >> =20 >>=20 >> Pete, >>=20 >> =20 >>=20 >> 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. >>=20 >> =20 >>=20 >> =20 >>=20 >> On Feb 10, 2014, at 2:59 PM, Zehler, Peter = wrote: >>=20 >>=20 >>=20 >>=20 >> All, >>=20 >> =20 >>=20 >> I have conflicting notes. I have some Push scan related attributes = marked as conditionally mandatory while Pull and Push scan are listed as = required. >>=20 >> =20 >>=20 >> My opinion is that Push and Pull scanning are mandated and therefore = the Push related attributes are also mandatory. For Push scanning the = =93http=94, =93https=94, =93ftp=94 and =93ftps URI schemes MUST be = supported. >>=20 >> =20 >>=20 >> Any objections? >>=20 >> =20 >>=20 >> Peter Zehler >>=20 >> Xerox Research Center Webster >> Email: Peter.Zehler@Xerox.com >> Office: +1 (585) 265-8755 >>=20 >> 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 >>=20 >> =20 >>=20 >> _______________________________________________ >> ipp mailing list >> ipp@pwg.org >> https://www.pwg.org/mailman/listinfo/ipp >>=20 >> =20 >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >>=20 >> =20 >=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 >=20 > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp >=20 >=20 > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp --Apple-Mail=_7D22435A-1603-4225-B054-06E9B3AC7AEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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=92s 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?

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

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@gmail.com
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 <msweet@apple.com> 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...

On Feb 10, = 2014, at 3:13 PM, Zehler, Peter <Peter.Zehler@xerox.com> = wrote:

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

Xerox Research Center Webster
Email: Peter.Zehler@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: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Monday, February 10, 2014 3:07 PM
To: Zehler, Peter
Cc: IPP@pwg.org
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.

On Feb 10, 2014, at 2:59 PM, Zehler, Peter = <Peter.Zehler@xerox.com> = wrote:

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 = =93http=94, =93https=94, =93ftp=94 and =93ftps URI schemes MUST be = supported.

Any = objections?

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@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

___________________________________________= ____
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

_________________________________________________________
= Michael Sweet, Senior Printing System Engineer, PWG = Chair

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

=

__________________________________________= _____
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

_______________________________________________
ipp mailing = list
ipp@pwg.org
https://www.pwg.org/mailman= /listinfo/ipp

= --Apple-Mail=_7D22435A-1603-4225-B054-06E9B3AC7AEB-- --Apple-Mail=_C789ED98-D8D4-428C-9F02-6ACFC392820E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH2zCCB9cw gga/oAMCAQICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEFBQAwgfcxCzAJBgNVBAYTAlVT MSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9y aXR5IEcyMB4XDTEyMTEyNjAwMDAwMFoXDTE0MTEyNjIzNTk1OVowgZgxIDAeBgNVBAoUF0hld2xl dHQtUGFja2FyZCBDb21wYW55MSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVtcGxveWVl czEPMA0GA1UECxMGUy9NSU1FMRYwFAYDVQQDEw1TbWl0aCBLZW5uZWR5MSMwIQYJKoZIhvcNAQkB FhRzbWl0aC5rZW5uZWR5QGhwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmo HmmwCMk0tCSI1w6tYppeJX3YINwFC5wUIhCt8HcRW/Ass9n7BxP1MpBUScmYpaQOjFI+n6JueqNN lmHysW9wFG8FiSxowAf2C6cN+kmrV1MOzprrpjZZTB979lqRD/UG5RCo4BNy3aTTtqMFk7JkrL1Q H8yLa5IOgUd36N7bK3+nSz6W3X3jo5G8Eax5xJvwCioOQzzmclRKpoDRKFT35bHptUCD0VR7IY74 9Ik7+A4RBp52w7zKYrs6N59Hy0PxxEzOsQImUC7++mhRJtg5AdX75wAKb665v3b4RZjJBMQhjYdU 8Al3e/iq362nUqJmrFbNhpM9LSapjpbCm7ECAwEAAaOCA7owggO2MB8GA1UdEQQYMBaBFHNtaXRo Lmtlbm5lZHlAaHAuY29tMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAw TqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFu eVNNSU1FRzIvTGF0ZXN0Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAd BgNVHQ4EFgQU2ugcyk1Ph3Uvd67i/95+2TE174IwggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsG AQUFBzABhhtodHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQL EydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MIIB PQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBD b21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3JyZXNwb25kIHdp dGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0ZS4gSXNzdWVkIHRvIGZhY2ls aXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJl ZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwME MEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG 9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEFBQADggEBAImyDkwpuUnbTsboOwpQAPQ4 M1jbZkfWS/mLo6oj6XOWApq9IQ1jkwowCWwwCA3F3wCbKQGphJ8HdLaVGY9AznOEQoixLHx9rnIT aq9lFeagCZiqtFq6/i33etWRb6dXp3FZYn9ikhYv74Ewil/ue61VqW9vOAZq51Wt9JznLmVSkJN1 1A4oJxNL8/jiK82tSXMkUHe07VbZUUF+t609D979rvVK68sw6P+cDe+46gy6oM9LHtINt8Fclro/ 45hQe0FdW1A1dmyx4dyKW/SbRK4uw5c0nXvaZn0Wrlnq2Rxm/wCNKnGxAtp0ir7/7ubR6GjB3xuf BjNLp57JgbuFIg4xggTeMIIE2gIBATCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXds ZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx NTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi 82zI/6Xyi7FlMAkGBSsOAwIaBQCgggKlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MDIxMDIyNTEyM1owIwYJKoZIhvcNAQkEMRYEFGlxqMMjyKG4TFAGhXaSH1cQ UQS4MIIBHwYJKwYBBAGCNxAEMYIBEDCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXds ZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx NTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi 82zI/6Xyi7FlMIIBIQYLKoZIhvcNAQkQAgsxggEQoIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIC EDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEBBQAEggEAXoCz/d0BNCUZZ8wKmZ/E6oKgtHFq TI2FsuKE6Kr/j5X1hd7Y/InFLf2eU7/uqFvEDA1osUUrG6+hmw7mu1Avc55SfmYyhqqqbrfumzJc Od8eu+qqF3KW/FT1jCcO3D4BbKX4FJIXLt7TVSz8eEA4LSwtqU/cV5z2fuuyN40JvgXUwRLBLott n4Kk1uICgJuAeawtz5J5Z9LfunteaXRAJ3mFfKYXhFCZfWJptOdrOmuz38rwEAgS25sBd0mikxu6 0jBeZlnDjpPf2K6pFaFBd04QtB2njIeStqDlMcQpsxmKIZVtyQo5cu8jOI2j8UGZhKFWE1pIMVti Jo4LqWtf+AAAAAAAAA== --Apple-Mail=_C789ED98-D8D4-428C-9F02-6ACFC392820E-- --===============2043067594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============2043067594==-- From ipp-bounces@pwg.org Tue Feb 11 07:13:44 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490611A0376 for ; Tue, 11 Feb 2014 07:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiL4O-chAaLa for ; Tue, 11 Feb 2014 07:13:41 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id C932D1A03E6 for ; Tue, 11 Feb 2014 07:13:41 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 79A41959E; Tue, 11 Feb 2014 15:32:29 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by www.pwg.org (Postfix) with ESMTPS id EE26E958E for ; Tue, 11 Feb 2014 15:32:27 +0000 (UTC) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0U009P57MJSD61@mail-out.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 07:13:37 -0800 (PST) X-AuditID: 11807165-f79076d0000015d9-71-52fa3e214794 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id D0.4A.05593.12E3AF25; Tue, 11 Feb 2014 07:13:37 -0800 (PST) Received: from [17.153.99.181] (unknown [17.153.99.181]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0U00J687MMBL00@sesame.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 07:13:37 -0800 (PST) From: Michael Sweet In-reply-to: Date: Tue, 11 Feb 2014 10:13:35 -0500 Message-id: <52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com> References:

To: Ira McDonald X-Mailer: Apple Mail (2.1873) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUi2FDcoKto9yvIoPGuucWxfS9ZHBg95i2e zhTAGMVlk5Kak1mWWqRvl8CVsXnSQpaCe0EV+659YGpgPOnbxcjJISFgIrHx3DdmCFtM4sK9 9WxdjFwcQgJ9TBIvGp9BOTOZJCa83swKUiUsYCnxsOUxmM0roCcxcd8MJpAiZoEpjBIv1l1l AkmwCahJ/J7UB1bEKRAs8W7NcRYQm0VAVWLrN4hmZgE3idb/s5khBtlIbDzUxQSx7QCTRNv7 zexdjBwcIgJaEkueK0KcJyvx7/Rp5gmM/LOQ7J6FbPcsoBZmgSSJNftNZoGt0JZYtvA1M4St J/Gy6R07priuxMV1kxghbFOJJ2+3s0HY1hI/5zyCiitKTOl+yL6AkWsVo0BRak5ipbleYkFB Tqpecn7uJkZwNBSm7mBsXG51iFGAg1GJh1fB8meQEGtiWXFl7iFGFaARjzasvsAoxZKXn5eq JMKrpvYrSIg3JbGyKrUoP76oNCe1+BCjNAeLkjgvV+rXICGB9MSS1OzU1ILUIpgsEwenVANj QPDN+vWct2odH4luXuOnY1pbJC6yfwHDqcW++8pFfHkLZSZfyZixKLOZz+cy88HiPrlPgtGz L0iYi/kuVz6qbmv+5k3xZbaJUfMS9ryq45Ku0pTl/bFv/a2cvu9mdVP9GVezbFi9KWq/8dpN iy8lTmOXqPlrtP7WLF59i0Xr9wp+dtjyYZKrEktxRqKhFnNRcSIALI/Bd44CAAA= Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1899945103==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1899945103== Content-type: multipart/signed; boundary="Apple-Mail=_84ACFD25-2B82-4D10-99D9-FF0EC073F830"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_84ACFD25-2B82-4D10-99D9-FF0EC073F830 Content-Type: multipart/alternative; boundary="Apple-Mail=_1EB22EC3-2E92-45AC-8E7F-47D27B916ED0" --Apple-Mail=_1EB22EC3-2E92-45AC-8E7F-47D27B916ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ira, On Feb 10, 2014, at 5:31 PM, Ira McDonald = wrote: > Hi Mike and Pete, >=20 > 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 --Apple-Mail=_1EB22EC3-2E92-45AC-8E7F-47D27B916ED0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Ira,

On Feb 10, 2014, at 5:31 PM, = Ira McDonald <blueroofmusic@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

= --Apple-Mail=_1EB22EC3-2E92-45AC-8E7F-47D27B916ED0-- --Apple-Mail=_84ACFD25-2B82-4D10-99D9-FF0EC073F830 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjExMTUxMzM1WjAjBgkqhkiG9w0BCQQxFgQUXWib38tj5581f50W+hmnbRDy bjEwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQB8MSWZnuRDs8bxLon/ltj55qaRx8mjmQYLLLplb/qyllSq67Gmu7YMiO29sGTUPDGGmBTdXenS OeAw2LpZtFRM7VtBQV0FQnBui+hm99WD2lP1Ed6JF87KWMZfornOk1J77T0CjHuePWH2IQtztEe6 4ik90qQmVmZVGpWBej839Zz5P5smafBdvmG9XLZ55KzC6abiVYVHBRZw9m7IN9XK/zLd3eRWEg4K +WFx1aMrY5qab+X8d5NgoJn1nrA4fbW8976vE0HPQ5wkxD3dOi1rVAaTpuoz0YaXkBxtx7EqtTHq r518rS/GlWFpToGM2lGh8jA4j7z3VNEXa30+cP2ZAAAAAAAA --Apple-Mail=_84ACFD25-2B82-4D10-99D9-FF0EC073F830-- --===============1899945103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1899945103==-- From ipp-bounces@pwg.org Tue Feb 11 07:28:18 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F354D1A0412 for ; Tue, 11 Feb 2014 07:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwzkmsaVmw0s for ; Tue, 11 Feb 2014 07:28:15 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9D61A0381 for ; Tue, 11 Feb 2014 07:28:15 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 5E3509694; Tue, 11 Feb 2014 15:47:04 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by www.pwg.org (Postfix) with ESMTPS id 849089693 for ; Tue, 11 Feb 2014 15:47:02 +0000 (UTC) MIME-version: 1.0 Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0U007E889TE1X0@mail-out.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 07:28:12 -0800 (PST) X-AuditID: 1180715a-f79cb6d00000168c-2c-52fa418cc1b1 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id F2.01.05772.C814AF25; Tue, 11 Feb 2014 07:28:12 -0800 (PST) Received: from [17.153.99.181] (unknown [17.153.99.181]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0U00JPR8AXBL00@sesame.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 07:28:11 -0800 (PST) From: Michael Sweet In-reply-to: <90F1DBF2-B67E-41DF-91DA-8B3EE5D4479F@hp.com> Date: Tue, 11 Feb 2014 10:28:10 -0500 Message-id: <374DEAF8-A8D1-41EC-B566-2DC899863A71@apple.com> References:

<90F1DBF2-B67E-41DF-91DA-8B3EE5D4479F@hp.com> To: "Kennedy, Smith (Wireless Architect)" X-Mailer: Apple Mail (2.1873) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUi2FDcoNvj+CvIYPpPPotj+16yODB6zFs8 nSmAMYrLJiU1J7MstUjfLoErY8aF3awF33MqLmy6y97AuD65i5GTQ0LARGLOkjVMELaYxIV7 69m6GLk4hAT6mCQmL/7PAuHMZJJ4cuw+K0iVsIClxMOWx2A2r4CexMR9M5hAipgFpjBKnF/+ jREkwSagJvF7Uh9YEaeAlcSpTRvYQGwWAVWJrQtOsoDYzAKeEo2rnzBCDLKReHllHSvEtg9M Ehv//AK7SUTAQeL5kk8sEPfJSvw7fZp5AiP/LCTLZyFbPgtscJLEpefX2SBsbYllC18zQ9gG Ek87X7FiiutLvHk3hwnCNpV48nY7VK+1xM85j6BmKkpM6X7IvoCRaxWjQFFqTmKlmV5iQUFO ql5yfu4mRnBEFEbtYGxYbnWIUYCDUYmHd8P2n0FCrIllxZW5hxhVgEY82rD6AqMUS15+XqqS CK+a2q8gId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxcqV+DhATSE0tSs1NTC1KLYLJMHJxSDYw5 y2TN7T/5pEg+WrrvwBz3ZLVnxxs54tbZavIFqUwWX2uQ/FdBUzsqRVBDXWXZ+tz9Mi86jO8n 890RenC44pmI58qm5acrTbRcDVKnrL4tkRuzWvCvEKtAh2vEFNeYWIu7y1/by7fbH1vcF2qV wfZ+R9nc92Z9r8X/lq29kfYnTstZY25pvRJLcUaioRZzUXEiAJ1IFeaQAgAA Cc: "" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0986032476==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0986032476== Content-type: multipart/signed; boundary="Apple-Mail=_16D48AC5-89CB-4EA0-B567-EFD3968128CC"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_16D48AC5-89CB-4EA0-B567-EFD3968128CC Content-Type: multipart/alternative; boundary="Apple-Mail=_C6E89104-4C98-45DB-8AD0-5799D010C402" --Apple-Mail=_C6E89104-4C98-45DB-8AD0-5799D010C402 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Smith, On Feb 10, 2014, at 5:51 PM, Kennedy, Smith (Wireless Architect) = wrote: > Hi there, >=20 > I agree that Push should be optional. >=20 > Would we imagine that a client would filter on the Push URI schemes it = supported? If so, Pete=92s 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 TXT record vs. = having to do a follow-up interrogation, which is generally expensive and = not desirable. 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...) _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_C6E89104-4C98-45DB-8AD0-5799D010C402 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Smith,

On Feb 10, 2014, at 5:51 = PM, Kennedy, Smith (Wireless Architect) <smith.kennedy@hp.com> = wrote:

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=92s = 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 TXT record vs. having to do a follow-up interrogation, = which is generally expensive and not = desirable.

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

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_C6E89104-4C98-45DB-8AD0-5799D010C402-- --Apple-Mail=_16D48AC5-89CB-4EA0-B567-EFD3968128CC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjExMTUyODEwWjAjBgkqhkiG9w0BCQQxFgQUkynhxS66a9oqIq4kCG9u8HQy 9ukwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQCUGlvTnvI/ToDtbr9HoVJtU7Hyol+swE9u33PtV7Nu9PU/y4I7Yh14MNyNqYWf/ar5h9EGmYKH uIIJ7b1gCXWbIc4IIWDxjgtYKh6YwlUaPx2iasGiJx0j8NLqrFen94cGSFS1sk8yqYE3RrlsWKqN bPaPmCBiVlpp5x28yyw8bgsKtQJbVp5I6lVmm2mhd001EA0eFPwVehV9MddAbhvOrJhaTW20gTDW bXN8G700EoluRPpzkfbEBDBWH9NFTYtD6swrZpFMdW9fBD44zjXK0uzpAK4rsHiu8Q4w4cdJexD7 qvd7FdXu+Pr8KIrCPpgy+KFEFQ/iLiufRwO97cfrAAAAAAAA --Apple-Mail=_16D48AC5-89CB-4EA0-B567-EFD3968128CC-- --===============0986032476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0986032476==-- From ipp-bounces@pwg.org Tue Feb 11 07:55:48 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738F21A050B for ; Tue, 11 Feb 2014 07:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8DFWqQOJmlC for ; Tue, 11 Feb 2014 07:55:46 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECD21A050A for ; Tue, 11 Feb 2014 07:55:46 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id D89F296A3; Tue, 11 Feb 2014 16:14:34 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by www.pwg.org (Postfix) with ESMTPS id 974D69685 for ; Tue, 11 Feb 2014 16:14:32 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id uq10so9028718igb.5 for ; Tue, 11 Feb 2014 07:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cAqzR3mmjQ4U0pqKjPisVCtjuHQM0NGdFjiNXPWLl6I=; b=KxYFhj9DZj0FYplU+OnP7CBCUZmfbhs3LVjDfoogUikR45JNuHgX9qJLchUpsQptvZ LWmma2nJ1iV+dYb42SB/1CKs7G5N4hr18jWDzyljQkfnOtw3/JrQHhhrrgTgzHMFhHY7 silh8+kLJB8udGEliSwmYtKMtZghWdAXuJ0PjBfwC/PkaSgy/4daKe7AArlCVyugRTXx vYaHnogEh4xZGKgD9vNyaivzGFe4XmFIbJ8vj61RYmlk+bmddZUWoAIdtt+R+yI88RTz Kl5kdU9icuLuV7RaKvnMAmoUaC/sjuMuQyXklx2Em1wyU5EpXuY1Y3hhHSb3gIQ2Bg3E t2cg== X-Received: by 10.50.60.105 with SMTP id g9mr20449160igr.14.1392134142183; Tue, 11 Feb 2014 07:55:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.1.207 with HTTP; Tue, 11 Feb 2014 07:55:21 -0800 (PST) In-Reply-To: <52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com> References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com> From: Ira McDonald Date: Tue, 11 Feb 2014 10:55:21 -0500 Message-ID: To: Michael Sweet , Ira McDonald Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1814313119==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1814313119== Content-Type: multipart/alternative; boundary=047d7b10caa506514e04f2237df7 --047d7b10caa506514e04f2237df7 Content-Type: text/plain; charset=ISO-8859-1 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@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 wrote: > Ira, > > On Feb 10, 2014, at 5:31 PM, Ira McDonald 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 > > --047d7b10caa506514e04f2237df7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Mike,

Crossed wires?

The mobile client may have very limited local storage and there= fore want
the MFD to push a large scan output file directly to a network= server.=A0 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 Mobi= lity Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary= - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Pri= nting Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High No= rth Inc
http://sites.google.com/site/bluero= ofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434

On Tue, Feb 11, 2014 at 10:13 AM, Michae= l Sweet <msweet@apple.com> wrote:

Ira,

= On Feb 10, 2014, at 5:31 PM, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi Mike and Pete,

What ab= out 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=A0Engineer, PWG Chair

--047d7b10caa506514e04f2237df7-- --===============1814313119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1814313119==-- From ipp-bounces@pwg.org Tue Feb 11 08:18:15 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958F01A061F for ; Tue, 11 Feb 2014 08:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ezvf7s7mQyJD for ; Tue, 11 Feb 2014 08:18:13 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id A1B731A062D for ; Tue, 11 Feb 2014 08:18:13 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 85DAE96AF; Tue, 11 Feb 2014 16:37:02 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by www.pwg.org (Postfix) with ESMTPS id 7F5E696AE for ; Tue, 11 Feb 2014 16:37:01 +0000 (UTC) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0U00D8FALW2A20@mail-out.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 08:18:11 -0800 (PST) X-AuditID: 11807143-f79f66d0000015d3-4a-52fa4d437fa7 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id F8.B4.05587.34D4AF25; Tue, 11 Feb 2014 08:18:11 -0800 (PST) Received: from [17.153.99.181] (unknown [17.153.99.181]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0U00JT2AM9BL20@sesame.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 08:18:11 -0800 (PST) From: Michael Sweet In-reply-to: Date: Tue, 11 Feb 2014 11:18:09 -0500 Message-id: <27516954-64DD-4042-A984-39D975BD7FA8@apple.com> References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com> To: Ira McDonald X-Mailer: Apple Mail (2.1873) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FDcoOvs+yvI4MtfVYtj+16yODB6zFs8 nSmAMYrLJiU1J7MstUjfLoEr486SiUwFU4Mq3h1xbGD87tPFyMEhIWAi0f9JrIuRE8gUk7hw bz1bFyMXh5BAH5PE2fktzBDOTCaJc2+XsIFUCQtYSjxsecwKYvMK6ElM3DeDCaSIWWAKo8S0 J3dZQBJsAmoSvyf1sYJs4BQIlni+NAMkzCKgKtG2/C4ziM0s4CbR+n82M0gJr4CNxIMHoRC7 djFLXNv8BCwuIqAlseS5IsRxshL/Tp9mnsDIPwvJ5lnINs8CG5skcWXOAzYIW1ti2cLXzBC2 nsTLpnfsmOK6EhfXTWKEsE0lnrzdDtVrLfFzziOouKLElO6H7AsYuVYxChSl5iRWGuklFhTk pOol5+duYgTHQaHzDsZjy6wOMQpwMCrx8EZ4/woSYk0sK67MPcSoAjTi0YbVFxilWPLy81KV RHjV1IDSvCmJlVWpRfnxRaU5qcWHGKU5WJTEeblSvwYJCaQnlqRmp6YWpBbBZJk4OKUaGMN+ 7d2u3ZLzeSv7XJWdDTGzA8zfeNbc5N28ZYHAncPn7T3nHP27pu3e1Kmrdx4+vTBzYfs5mZPn wy7KX2Vk7PwUMJO15a6GrL9nY53T5FusMdl1fx17WaZum7w5RHDOkjCX3rWFyk0bly/+O2V3 fo+QXK7sw9eqnVcqpH2ufFl4cGbJfdGcQ2FKLMUZiYZazEXFiQA6HuMOiwIAAA== Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034433244==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1034433244== Content-type: multipart/signed; boundary="Apple-Mail=_48B7C8A7-B6D9-4AF3-A0E3-1B6B570537E6"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_48B7C8A7-B6D9-4AF3-A0E3-1B6B570537E6 Content-Type: multipart/alternative; boundary="Apple-Mail=_4C630989-A35E-447B-8CC2-54B924C93BCB" --Apple-Mail=_4C630989-A35E-447B-8CC2-54B924C93BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ira, On Feb 11, 2014, at 10:55 AM, Ira McDonald = wrote: > Hi Mike, >=20 > Crossed wires? >=20 > 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. 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. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_4C630989-A35E-447B-8CC2-54B924C93BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Ira,

On Feb 11, 2014, at 10:55 AM, = Ira McDonald <blueroofmusic@gmail.com> = wrote:

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.

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.

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_4C630989-A35E-447B-8CC2-54B924C93BCB-- --Apple-Mail=_48B7C8A7-B6D9-4AF3-A0E3-1B6B570537E6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjExMTYxODEwWjAjBgkqhkiG9w0BCQQxFgQU0zkBJqUhTfohLDHTtA5M94yr 49MwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQCjGL6GNlCCOgtDAbOyrjtPT0zZAwjqIi+zTvtvrz4XXOL2NebQ90rcG611tO4vQjr7mKxK7q5e vj0pOKlboZbdwIjlM8ihI2maVfIN/eL1lbSzEIgxFkROSnX+3wHcTRgQ+FA5kVr1E80NZLZ3qDw+ JbG1jF5pXInjFN8T2emjfR58hoKZ87Z7iDp0dmjKrQu6fb6gFGmXRenfj2LjtYSg4Q4GicpoBKpj 2IJrezEYqDhi7ShcPZRf8imVIS0rbZJCej+HS9Ru8B0MQIKDPsU0YBmmGnd0aEm43RZtX3QwMPAE fUFLE57sBsizH9M/gGX02L+R2T38CPq4Ldyo5jcnAAAAAAAA --Apple-Mail=_48B7C8A7-B6D9-4AF3-A0E3-1B6B570537E6-- --===============1034433244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1034433244==-- From ipp-bounces@pwg.org Tue Feb 11 08:38:41 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7471A0641 for ; Tue, 11 Feb 2014 08:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ghu9ZjsXztmC for ; Tue, 11 Feb 2014 08:38:36 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 338FE1A0614 for ; Tue, 11 Feb 2014 08:38:36 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 333EF96C0; Tue, 11 Feb 2014 16:57:25 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from USA7109MR006.ACS-INC.COM (usa7109mr006.acs-inc.com [63.87.171.175]) by www.pwg.org (Postfix) with ESMTPS id 0621F96BF for ; Tue, 11 Feb 2014 16:57:23 +0000 (UTC) Received: from usa7109ht003.na.xerox.net ([13.41.230.29]) by USA7109MR006.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 11 Feb 2014 10:38:22 -0600 Received: from USA7109MB004.na.xerox.net ([169.254.4.205]) by USA7109HT003.na.xerox.net ([13.41.230.29]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 10:38:17 -0600 From: "Zehler, Peter" To: Ira McDonald , Michael Sweet Thread-Topic: [IPP] IPP Scan - Is Push scanning mandatory? Thread-Index: Ac8mmqBi8q2KEu3cQD+WG+3VxxvtAAAM2CsAAAyM3vD//6G1AIAAIj4AgAEX44CAAAurgIAAYsLQ Date: Tue, 11 Feb 2014 16:38:16 +0000 Message-ID: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.94] MIME-Version: 1.0 Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347521680==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0347521680== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_A4DE324D317E4F40A82CF077C7A9E1E34B9CC3USA7109MB004naxer_" --_000_A4DE324D317E4F40A82CF077C7A9E1E34B9CC3USA7109MB004naxer_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 destin= ation. (e.g., scanning a contract and delivering is securely to the destin= ation.) The ability to discover scanners that support push without interro= gating all the scanners in an enterprise environment is needed. We elimina= ted seven of the text records from the discovery message. This leaves 4 ma= ndatory, 2 conditional, and 2 optional. Adding this one should not be an u= ndue 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,f= tps,smb,ipp,ipps,mailto" which probably comes down to about 45 bytes for th= e text record. Pete Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@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@gmail.com] Sent: Tuesday, February 11, 2014 10:55 AM To: Michael Sweet; Ira McDonald Cc: Zehler, Peter; IPP@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. Tha= t'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@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 > wrote: Ira, On Feb 10, 2014, at 5:31 PM, Ira McDonald > 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 pus= h, the (mobile) client certainly *can* do it... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_A4DE324D317E4F40A82CF077C7A9E1E34B9CC3USA7109MB004naxer_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The use case of the const= rained client with minimal local storage should be accommodated. Howe= ver 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 destin= ation.) The ability to discover scanners that support push without in= terrogating 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 b= ytes for the text record.

Pete

<= /p>

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com=
Office: +1 (585) 265-8755

Mobile: +1 (585) 329-9508<= /span>
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.<= br> 800 Phillips Rd.
M/S 128-25E<= br> Webster NY, 14580-9701

<= /p>

From: Ira McDo= nald [mailto:blueroofmusic@gmail.com]
Sent: Tuesday, February 11, 2014 10:55 AM
To: Michael Sweet; Ira McDonald
Cc: Zehler, Peter; IPP@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 (Musicia= n / 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: bluero= ofmusic@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@apple.com&= gt; wrote:

Ira,

On Feb 10, 2014, at 5:31 PM, Ira McDonald <blueroofmusic@gmail.= com> wrote:

Hi Mike and Pete,

What about a simple TXT record discovery attribute f= or Push capability that's boolean?

Since a bunch of URI schemes are conditionally manda= tory 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...<= o:p>

= _________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--_000_A4DE324D317E4F40A82CF077C7A9E1E34B9CC3USA7109MB004naxer_-- --===============0347521680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0347521680==-- From ipp-bounces@pwg.org Tue Feb 11 08:49:12 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F971A05D2 for ; Tue, 11 Feb 2014 08:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xza9-RDmf0aa for ; Tue, 11 Feb 2014 08:49:09 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id ABA451A0619 for ; Tue, 11 Feb 2014 08:49:09 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id B8F2A970A; Tue, 11 Feb 2014 17:07:58 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by www.pwg.org (Postfix) with ESMTPS id AB9439707 for ; Tue, 11 Feb 2014 17:07:56 +0000 (UTC) MIME-version: 1.0 Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0U007F6C0YE101@mail-out.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 08:49:06 -0800 (PST) X-AuditID: 11807153-f799f6d000001862-a1-52fa54810946 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 32.94.06242.2845AF25; Tue, 11 Feb 2014 08:49:06 -0800 (PST) Received: from [17.153.99.181] (unknown [17.153.99.181]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0U00JD1C1RBL40@sesame.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 08:49:05 -0800 (PST) From: Michael Sweet In-reply-to: Date: Tue, 11 Feb 2014 11:49:04 -0500 Message-id: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com> To: Peter Zehler X-Mailer: Apple Mail (2.1873) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUi2FDcoNsU8ivIYOZ5Notj+16yODB6zFs8 nSmAMYrLJiU1J7MstUjfLoEro6dnG3PBhW2MFV2HNrM2MC5ZytjFyMkhIWAi8X76JWYIW0zi wr31bF2MXBxCAn1MEj9WPmWCcGYySTw9+44VpEpYwFLiYctjMJtXQE9i4r4ZTCA2s8AURonZ GzNBbDYBNYnfk/qAajg4OAX8JRacVAAJswioSvxd0scCUe4usefyeqgxNhIzj09ih9j1n1ni 2em/bCAJEQFNiYOH9kNdJyvx7/Rp5gmM/LOQrJ6FZPUsoHXMAkkS+9bqQYS1JZYtfM0MYRtI PO18xYopri/x5t0cqDGmEk/ebmeDsK0lfs55xAhhK0pM6X7IvoCRaxWjQFFqTmKlsV5iQUFO ql5yfu4mRnA0FAbvYPyzzOoQowAHoxIPb4T3ryAh1sSy4srcQ4wqQCMebVh9gVGKJS8/L1VJ hFdNDSjNm5JYWZValB9fVJqTWnyIUZqDRUmclyv1a5CQQHpiSWp2ampBahFMlomDU6qBcc/6 Tr0sTuOwdPck4bA7B7J+1WxbnWZWMHEBq6OOdChznlFSdpW/hVOuw7Uz+4/8Ep9Qsun34T2J v8zY05p1OqQNlPMnXT52JNC5SonDOZnxT8u+UxW8RwKzpaQu1TuujvvwUbOdk1vUcrlhXFx4 AN+ZG4/6fRr/tcZmrejbXf5IsqNCYbcSS3FGoqEWc1FxIgCS9bkUjgIAAA== Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0305206981==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0305206981== Content-type: multipart/signed; boundary="Apple-Mail=_4E8DFB14-5C40-46C0-B34B-9C2097E2F04A"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_4E8DFB14-5C40-46C0-B34B-9C2097E2F04A Content-Type: multipart/alternative; boundary="Apple-Mail=_81351A0B-CCD1-441E-A854-D560D6266999" --Apple-Mail=_81351A0B-CCD1-441E-A854-D560D6266999 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 = 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 = =93http,https,ftp,ftps,smb,ipp,ipps,mailto=94 which probably comes down = to about 45 bytes for the text record. > Pete > =20 > Peter Zehler >=20 > Xerox Research Center Webster > Email: Peter.Zehler@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 > =20 > From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20 > Sent: Tuesday, February 11, 2014 10:55 AM > To: Michael Sweet; Ira McDonald > Cc: Zehler, Peter; IPP@pwg.org > Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? > =20 > Hi Mike, >=20 > Crossed wires? >=20 > 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). >=20 > Cheers, > - Ira >=20 >=20 > 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@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 > =20 >=20 > On Tue, Feb 11, 2014 at 10:13 AM, Michael Sweet = wrote: > Ira, > =20 > On Feb 10, 2014, at 5:31 PM, Ira McDonald = wrote: > Hi Mike and Pete, >=20 > 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. > =20 > What would be the use case? > =20 > 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... > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 > =20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_81351A0B-CCD1-441E-A854-D560D6266999 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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@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 = =93http,https,ftp,ftps,smb,ipp,ipps,mailto=94 which probably comes down = to about 45 bytes for the text record.
Pete

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@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@gmail.com= ]
Sent: Tuesday, February 11, 2014 10:55 AM
To: Michael Sweet; Ira McDonald
Cc: Zehler, Peter; IPP@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<= /a>
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@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@apple.com> wrote:

Ira,

On Feb 10, 2014, at 5:31 PM, Ira McDonald = <blueroofmusic@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

= --Apple-Mail=_81351A0B-CCD1-441E-A854-D560D6266999-- --Apple-Mail=_4E8DFB14-5C40-46C0-B34B-9C2097E2F04A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjExMTY0OTA0WjAjBgkqhkiG9w0BCQQxFgQUsvsTYh9hnyLIFV/m1yfKDgry 7G4wgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQB9A1F6nJyOwCQucS8rDdAPh/FsnE4+3oxcNRq+9DzNiGIYPINTWBMMarTE++V85zeYkcoLLZlJ AVRwjp07BSWFBwqhdeiYTL/7/cRRHo5AuAYvBFwGPT163Wht93TkEoG7/HBCRJHrJ101zmQyjCxh OhR3VhjisUb47Naru3WWQl4o6dpFMN1a7qmRHMl7xMOoYpxF89/tOmZJve1z8VaZishT0zVQxRga M/f7vbV+BoEhts8p3uID6yEoD9OdG9taynoVbutbvxGv9I+gj/rquWyNhyeoTi88UlvEaTbEcdIZ 3j0rOm+g1dbBQiWZ3Wl80dU0OxEClQqiRGzL1qY+AAAAAAAA --Apple-Mail=_4E8DFB14-5C40-46C0-B34B-9C2097E2F04A-- --===============0305206981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0305206981==-- From ipp-bounces@pwg.org Tue Feb 11 08:57:49 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4BA1A0630 for ; Tue, 11 Feb 2014 08:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qS2Uqcpm8eN for ; Tue, 11 Feb 2014 08:57:45 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03A1A0627 for ; Tue, 11 Feb 2014 08:57:43 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 3B79D96C4; Tue, 11 Feb 2014 17:16:32 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by www.pwg.org (Postfix) with ESMTPS id 4C14796C0 for ; Tue, 11 Feb 2014 17:16:30 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id uy17so9141118igb.4 for ; Tue, 11 Feb 2014 08:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3jQFObPrqTQ674c9G+wqrR27lFzATPl0O3gdhXSm8SA=; b=LBoRcpGM6zgQiBy0sZ/hDUinlnEGN1SBcUFJt7lAeIAO6urWqC9f9/Bw15MdPoMsLc YdznvneE4tPbHD86ASuWnoMeac6H1uAmZOaKLQlrIHXsFjTJX1DQQdk0eIjO+285byDb H2gcLFeVuuu4xZYjiMuT4CBAQRN+/4SpnJJY/MoClfOwtarla7lhRtvFKcFViRIwdg3L +gd2x/uVOszf7arpAt6vpekKYOF7RxWm+e0mcdJMB1v3C0yAE7WuO+OtacOFIssTTK47 XfCsYQ0yfhas47wqIZd/n8dkGbSp1fqM3dbWngSYBTZn9jli1bdHyMixbbFy+S2r5ITK FNjw== X-Received: by 10.50.60.105 with SMTP id g9mr20804869igr.14.1392137859734; Tue, 11 Feb 2014 08:57:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.1.207 with HTTP; Tue, 11 Feb 2014 08:57:19 -0800 (PST) In-Reply-To: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

From: Ira McDonald Date: Tue, 11 Feb 2014 11:57:19 -0500 Message-ID: To: Michael Sweet , Ira McDonald Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1569246621==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1569246621== Content-Type: multipart/alternative; boundary=047d7b10caa59ba72c04f2245a34 --047d7b10caa59ba72c04f2245a34 Content-Type: text/plain; charset=ISO-8859-1 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 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@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 11:49 AM, Michael Sweet wrote: > 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 > 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@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@gmail.com] > > *Sent:* Tuesday, February 11, 2014 10:55 AM > *To:* Michael Sweet; Ira McDonald > *Cc:* Zehler, Peter; IPP@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@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 wrote: > > Ira, > > > > On Feb 10, 2014, at 5:31 PM, Ira McDonald 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 > > --047d7b10caa59ba72c04f2245a34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 th= e emerging countries

markets. These devices definitely do *n= ot* have 8GB, high-speed CPUs, or

large batteries.

<= div>

Radio usage controls battery life. Acting as a pull an= d forward agent for large
files is a seriously poor idea for very low-en= d phones.

Cheers,

- Ira

Ira McDonald (Musician / Software A= rchitect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux = Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group<= br> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated E= xpert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094=
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434=

<= /div>

On Tue, Feb 11, 2014 at 11:49 AM, Michae= l Sweet <msweet@apple.com> wrote:

Pete,

Please provide= your definition of a constrained network scan client with minimal local st= orage.

On Feb 11, 2014, at 11:38 AM, Zehler, Peter <Peter.Zehler@xerox.com> wrote:=

All,
The use case of = the constrained client with minimal local storage should be accommodated.&n= bsp; 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 destin= ation.) The ability to discover scanners that support push without in= terrogating 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 b= ytes for the text record.
Pete

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xe= rox.com
Office: +1 (585) 265-8755=

Mobile: +1 (585) 329= -9508
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.<= br> 800 Phillips Rd.
M/S 128-25E<= br> Webster NY, 14580-9701

From: Ira McDonald [mailto:blueroofmusic@gmail.co= m]
Sent: Tuesday, February 11, 2014 10:55 AM
To: Michael Sweet; Ira McDonald
Cc: Zehler, Peter; = IPP@pwg.org
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?<= /u>

Hi Mike,<= u>

Crossed wires?<= u>

The mobile clie= nt 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 (Mu= sician / 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: bluero= ofmusic@gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094<= br> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Tue, Feb 11, 2014 at 10:13 AM, Michael Sweet= <msweet@apple.com= > wrote:

Ira,

On Feb 10, 2014, at 5:31 PM, Ira McDonald <<= a href=3D"mailto:blueroofmusic@gmail.com" target=3D"_blank">blueroofmusic@g= mail.com> wrote:

Hi Mike and Pete= ,

What about a simple TXT record discovery attri= bute 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 prin= ter - 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 certainl= y *can* do it...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

_________________________________________________________
Michael Sweet,= Senior Printing System Engineer, PWG Chair

--047d7b10caa59ba72c04f2245a34-- --===============1569246621== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1569246621==-- From ipp-bounces@pwg.org Tue Feb 11 09:37:55 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE51A0656 for ; Tue, 11 Feb 2014 09:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PliQupF6LKu for ; Tue, 11 Feb 2014 09:37:53 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4F31A05CD for ; Tue, 11 Feb 2014 09:37:53 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 431F69769; Tue, 11 Feb 2014 17:56:42 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by www.pwg.org (Postfix) with ESMTPS id 715DE9768 for ; Tue, 11 Feb 2014 17:56:41 +0000 (UTC) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0U0074AE8C6Y70@mail-out.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 09:37:31 -0800 (PST) X-AuditID: 11807166-f79c26d000001623-6a-52fa5fdb2566 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 63.0E.05667.BDF5AF25; Tue, 11 Feb 2014 09:37:31 -0800 (PST) Received: from [17.153.99.181] (unknown [17.153.99.181]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0U00CWOEAHAO00@sesame.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 09:37:31 -0800 (PST) From: Michael Sweet In-reply-to: Date: Tue, 11 Feb 2014 12:37:30 -0500 Message-id: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

To: Ira McDonald X-Mailer: Apple Mail (2.1873) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUi2FDcoHs7/leQQf9RU4tj+16yODB6zFs8 nSmAMYrLJiU1J7MstUjfLoEr49iP50wFh+MqLv1tZGpgnBrexcjJISFgIrH15R52CFtM4sK9 9WxdjFwcQgJ9TBLPP5xggnBmMklsXNHKCFIlLGAp8bDlMSuIzSugJzFx3wywImaBKYwSE3+e YwZJsAmoSfye1AdWxCkQLLG57wkLiM0ioCrx/MAVJhCbWcBNovX/bGaIQTYSkz72g9lCAj9Z JBZdi+1i5OAQEdCSWPJcEeI6WYl/p08zT2Dkn4Vk9Sxkq2cBtTALJEl8+6A5C2yDtsSyha+Z IWw9iZdN79gxxXUlLq6bxAhhm0o8ebudDcK2lvg55xFUXFFiSvdD9gWMXKsYBYpScxIrLfQS CwpyUvWS83M3MYJjoTBtB2PTcqtDjAIcjEo8vBHev4KEWBPLiitzDzGqAI14tGH1BUYplrz8 vFQlEV41NaA0b0piZVVqUX58UWlOavEhRmkOFiVxXq7Ur0FCAumJJanZqakFqUUwWSYOTqkG Rl4D7oM7VjXfYua+a7s6nuuyy/Id5yW6zB5a9HlL3sk2ab38anu4lvtTFR1FhrdPXtxtnd9c ZT7bz8l/Var1DfNQ7WrOX+FyBTUmDnsPbLOd8nR/0ukfpzNexhlvmvBt0ZdcNtlI31/iM4XZ P+/dFZi3MTwyI3bH4rgO85v3t2WoXq6+vCRfTImlOCPRUIu5qDgRAMRVzuSNAgAA Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0645710423==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0645710423== Content-type: multipart/signed; boundary="Apple-Mail=_2E823CB2-9A06-4FCB-B2B6-59789F101296"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_2E823CB2-9A06-4FCB-B2B6-59789F101296 Content-Type: multipart/alternative; boundary="Apple-Mail=_B5C4CA13-251D-4BE3-A2A5-3C9E36A06041" --Apple-Mail=_B5C4CA13-251D-4BE3-A2A5-3C9E36A06041 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ira, On Feb 11, 2014, at 11:57 AM, Ira McDonald = wrote: > Hi Mike, >=20 > I also want to hear Pete's definition of constrained network clients. >=20 > 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. 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 > files is a seriously poor idea for very low-end phones. 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. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_B5C4CA13-251D-4BE3-A2A5-3C9E36A06041 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Ira,

On Feb 11, 2014, at 11:57 AM, = Ira McDonald <blueroofmusic@gmail.com> = wrote:

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.

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
files is a = seriously poor idea for very low-end = phones.

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.

_________________________________________________________

Michael Sweet, Senior Printing = System Engineer, PWG Chair

= --Apple-Mail=_B5C4CA13-251D-4BE3-A2A5-3C9E36A06041-- --Apple-Mail=_2E823CB2-9A06-4FCB-B2B6-59789F101296 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjExMTczNzMwWjAjBgkqhkiG9w0BCQQxFgQUW3YN3t+EUpTg+F0wQ88ZJsMd l+swgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQAEUdDx6zqnN6v7shwRGUhmN73Xg0o1W15W1jlGg6GKDLGs+9OVQE5l2NrXhNoqbqg3o5ncrOe8 LOnvGJJzO9HNR+G19aOj7pE8+N3xJKL2J7Qq9C6ocmC3yU8IZ5zOh72Ak8aFbieSsOaOJqhK0jmT RRWEySsBlHQ/xoEufgVw2itAeGy4h+Y6GLFz64kJ1i7E39nV1hyExMtjB1z1jpm3knB4iK82lO/t iaYj7eJhYU16BX1myiTAWHFmTSC4/FCQVvzcyGvXA9pKk3Sx6g5pbOO4Tzvn21sWcO6FPdDVz6+j 2eP9D3M3w/en9uCu2tKH+HKqLOcvxcI09OMvleRaAAAAAAAA --Apple-Mail=_2E823CB2-9A06-4FCB-B2B6-59789F101296-- --===============0645710423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0645710423==-- From ipp-bounces@pwg.org Tue Feb 11 10:13:12 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96A61A066C for ; Tue, 11 Feb 2014 10:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvlvVSETivlq for ; Tue, 11 Feb 2014 10:13:04 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id B5B791A06AD for ; Tue, 11 Feb 2014 10:13:03 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id ED2DC9771; Tue, 11 Feb 2014 18:31:52 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from USA7109MR006.ACS-INC.COM (usa7109mr006.acs-inc.com [63.87.171.175]) by www.pwg.org (Postfix) with ESMTPS id 491A6976F for ; Tue, 11 Feb 2014 18:31:51 +0000 (UTC) Received: from usa7109ht001.na.xerox.net ([13.41.230.31]) by USA7109MR006.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 11 Feb 2014 12:13:00 -0600 Received: from USA7109MB004.na.xerox.net ([169.254.4.205]) by USA7109HT001.na.xerox.net ([13.41.230.31]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 12:12:59 -0600 From: "Zehler, Peter" To: Michael Sweet Thread-Topic: [IPP] IPP Scan - Is Push scanning mandatory? Thread-Index: Ac8mmqBi8q2KEu3cQD+WG+3VxxvtAAAM2CsAAAyM3vD//6G1AIAAIj4AgAEX44CAAAurgIAAYsLQ//+sQQCAAFSg0A== Date: Tue, 11 Feb 2014 18:12:59 +0000 Message-ID: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.94] MIME-Version: 1.0 Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0824730650==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0824730650== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_A4DE324D317E4F40A82CF077C7A9E1E34B9D78USA7109MB004naxer_" --_000_A4DE324D317E4F40A82CF077C7A9E1E34B9D78USA7109MB004naxer_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 po= int. 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 cli= ent. A pull from and MFD and then a push to a repository is not equivalen= t to an MFD pushing to a repository. I view this as an enterprise scannin= g requirement. Consumer and SMB targeted products can simply just implemen= t pull and avoid the push related overhead. But we need a scan solution th= at scales. Using discovery to filter basic relatively static capabilities i= s required. For printing that is things like color printing and supported = PDLs. For Scanning it is document feed capabilities and , for me, if it ca= n deliver a scan directly to a workflow (i.e., Push). Pete Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@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@apple.com] Sent: Tuesday, February 11, 2014 11:49 AM To: Zehler, Peter Cc: Ira McDonald; IPP@pwg.org Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? Pete, Please provide your definition of a constrained network scan client with mi= nimal local storage. On Feb 11, 2014, at 11:38 AM, Zehler, Peter > 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 destin= ation. (e.g., scanning a contract and delivering is securely to the destin= ation.) The ability to discover scanners that support push without interro= gating all the scanners in an enterprise environment is needed. We elimina= ted seven of the text records from the discovery message. This leaves 4 ma= ndatory, 2 conditional, and 2 optional. Adding this one should not be an u= ndue 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,f= tps,smb,ipp,ipps,mailto" which probably comes down to about 45 bytes for th= e text record. Pete Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@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@gmail.com] Sent: Tuesday, February 11, 2014 10:55 AM To: Michael Sweet; Ira McDonald Cc: Zehler, Peter; IPP@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. Tha= t'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@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 > wrote: Ira, On Feb 10, 2014, at 5:31 PM, Ira McDonald > 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 pus= h, the (mobile) client certainly *can* do it... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_A4DE324D317E4F40A82CF077C7A9E1E34B9D78USA7109MB004naxer_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

<= /p>

My definition of constrai= ned network scan client with minimal local storage is a dual-core 1GH= z Snapdragon processor, a 4-inch WVGA screen, 512MB of memory and 2GB of storage. But accommodating low end clients was not my poi= nt.

<= /p>

The need Xerox has to dis= cover a Push scan service are scenarios such as I mentioned below. Th= is 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 scann= ing requirement. Consumer and SMB targeted products can simply just i= mplement pull and avoid the push related overhead. But we need a scan solution that scales. Using discovery to filter basic r= elatively static capabilities is required. For printing that is thing= s 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).

<= /p>

Pete

<= /p>

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com=
Office: +1 (585) 265-8755

Mobile: +1 (585) 329-9508<= /span>
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.<= br> 800 Phillips Rd.
M/S 128-25E<= br> Webster NY, 14580-9701

<= /p>

From: Michael = Sweet [mailto:msweet@apple.com]
Sent: Tuesday, February 11, 2014 11:49 AM
To: Zehler, Peter
Cc: Ira McDonald; IPP@pwg.org
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?=

Pete,

Please provide your definition of a constrained netw= ork scan client with minimal local storage.

On Feb 11, 2014, at 11:38 AM, Zehler, Peter <Peter.Zehler@xerox.com> wrote:=

All,

Pete

<= /p>

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com=
Office: +1 (585) 265-8755

Mobile: +1 (585) 329-9508<= /span>
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.<= br> 800 Phillips Rd.
M/S 128-25E<= br> Webster NY, 14580-9701

<= /p>

From: Ira McDo= nald [mailto:blueroofmusic@gmail= .com]
Sent: Tuesday, February 11, 2014 10:55 AM
To: Michael Sweet; Ira McDonald
Cc: Zehler, Peter; IPP@pwg.org Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?

Hi Mike,

Crossed wires?

Cheers,

- Ira

On Tue, Feb 11, 2014 at 10:13 AM, Michael Sweet <= msweet@apple.com&= gt; wrote:

Ira,

On Feb 10, 2014, at 5:31 PM, Ira McDonald <blueroofmusic@gmail.= com> wrote:

Hi Mike and Pete,

What about a simple TXT record discovery attribute f= or Push capability that's boolean?

Since a bunch of URI schemes are conditionally manda= tory anyway, that gets 90% of
the discovery need.

What would be the use case?

= _________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair<= /o:p>

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--_000_A4DE324D317E4F40A82CF077C7A9E1E34B9D78USA7109MB004naxer_-- --===============0824730650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0824730650==-- From ipp-bounces@pwg.org Tue Feb 11 12:09:35 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683371A0762 for ; Tue, 11 Feb 2014 12:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMHaSm5ljXKN for ; Tue, 11 Feb 2014 12:09:30 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 71A581A074F for ; Tue, 11 Feb 2014 12:09:30 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id D258496B5; Tue, 11 Feb 2014 20:28:19 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by www.pwg.org (Postfix) with ESMTPS id E12BE96B4 for ; Tue, 11 Feb 2014 20:28:17 +0000 (UTC) MIME-version: 1.0 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0U00AKYLAKDDH0@mail-out.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 12:09:27 -0800 (PST) X-AuditID: 11807157-f79aa6d0000017b2-a2-52fa8376b547 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id CC.6C.06066.6738AF25; Tue, 11 Feb 2014 12:09:27 -0800 (PST) Received: from [17.153.99.181] (unknown [17.153.99.181]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0U001YKLBOEO20@sesame.apple.com> for IPP@pwg.org; Tue, 11 Feb 2014 12:09:26 -0800 (PST) From: Michael Sweet In-reply-to: Date: Tue, 11 Feb 2014 15:09:25 -0500 Message-id: <429A2FF0-FEF3-4801-9BB0-3E58370DA0F5@apple.com> References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

To: Peter Zehler X-Mailer: Apple Mail (2.1873) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUi2FDcoFve/CvIYO1jJotj+16yODB6zFs8 nSmAMYrLJiU1J7MstUjfLoErY+nqeUwFe9uYKm5enMzUwHjtNWMXIyeHhICJxMZ3/cwQtpjE hXvr2boYuTiEBPqYJD7fPwTlzGSSeDBhEViVsIClxMOWx6wgNq+AnsTEfTOYQIqYBaYwSmxd NQGsiE1ATeL3pD6wIk4Bf4nL03cwgdgsAqoSP3/8BbOZBdwl9lxeDzXIRuLJwdfMENu+s0h0 nprFBpIQEdCUOHhoP9R9shL/Tp9mnsDIPwvJ8lnIls8CG5wk8XnFNXYIW1ti2cLXUHEDiaed r1gxxfUl3rybwwRhm0o8ebudDcK2lvg55xEjhK0oMaX7IfsCRq5VjAJFqTmJlSZ6iQUFOal6 yfm5mxjBUVEYvoPx3zKrQ4wCHIxKPLwMnr+ChFgTy4orcw8xqgCNeLRh9QVGKZa8/LxUJRHe c3VAad6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxcqV+DhATSE0tSs1NTC1KLYLJMHJxSDYxLl2bF JG+9uujKn1+CHYZmGZ7yl24I+jB4/vlr7SacKODy4t78bxr1Ubb3lP9mHpudI81Sdfz8JfOu OPMMt+/fNLqKWflvaUzdoXJJflGe9oJ7DAdbEuf2v/O/I8btcXVKvZ1X87sz6TpPJ/jF+QRo HDy1St3tYBlH5FmGG7+jvW+0rEv+vF6JpTgj0VCLuag4EQA6WcXLkgIAAA== Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1130795413==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1130795413== Content-type: multipart/signed; boundary="Apple-Mail=_766C1284-65A1-41D4-A151-A00AC642097F"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_766C1284-65A1-41D4-A151-A00AC642097F Content-Type: multipart/alternative; boundary="Apple-Mail=_4F22DBF0-C0FD-4384-88AC-CD7A9BFD0AD8" --Apple-Mail=_4F22DBF0-C0FD-4384-88AC-CD7A9BFD0AD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Pete, First, support for push scan !=3D 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 = wrote: > Mike, > =20 > 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.=20 > =20 > 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). > =20 > Pete > =20 > Peter Zehler >=20 > Xerox Research Center Webster > Email: Peter.Zehler@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 > =20 > From: Michael Sweet [mailto:msweet@apple.com]=20 > Sent: Tuesday, February 11, 2014 11:49 AM > To: Zehler, Peter > Cc: Ira McDonald; IPP@pwg.org > Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? > =20 > Pete, > =20 > Please provide your definition of a constrained network scan client = with minimal local storage. > =20 > =20 > On Feb 11, 2014, at 11:38 AM, Zehler, Peter = wrote: >=20 >=20 > 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 = =93http,https,ftp,ftps,smb,ipp,ipps,mailto=94 which probably comes down = to about 45 bytes for the text record. > Pete > =20 > Peter Zehler >=20 > Xerox Research Center Webster > Email: Peter.Zehler@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 > =20 > From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20 > Sent: Tuesday, February 11, 2014 10:55 AM > To: Michael Sweet; Ira McDonald > Cc: Zehler, Peter; IPP@pwg.org > Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? > =20 > Hi Mike, >=20 > Crossed wires? >=20 > 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). >=20 > Cheers, > - Ira >=20 >=20 > 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@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 > =20 >=20 > On Tue, Feb 11, 2014 at 10:13 AM, Michael Sweet = wrote: > Ira, > =20 > On Feb 10, 2014, at 5:31 PM, Ira McDonald = wrote: > Hi Mike and Pete, >=20 > 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. > =20 > What would be the use case? > =20 > 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... > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 > =20 > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_4F22DBF0-C0FD-4384-88AC-CD7A9BFD0AD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Pete,

First, support for push = scan !=3D 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@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@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@apple.com]
Sent: Tuesday, February 11, 2014 11:49 AM
To: Zehler, Peter
Cc: Ira McDonald; IPP@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@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 = =93http,https,ftp,ftps,smb,ipp,ipps,mailto=94 which probably comes down = to about 45 bytes for the text record.
Pete

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@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@gmail.com= ]
Sent: Tuesday, February 11, 2014 10:55 AM
To: Michael Sweet; Ira McDonald
Cc: Zehler, Peter; IPP@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<= /a>
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@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@apple.com> wrote:

Ira,

On Feb 10, 2014, at 5:31 PM, Ira McDonald = <blueroofmusic@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

= --Apple-Mail=_4F22DBF0-C0FD-4384-88AC-CD7A9BFD0AD8-- --Apple-Mail=_766C1284-65A1-41D4-A151-A00AC642097F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjExMjAwOTI1WjAjBgkqhkiG9w0BCQQxFgQUQmoEyrD/6G+9gfbtu1H/3FnO WcYwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQC7CtsTIOGoetCyNPxS/GRJa0lc+NWL3/Eb6brN6Lzes9eDnhSns92fqbCktobESq+8XJeozZyt mw7LzaTkM8aWyhTxeEVBENVU0GIu/LAPMzzVnXQ6zfqsmeTLHcWs1WiXsZ6xUdYpy5DeYurWsLsp ncvSFMcZoksmKM4dc74cZz0OPqxbv/FlKDybHse1pj0oj/rGAaSiRLgWLdDFmQ7/LnBPisdA0wNY UathiMTvP5pTBNU8jk6MRmHGemnxhptZ0aF/XEMjjK3H8ijjn36IvS87YqB5dvqwGXaN+t+pzBsA iq8j/JewBPc7kRujmV/iDfz11RFTQIpp1eJmXtgxAAAAAAAA --Apple-Mail=_766C1284-65A1-41D4-A151-A00AC642097F-- --===============1130795413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1130795413==-- From ipp-bounces@pwg.org Tue Feb 11 12:46:01 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3091A073D for ; Tue, 11 Feb 2014 12:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tzhsxw8ZWLSV for ; Tue, 11 Feb 2014 12:45:55 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 1555F1A0732 for ; Tue, 11 Feb 2014 12:45:55 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id C3543959F; Tue, 11 Feb 2014 21:04:43 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from USA7109MR003.ACS-INC.COM (usa7109mr003.acs-inc.com [63.101.151.12]) by www.pwg.org (Postfix) with ESMTPS id AFD6B959C for ; Tue, 11 Feb 2014 21:04:42 +0000 (UTC) Received: from usa7109ht004.na.xerox.net ([13.41.230.30]) by USA7109MR003.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 11 Feb 2014 14:45:51 -0600 Received: from USA7109MB004.na.xerox.net ([169.254.4.205]) by USA7109HT004.na.xerox.net ([13.41.230.30]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 14:45:50 -0600 From: "Zehler, Peter" To: Michael Sweet Thread-Topic: [IPP] IPP Scan - Is Push scanning mandatory? Thread-Index: Ac8mmqBi8q2KEu3cQD+WG+3VxxvtAAAM2CsAAAyM3vD//6G1AIAAIj4AgAEX44CAAAurgIAAYsLQ//+sQQCAAFSg0P//41qAgABhk3A= Date: Tue, 11 Feb 2014 20:45:50 +0000 Message-ID: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

<429A2FF0-FEF3-4801-9BB0-3E58370DA0F5@apple.com> In-Reply-To: <429A2FF0-FEF3-4801-9BB0-3E58370DA0F5@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.94] MIME-Version: 1.0 Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0982685193==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0982685193== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_A4DE324D317E4F40A82CF077C7A9E1E34B9E8EUSA7109MB004naxer_" --_000_A4DE324D317E4F40A82CF077C7A9E1E34B9E8EUSA7109MB004naxer_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike, First, some workflows require push scan. That does not mean push scan =3D= =3D workflow. I do not consider scan to DropBox, SkyDrive or Flickr to be = workflows but they are none the less useful "software optimizations". Alth= ough a "fire and forget" aspect of the feature might be considered more tha= n just an optimization. Second, I expect that certain workflow Apps will only show scanners that ca= n potentially deliver scans directly to the destination. Pull only scanner= s 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 capa= ble 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. W= hich leaves ftp, ftps and smb. I see some workflow solutions using hot fol= ders that would benefit from that information but that is not a primary con= cern. Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@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@apple.com] Sent: Tuesday, February 11, 2014 3:09 PM To: Zehler, Peter Cc: Ira McDonald; IPP@pwg.org Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? Pete, First, support for push scan !=3D 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 su= pport 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 does= n't feel like the right answer to me...) On Feb 11, 2014, at 1:12 PM, Zehler, Peter > 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 po= int. 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 cli= ent. A pull from and MFD and then a push to a repository is not equivalen= t to an MFD pushing to a repository. I view this as an enterprise scannin= g requirement. Consumer and SMB targeted products can simply just implemen= t pull and avoid the push related overhead. But we need a scan solution th= at scales. Using discovery to filter basic relatively static capabilities i= s required. For printing that is things like color printing and supported = PDLs. For Scanning it is document feed capabilities and , for me, if it ca= n deliver a scan directly to a workflow (i.e., Push). Pete Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@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@apple.com] Sent: Tuesday, February 11, 2014 11:49 AM To: Zehler, Peter Cc: Ira McDonald; IPP@pwg.org Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? Pete, Please provide your definition of a constrained network scan client with mi= nimal local storage. On Feb 11, 2014, at 11:38 AM, Zehler, Peter > 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 destin= ation. (e.g., scanning a contract and delivering is securely to the destin= ation.) The ability to discover scanners that support push without interro= gating all the scanners in an enterprise environment is needed. We elimina= ted seven of the text records from the discovery message. This leaves 4 ma= ndatory, 2 conditional, and 2 optional. Adding this one should not be an u= ndue 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,f= tps,smb,ipp,ipps,mailto" which probably comes down to about 45 bytes for th= e text record. Pete Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@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@gmail.com] Sent: Tuesday, February 11, 2014 10:55 AM To: Michael Sweet; Ira McDonald Cc: Zehler, Peter; IPP@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. Tha= t'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@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 > wrote: Ira, On Feb 10, 2014, at 5:31 PM, Ira McDonald > 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 pus= h, 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 --_000_A4DE324D317E4F40A82CF077C7A9E1E34B9E8EUSA7109MB004naxer_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

<= /p>

First, some workflows req= uire push scan. That does not mean push scan =3D=3D 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 con= sidered more than just an optimization.

<= /p>

Second, I expect that cer= tain workflow Apps will only show scanners that can potentially deliver sca= ns 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.&= nbsp; 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 als= o be interesting for a client to find. I would think that a pus= h 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 pri= mary concern.

<= /p>

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com=
Office: +1 (585) 265-8755

Mobile: +1 (585) 329-9508<= /span>
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.<= br> 800 Phillips Rd.
M/S 128-25E<= br> Webster NY, 14580-9701

<= /p>

From: Michael = Sweet [mailto:msweet@apple.com]
Sent: Tuesday, February 11, 2014 3:09 PM
To: Zehler, Peter
Cc: Ira McDonald; IPP@pwg.org
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?=

Pete,

First, support for push scan !=3D support for a work= flow solution.

Second, how do you anticipate this being used with d= iscovery? 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 li= st of push schemes doesn't feel like the right answer to me...)<= /p>

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

Mike,

<= /p>

Pete

<= /p>

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com=
Office: +1 (585) 265-8755

Mobile: +1 (585) 329-9508<= /span>
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.<= br> 800 Phillips Rd.
M/S 128-25E<= br> Webster NY, 14580-9701

<= /p>

Pete,

Please provide your definition of a constrained netw= ork scan client with minimal local storage.

On Feb 11, 2014, at 11:38 AM, Zehler, Peter <Peter.Zehler@xerox.com> wrote:=

All,

Pete

<= /p>

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com=
Office: +1 (585) 265-8755

Mobile: +1 (585) 329-9508<= /span>
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.<= br> 800 Phillips Rd.
M/S 128-25E<= br> Webster NY, 14580-9701

<= /p>

Hi Mike,

Crossed wires?

Cheers,

- Ira

On Tue, Feb 11, 2014 at 10:13 AM, Michael Sweet <= msweet@apple.com&= gt; wrote:

Ira,

On Feb 10, 2014, at 5:31 PM, Ira McDonald <blueroofmusic@gmail.= com> wrote:

Hi Mike and Pete,

What about a simple TXT record discovery attribute f= or Push capability that's boolean?

Since a bunch of URI schemes are conditionally manda= tory anyway, that gets 90% of
the discovery need.

What would be the use case?

= _________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair<= /o:p>

______________________________= ___________________________<= span style=3D"font-family:"Andale Mono";color:black">
Michael Sweet, Senior Printing System&n= bsp;Engineer, PWG Chair

--_000_A4DE324D317E4F40A82CF077C7A9E1E34B9E8EUSA7109MB004naxer_-- --===============0982685193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0982685193==-- From ipp-bounces@pwg.org Wed Feb 12 13:12:20 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE8B1A066B for ; Wed, 12 Feb 2014 13:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvAWGTXO8Msu for ; Wed, 12 Feb 2014 13:12:14 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 75B441A0647 for ; Wed, 12 Feb 2014 13:12:14 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id A280885BC; Wed, 12 Feb 2014 21:31:08 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by www.pwg.org (Postfix) with ESMTPS id 2D5128534 for ; Wed, 12 Feb 2014 21:31:07 +0000 (UTC) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0W009PZIWB6KZ1@mail-out.apple.com> for IPP@pwg.org; Wed, 12 Feb 2014 13:12:11 -0800 (PST) X-AuditID: 11807165-f79076d0000015d9-35-52fbe3ab6938 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 6B.17.05593.BA3EBF25; Wed, 12 Feb 2014 13:12:11 -0800 (PST) Received: from [17.153.99.181] (unknown [17.153.99.181]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0W00D2XIW9Z230@sesame.apple.com> for IPP@pwg.org; Wed, 12 Feb 2014 13:12:11 -0800 (PST) From: Michael Sweet In-reply-to: Date: Wed, 12 Feb 2014 16:12:09 -0500 Message-id: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

<429A2FF0-FEF3-4801-9BB0-3E58370DA0F5@apple.com> To: Peter Zehler X-Mailer: Apple Mail (2.1873) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUi2FDcoLv68e8gg29rdCyO7XvJ4sDoMW/x dKYAxigum5TUnMyy1CJ9uwSujNuHd7IVTJvEWNG06TBbA+P+ZsYuRk4OCQETiRXrtjJD2GIS F+6tZwOxhQT6mCQu9dd1MXIB2TOZJGZ+vs4OkhAWsJR42PKYFcTmFdCTmLhvBhNIEbPAFEaJ vjX/wKayCahJ/J7UB1bEKeAvseLjLbCpLAKqEt8f7GMBsZkF3CX2XF4PNchG4vTcI6wQ296z Svw6vpcJJCEioClx8NB+qPNkJf6dPs08gZF/FpLls5AtnwU2OEmi7cs7JghbW2LZwtfMELaB xNPOV6yY4voSb97Ngao3lXjydjsbhG0t8XPOI6iZihJTuh+yL2DkWsUoUJSak1hprpdYUJCT qpecn7uJERwThak7GBuXWx1iFOBgVOLhvTD1d5AQa2JZcWXuIUYVoBGPNqy+wCjFkpefl6ok wlt8GCjNm5JYWZValB9fVJqTWnyIUZqDRUmclyv1a5CQQHpiSWp2ampBahFMlomDU6qBcX5T WpH2Wn17/U0/kw1+7uoOM7bMElw+VXHhjqC8wK4PPNNrhXsyVU7//OrO0FpZbnf6QHufmZ3g vB71cJGETKEPS3qcRVQ3RmSfZX5mYbHslnzSxO9fW/u/nqt67qe++N6+rA/7cpfcfx0Q+tzi ++Tu6XlPv7VosrX99FP1+zOjb9IbHVkxJZbijERDLeai4kQAPSb/k5ECAAA= Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0320024113==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0320024113== Content-type: multipart/signed; boundary="Apple-Mail=_D86D180F-2A60-4BD7-B3F2-0309E828E6C1"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_D86D180F-2A60-4BD7-B3F2-0309E828E6C1 Content-Type: multipart/alternative; boundary="Apple-Mail=_2709FFC2-5A49-4504-9605-E702C68FB9CC" --Apple-Mail=_2709FFC2-5A49-4504-9605-E702C68FB9CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Pete, On Feb 11, 2014, at 3:45 PM, Zehler, Peter = wrote: > Mike, > =20 > First, some workflows require push scan. That does not mean push scan = =3D=3D workflow. I do not consider scan to DropBox, SkyDrive or Flickr = to be workflows but they are none the less useful =93software = optimizations=94. Although a =93fire and forget=94 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 =93remote copy=94 (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 --Apple-Mail=_2709FFC2-5A49-4504-9605-E702C68FB9CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Pete,

On Feb 11, 2014, = at 3:45 PM, Zehler, Peter <Peter.Zehler@xerox.com> = wrote:

Mike,

First, some workflows require push scan. = That does not mean push scan =3D=3D workflow. I do not consider = scan to DropBox, SkyDrive or Flickr to be workflows but they are none the less useful =93software optimizations=94. = Although a =93fire and forget=94 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 =93remote copy=94 (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

= --Apple-Mail=_2709FFC2-5A49-4504-9605-E702C68FB9CC-- --Apple-Mail=_D86D180F-2A60-4BD7-B3F2-0309E828E6C1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjEyMjExMjEwWjAjBgkqhkiG9w0BCQQxFgQU+VTzsqkKdkZJuKWeGrJ8GK4Z zrUwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQCEDJXHwfCF7bp8XDKhPzO+UAs9vfP8xAgENoTgenTxZABkjkgPgywqVYHXQ1EIzCmm1S2egrzy /keBc7J/Q1gDDojbMFN8F0GGC+Zbjnk5xCYir64ZoKZGYvQ5lbU0MN4aWFPhX2rgqEr4rM93/nwT lLITrlMR6kVpIgAtRvaraacKPIGZrVjP2+nKShPf1oHQ8O5NLvtu55ghJCFhwb47SDCOR7SKNazJ jF0jfGfzHOGI43cFRdJYdYL/Rc4vuGYu3dpZNON5OMSfDHRmM3ue9isvwG8hQ18zWZffnQg5K6qF nVbrLxAdQYEyqSCr1bGmNbr0jhexhHQTtWbphv0uAAAAAAAA --Apple-Mail=_D86D180F-2A60-4BD7-B3F2-0309E828E6C1-- --===============0320024113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0320024113==-- From ipp-bounces@pwg.org Wed Feb 12 13:26:03 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D830D1A069B for ; Wed, 12 Feb 2014 13:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geOiZ3VKmNUT for ; Wed, 12 Feb 2014 13:25:59 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 454621A066B for ; Wed, 12 Feb 2014 13:25:59 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 237AF8495; Wed, 12 Feb 2014 21:44:53 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by www.pwg.org (Postfix) with ESMTPS id 6EA9D8085 for ; Wed, 12 Feb 2014 21:44:51 +0000 (UTC) Received: from G4W6310.americas.hpqcorp.net (g4w6310.houston.hp.com [16.210.26.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id C4C6738013; Wed, 12 Feb 2014 21:25:55 +0000 (UTC) Received: from G9W3616.americas.hpqcorp.net (16.216.186.51) by G4W6310.americas.hpqcorp.net (16.210.26.217) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Feb 2014 21:24:46 +0000 Received: from G9W0739.americas.hpqcorp.net ([169.254.10.90]) by G9W3616.americas.hpqcorp.net ([16.216.186.51]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 21:24:45 +0000 From: "Kennedy, Smith (Wireless Architect)" To: Michael Sweet , Peter Zehler Thread-Topic: [IPP] IPP Scan - Is Push scanning mandatory? Thread-Index: Ac8mmqBi8q2KEu3cQD+WG+3VxxvtAAAARYQAAAA47QAAAIqUAAAER9UAACL8WIAAAXVsgAABf7UAAABgjwAAAu5GgAAEEP+AAAFFlwAAMzXkgAAAcIEA Date: Wed, 12 Feb 2014 21:24:44 +0000 Message-ID: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

<429A2FF0-FEF3-4801-9BB0-3E58370DA0F5@apple.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [15.201.58.27] MIME-Version: 1.0 Cc: "" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0977169347==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0977169347== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_113AFA60-443D-49E0-88C0-E26601B0DF14"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_113AFA60-443D-49E0-88C0-E26601B0DF14 Content-Type: multipart/alternative; boundary="Apple-Mail=_32B7CF32-0E3C-4557-80EC-3323CCD0C19D" --Apple-Mail=_32B7CF32-0E3C-4557-80EC-3323CCD0C19D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> 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. >=20 > 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 =93required=94 facility of IPP Scan. Smith On 2014-02-12, at 2:12 PM, Michael Sweet wrote: > Pete, >=20 > On Feb 11, 2014, at 3:45 PM, Zehler, Peter = wrote: >> Mike, >> =20 >> First, some workflows require push scan. That does not mean push = scan =3D=3D workflow. I do not consider scan to DropBox, SkyDrive or = Flickr to be workflows but they are none the less useful =93software = optimizations=94. Although a =93fire and forget=94 aspect of the = feature might be considered more than just an optimization. >=20 > 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... >=20 >> 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. >=20 > Why would they exclude them? Are there security or other reasons? >=20 >> 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. >=20 > 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! >=20 >> The reason the schemes would be of interest is that finding a scanner = capable of =93remote copy=94 (i.e., scan to ipp/ipps) might be of = interest. >=20 > 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. >=20 >> A scan-to-email scanner might also be interesting for a client to = find. >=20 > 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. >=20 >> 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. >=20 > 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. >=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp --Apple-Mail=_32B7CF32-0E3C-4557-80EC-3323CCD0C19D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

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.

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

Smith

On 2014-02-12, at 2:12 PM, Michael Sweet <msweet@apple.com> = wrote:

Pete,

On Feb 11, 2014, = at 3:45 PM, Zehler, Peter <Peter.Zehler@xerox.com> wrote:
Mike,

First, some workflows require push scan. That = does not mean push scan =3D=3D workflow. I do not consider scan to = DropBox, SkyDrive or Flickr to be workflows but they are none the less = useful =93software optimizations=94. Although a =93fire and = forget=94 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 =93remote copy=94 (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-ema= il 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.

Fo= r 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

_________________________________= ______________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

= --Apple-Mail=_32B7CF32-0E3C-4557-80EC-3323CCD0C19D-- --Apple-Mail=_113AFA60-443D-49E0-88C0-E26601B0DF14 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH2zCCB9cw gga/oAMCAQICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEFBQAwgfcxCzAJBgNVBAYTAlVT MSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9y aXR5IEcyMB4XDTEyMTEyNjAwMDAwMFoXDTE0MTEyNjIzNTk1OVowgZgxIDAeBgNVBAoUF0hld2xl dHQtUGFja2FyZCBDb21wYW55MSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVtcGxveWVl czEPMA0GA1UECxMGUy9NSU1FMRYwFAYDVQQDEw1TbWl0aCBLZW5uZWR5MSMwIQYJKoZIhvcNAQkB FhRzbWl0aC5rZW5uZWR5QGhwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmo HmmwCMk0tCSI1w6tYppeJX3YINwFC5wUIhCt8HcRW/Ass9n7BxP1MpBUScmYpaQOjFI+n6JueqNN lmHysW9wFG8FiSxowAf2C6cN+kmrV1MOzprrpjZZTB979lqRD/UG5RCo4BNy3aTTtqMFk7JkrL1Q H8yLa5IOgUd36N7bK3+nSz6W3X3jo5G8Eax5xJvwCioOQzzmclRKpoDRKFT35bHptUCD0VR7IY74 9Ik7+A4RBp52w7zKYrs6N59Hy0PxxEzOsQImUC7++mhRJtg5AdX75wAKb665v3b4RZjJBMQhjYdU 8Al3e/iq362nUqJmrFbNhpM9LSapjpbCm7ECAwEAAaOCA7owggO2MB8GA1UdEQQYMBaBFHNtaXRo Lmtlbm5lZHlAaHAuY29tMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAw TqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFu eVNNSU1FRzIvTGF0ZXN0Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAd BgNVHQ4EFgQU2ugcyk1Ph3Uvd67i/95+2TE174IwggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsG AQUFBzABhhtodHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQL EydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MIIB PQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBD b21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3JyZXNwb25kIHdp dGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0ZS4gSXNzdWVkIHRvIGZhY2ls aXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJl ZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwME MEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG 9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEFBQADggEBAImyDkwpuUnbTsboOwpQAPQ4 M1jbZkfWS/mLo6oj6XOWApq9IQ1jkwowCWwwCA3F3wCbKQGphJ8HdLaVGY9AznOEQoixLHx9rnIT aq9lFeagCZiqtFq6/i33etWRb6dXp3FZYn9ikhYv74Ewil/ue61VqW9vOAZq51Wt9JznLmVSkJN1 1A4oJxNL8/jiK82tSXMkUHe07VbZUUF+t609D979rvVK68sw6P+cDe+46gy6oM9LHtINt8Fclro/ 45hQe0FdW1A1dmyx4dyKW/SbRK4uw5c0nXvaZn0Wrlnq2Rxm/wCNKnGxAtp0ir7/7ubR6GjB3xuf BjNLp57JgbuFIg4xggTeMIIE2gIBATCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXds ZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx NTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi 82zI/6Xyi7FlMAkGBSsOAwIaBQCgggKlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE0MDIxMjIxMjQ0NVowIwYJKoZIhvcNAQkEMRYEFPoChL25Exg5iCWvIi8W2scJ lxl0MIIBHwYJKwYBBAGCNxAEMYIBEDCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXds ZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx NTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi 82zI/6Xyi7FlMIIBIQYLKoZIhvcNAQkQAgsxggEQoIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIC EDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEBBQAEggEAJ7d28LJ9u+Y84tGkJMwblce8mz9h MOlLsghyIZNAw+BeRuopjQSCmk0U49NplPFHnqYsOqlUpsfU/mDAOPwzAWvukqm3BetvbWlrUVtj f860EIaKg5ER1rufDg8XXBxJeufZDT855DWIA/ijMJCicjH0GaLkZfx3cxatz6XCyUCnY1fKKqoO t1l0oXh5XPLTvokXMf48SwuGpUC2yf94100MjXktTdgsAUuDyNNcN8u5sbKy9Syz2vORKhPequ3L rN25HZmjbs9LYx/EuIJwuIqckh1LXB5jHWixVDaQS6UBQNWMLI8xXRsheXK5EBMZeRnjX8tBCqgL X4PlFxnTgQAAAAAAAA== --Apple-Mail=_113AFA60-443D-49E0-88C0-E26601B0DF14-- --===============0977169347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0977169347==-- From ipp-bounces@pwg.org Thu Feb 13 05:06:46 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EF41A0229 for ; Thu, 13 Feb 2014 05:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqlqltoQfN5R for ; Thu, 13 Feb 2014 05:06:41 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA1F1A022E for ; Thu, 13 Feb 2014 05:06:41 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id E120E957D; Thu, 13 Feb 2014 13:25:37 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from USA7109MR004.ACS-INC.COM (usa7109mr004.acs-inc.com [63.101.151.13]) by www.pwg.org (Postfix) with ESMTPS id 094D0955D for ; Thu, 13 Feb 2014 13:25:35 +0000 (UTC) Received: from usa7109ht001.na.xerox.net ([13.41.230.31]) by USA7109MR004.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 13 Feb 2014 07:06:36 -0600 Received: from USA7109MB004.na.xerox.net ([169.254.4.205]) by USA7109HT001.na.xerox.net ([13.41.230.31]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 07:06:35 -0600 From: "Zehler, Peter" To: Michael Sweet Thread-Topic: [IPP] IPP Scan - Is Push scanning mandatory? Thread-Index: Ac8mmqBi8q2KEu3cQD+WG+3VxxvtAAAM2CsAAAyM3vD//6G1AIAAIj4AgAEX44CAAAurgIAAYsLQ//+sQQCAAFSg0P//41qAgABhk3CAAUJJgP//eE7A Date: Thu, 13 Feb 2014 13:06:35 +0000 Message-ID: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

<429A2FF0-FEF3-4801-9BB0-3E58370DA0F5@apple.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.86] MIME-Version: 1.0 Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1121326256==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1121326256== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_A4DE324D317E4F40A82CF077C7A9E1E34BA485USA7109MB004naxer_" --_000_A4DE324D317E4F40A82CF077C7A9E1E34BA485USA7109MB004naxer_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I am pushing hard for discovery of push capability because it is an absolut= e requirement in the enterprise environment. If there is consensus that it= is such a burden, then we can make it optional instead of conditionally ma= ndatory. I think the opposition to the text discovery text record is the m= inority. 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 discuss= ion other than to reiterate that we have a business need for scanned docume= nts 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 ha= ve no problem with Push being mandatory but we realize for the low end it m= ay be a burden. We would have no problem allowing Push or Pull or both, bu= t realize that the PWG wants to insure some level of guaranteed interoperab= ility 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 market= ing term for scan to print where the scanner and printer are geographicall= y 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 c= lient on a mobile device does not equate to the mobile device being the rec= ipient of the scanned document. There are other capabilities that the mobi= le device brings such as all the personalized information (e.g., contacts) = and superior UI. Capabilities like those as well as the current movement f= rom PCs to mobile make implementing an IPP Scan Client on a mobile device d= esirable. 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@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@apple.com] Sent: Wednesday, February 12, 2014 4:12 PM To: Zehler, Peter Cc: Ira McDonald; IPP@pwg.org Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? Pete, On Feb 11, 2014, at 3:45 PM, Zehler, Peter > wrote: Mike, First, some workflows require push scan. That does not mean push scan =3D= =3D workflow. I do not consider scan to DropBox, SkyDrive or Flickr to be = workflows but they are none the less useful "software optimizations". Alth= ough a "fire and forget" aspect of the feature might be considered more tha= n just an optimization. In the case of those services, I would expect you would need to include cre= dentials 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 ca= n potentially deliver scans directly to the destination. Pull only scanner= s 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 require= d. If we think it is a useful optimization, it can stay recommended. Eith= er 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 capab= le 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 ar= e 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 t= o 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 somethi= ng push scan will give me. I would think that a push scanner could be depended upon to support http/ht= tps. 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 prim= ary concern. For write access, I would guess that SMB and FTP are going to be the genera= l favorites over HTTP, as those services generally have write access enable= d by default while HTTP requires special configuration or third-party solut= ions that have been configured accordingly. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_A4DE324D317E4F40A82CF077C7A9E1E34BA485USA7109MB004naxer_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

<= /p>

I am pushing hard for dis= covery of push capability because it is an absolute requirement in the ente= rprise 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 mino= rity. If I am wrong I’d like to hear from others.

<= /p>

The exact nature of Xerox= ’s use cases is beyond the scope of public discussion other than to r= eiterate that we have a business need for scanned documents to be delivered directly from the scan service to the scan destination and no= t allowing the scan client to act as an intermediary. Xerox would hav= e no problem with Push being mandatory but we realize for the low end it ma= y be a burden. We would have no problem allowing Push or Pull or both, but realize that the PWG wants to insure so= me level of guaranteed interoperability so we support making Pull mandatory= .

<= /p>

Xerox requests that Push = be optional but want the feature discoverable.

<= /p>

Remote copy is not creati= ng 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 pr= int.) I do not consider scan to email an edge case given it is alread= y supported by every MFD vendor in the PWG. The use of an IPP Scan cl= ient 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 perso= nalized information (e.g., contacts) and superior UI. Capabilities li= ke those as well as the current movement from PCs to mobile make implementing an IPP Scan Client on a mobile device desi= rable.

<= /p>

It is my preference to ha= ve a text record that is a comma separate= d list of schemes as described below (i.e. conditionally mandatory).

<= /p>

K= ey

D= escription

D= efault

push=

A co= mma separated list using the following keywords: http, https, ftp, ftps, sm= b, ipp, ipps, mailto. Vendors may extend the set of values.

Push= scan is not supported

<= /p>

Please voice your support= or opposition.

<= /p>

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com=
Office: +1 (585) 265-8755

Mobile: +1 (585) 329-9508<= /span>
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.<= br> 800 Phillips Rd.
M/S 128-25E<= br> Webster NY, 14580-9701

<= /p>

From: Michael = Sweet [mailto:msweet@apple.com]
Sent: Wednesday, February 12, 2014 4:12 PM
To: Zehler, Peter
Cc: Ira McDonald; IPP@pwg.org
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?=

Pete,

On Feb 11, 2014, at 3:45 PM, Zehler, Peter <Peter.Zehler@xerox.com> wrote:<= o:p>

Mike,
<= /p>
First, some workflows req= uire push scan. That does not mean push scan =3D=3D 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 con= sidered more than just an optimization.

In the case of those services, I would expect you wo= uld need to include credentials in the URIs, and that's not something I thi= nk we want to encourage...

Second, I expect that cer= tain workflow Apps will only show scanners that can potentially deliver sca= ns directly to the destination. Pull only scanners are excluded from consideration.

Why would they exclude them? Are there securit= y or other reasons?

As I said, I can live wit= h a Boolean since that will narrow the field to at least the scanners capab= le 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 wo= uld be of interest is that finding a scanner capable of “remote copy&= #8221; (i.e., scan to ipp/ipps) might be of interest.

Please, let's not bring that up again. It is u= seful for workflow but we are not trying to create a copy-like service inte= rface through scan, just as we didn't want to do it with faxout or with pri= nt. We collectively chose to keep a separate copy service for that purpose, and there was no interest in doing an IPP C= opy Service spec because initiating copy from a client is just an interesti= ng edge case.

A scan-to-email scanner m= ight also be interesting for a client to find.

Scan-to-email can be done a bunch of ways, but I wou= ld 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 f= tp, 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 h= ave write access enabled by default while HTTP requires special configurati= on or third-party solutions that have been configured accordingly.

____________= _____________________________________________
Michael Sweet, Senior= Printing System Engineer, PWG Chair

--_000_A4DE324D317E4F40A82CF077C7A9E1E34BA485USA7109MB004naxer_-- --===============1121326256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1121326256==-- From ipp-bounces@pwg.org Thu Feb 13 06:30:52 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187121A0293 for ; Thu, 13 Feb 2014 06:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2YhTwMX4ypX for ; Thu, 13 Feb 2014 06:30:48 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5511A0252 for ; Thu, 13 Feb 2014 06:30:48 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 3BFE09601; Thu, 13 Feb 2014 14:49:45 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by www.pwg.org (Postfix) with ESMTPS id C769395FC for ; Thu, 13 Feb 2014 14:49:43 +0000 (UTC) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0X001TFUZ5OF81@mail-out.apple.com> for IPP@pwg.org; Thu, 13 Feb 2014 06:30:45 -0800 (PST) X-AuditID: 11807166-f79c26d000001623-30-52fcd714880c Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 0D.D1.05667.417DCF25; Thu, 13 Feb 2014 06:30:44 -0800 (PST) Received: from [17.153.99.181] (unknown [17.153.99.181]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0X00DLEUZ5NV30@sesame.apple.com> for IPP@pwg.org; Thu, 13 Feb 2014 06:30:44 -0800 (PST) From: Michael Sweet In-reply-to: Date: Thu, 13 Feb 2014 09:30:41 -0500 Message-id: <52FAC5FD-CD94-4C56-A43E-37E1F9E3986C@apple.com> References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

<429A2FF0-FEF3-4801-9BB0-3E58370DA0F5@apple.com>

To: Peter Zehler X-Mailer: Apple Mail (2.1873) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUi2FDcoCty/U+QwfNZ1hbH9r1kcWD0mLd4 OlMAYxSXTUpqTmZZapG+XQJXxs/ji1gL9u5kqniw5RRLA+PdKUxdjJwcEgImEicu/mSBsMUk Ltxbz9bFyMUhJNDHJDHtwkNWCGcmk8SzxudgHcIClhIPWx6zgti8AnoSE/fNYAIpYhaYwihx d0cvI0iCTUBN4vekPrAiTgF/ia/rrgLFOThYBFQl7j5wBQkzC7hL7Lm8HmqOjcTq51Ohlj1n k+jZPJkZJCEioClx8NB+ZojzZCX+nT7NPIGRfxaS3bOQ7Z4FNjhJ4tnRflYIW1ti2cLXzBC2 gcTTzldYxPUl3rybwwRhm0o8ebudDcK2lvg55xHUTEWJKd0P2Rcwcq1iFChKzUmstNBLLCjI SdVLzs/dxAiOicK0HYxNy60OMQpwMCrx8Fp8/B0kxJpYVlyZe4hRBWjEow2rLzBKseTl56Uq ifCGH/kTJMSbklhZlVqUH19UmpNafIhRmoNFSZz3uTRQSiA9sSQ1OzW1ILUIJsvEwSnVwLhR eVHGTv7we7wG8yX2zc1/4WZ+VfGLT+nZWUvTXf72NV7jdn86VyQgcGVSc4fohOQPvVIdZgo+ d1UKT29b+zZmiv15jbU5Ro0nzlXd+v7hsL7Ty1/Xwhh/sP+VubfT7tStik8xUy806v9R3R/t tCMhQt2fIb/zpRSnlkrgKek5rOzrPXL3H1ZiKc5INNRiLipOBAA8B4ITkQIAAA== Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0596153700==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0596153700== Content-type: multipart/signed; boundary="Apple-Mail=_5EB55C88-DE6D-4362-962B-FB2108699CD9"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_5EB55C88-DE6D-4362-962B-FB2108699CD9 Content-Type: multipart/alternative; boundary="Apple-Mail=_55288C33-53CF-4219-BEF2-C96569BECFEE" --Apple-Mail=_55288C33-53CF-4219-BEF2-C96569BECFEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 = wrote: > All, > =20 > 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=92d like to hear = from others. > =20 > The exact nature of Xerox=92s 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.=20 > =20 > Xerox requests that Push be optional but want the feature = discoverable. > =20 > 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. > =20 > It is my preference to have a text record that is a comma separated = list of schemes as described below (i.e. conditionally mandatory). > =20 > Key >=20 > Description >=20 > Default >=20 > push >=20 > A comma separated list using the following keywords: http, https, ftp, = ftps, smb, ipp, ipps, mailto. Vendors may extend the set of values. >=20 > Push scan is not supported >=20 > =20 > Please voice your support or opposition. > =20 > =20 > Peter Zehler >=20 > Xerox Research Center Webster > Email: Peter.Zehler@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 > =20 > From: Michael Sweet [mailto:msweet@apple.com]=20 > Sent: Wednesday, February 12, 2014 4:12 PM > To: Zehler, Peter > Cc: Ira McDonald; IPP@pwg.org > Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? > =20 > Pete, > =20 > On Feb 11, 2014, at 3:45 PM, Zehler, Peter = wrote: > Mike, > =20 > First, some workflows require push scan. That does not mean push scan = =3D=3D workflow. I do not consider scan to DropBox, SkyDrive or Flickr = to be workflows but they are none the less useful =93software = optimizations=94. Although a =93fire and forget=94 aspect of the = feature might be considered more than just an optimization. > =20 > 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... > =20 > 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. > =20 > Why would they exclude them? Are there security or other reasons? > =20 > 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. > =20 > 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! >=20 >=20 > The reason the schemes would be of interest is that finding a scanner = capable of =93remote copy=94 (i.e., scan to ipp/ipps) might be of = interest. > =20 > 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. > =20 > A scan-to-email scanner might also be interesting for a client to = find. > =20 > 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. >=20 >=20 > 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. > =20 > 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. > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_55288C33-53CF-4219-BEF2-C96569BECFEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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 <Peter.Zehler@xerox.com> = 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=92d like to hear from = others.

The exact nature of Xerox=92s 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@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@apple.com]
Sent: Wednesday, February 12, 2014 4:12 PM
To: Zehler, Peter
Cc: Ira McDonald; IPP@pwg.org
Subject: Re: [IPP] IPP Scan - Is Push scanning = mandatory?

Pete,

On Feb 11, 2014, at 3:45 PM, Zehler, Peter = <Peter.Zehler@xerox.com> = wrote:

Mike,

First, some workflows require push scan. = That does not mean push scan =3D=3D workflow. I do not consider = scan to DropBox, SkyDrive or Flickr to be workflows but they are none the less useful =93software optimizations=94. = Although a =93fire and forget=94 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 =93remote copy=94 (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

= --Apple-Mail=_55288C33-53CF-4219-BEF2-C96569BECFEE-- --Apple-Mail=_5EB55C88-DE6D-4362-962B-FB2108699CD9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjEzMTQzMDQyWjAjBgkqhkiG9w0BCQQxFgQUvKicgeLPfE9gCKhu3t0h+w2D sSMwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQCikjiNcWMJ99DNnyA4KHuley7y6YiAQS1Pcoi+1rFrr9eVuFhiHvBvW6q70I3A6ez5ZsTzZTis uAMLgIvh7thMvYoaUzyFr7Mpn+nVzNrPyu5DfG3Zu/3Ncd5M+gF8iXevh8KRKNoHdF3ImnEhVCfR FmBq4gIkikfa7WaXU5Q4dJRnscAExMcPU3I453n4SN4Xa1TIJBks+vjLseTmwiSMtMnNQRHYG7Ij vt37fQUG80p93o+bN01MLqb5IbcC0L3byxrfuD+WfgAxtnVRnowkntlvwjpvj61pSKesk0PCnbhT 8n1n9tqyeF8GiLiYVE/eEn/eDNIDj9ZCOh+DCHlrAAAAAAAA --Apple-Mail=_5EB55C88-DE6D-4362-962B-FB2108699CD9-- --===============0596153700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0596153700==-- From ipp-bounces@pwg.org Thu Feb 13 09:21:48 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A301A0322 for ; Thu, 13 Feb 2014 09:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB6_0LCN1USX for ; Thu, 13 Feb 2014 09:21:46 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 8460B1A0323 for ; Thu, 13 Feb 2014 09:21:39 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 8AD2A9630; Thu, 13 Feb 2014 17:40:36 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by www.pwg.org (Postfix) with ESMTPS id 560E39625 for ; Thu, 13 Feb 2014 17:40:35 +0000 (UTC) MIME-version: 1.0 Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0Y005JJ2VA1S20@mail-out.apple.com> for ipp@pwg.org; Thu, 13 Feb 2014 09:21:35 -0800 (PST) X-AuditID: 1180715a-f79cb6d00000168c-5f-52fcff1e9c27 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 92.D7.05772.F1FFCF25; Thu, 13 Feb 2014 09:21:35 -0800 (PST) Received: from [17.153.16.154] (unknown [17.153.16.154]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0Y00INN2VX5240@sesame.apple.com> for ipp@pwg.org; Thu, 13 Feb 2014 09:21:34 -0800 (PST) From: Michael Sweet Date: Thu, 13 Feb 2014 12:21:32 -0500 To: "" Message-id: X-Mailer: Apple Mail (2.1874) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FDcoCv//0+QwZ497BbH9r1kcWD0mLd4 OlMAYxSXTUpqTmZZapG+XQJXxr2lv1kLljlUPH/+jrmBca1tFyMnh4SAiUTTw1/MELaYxIV7 69lAbCGBPiaJ+SfyIeyZTBLXP2uD2GwCahK/J/WxdjFycTALTGGUmPNxCVgzi4CqxOtpK8Ca hQWiJKZMbmAHsUUEFCV+TtvOCGLzCthIHP6zgQXC1pM4c/YXO8RiWYlHH5pYJjDyzEI2dxaS OhCbWUBbYtnC10BxDiBbR2LyQkaIsKnEk7fb2SBsa4mfcx5BxRUlpnQ/ZF/AyL6KUaAoNSex 0kwvsaAgJ1UvOT93EyM48AqjdjA2LLc6xCjAwajEw+vx4E+QEGtiWXFl7iFGFaARjzasvsAo xZKXn5eqJMJb/Q8ozZuSWFmVWpQfX1Sak1p8iFGag0VJnPeFNFBKID2xJDU7NbUgtQgmy8TB KdXAyH1i/tI/HPHrZr90863OOsFV+m3bkSrR+Z/XFpX5NZYEzWyKqVLkV43tV3J49mRLzsId V3fo9zKudd0mK8HIUSpfwyq2OuDYn45Tmk1sWp2T3vkZPAk85mc0e0qJgF/YbQlzy0eytZcj r/BohU3ZdzF252pd3sd+ChMKRHrOFvHcjctzqo1RYinOSDTUYi4qTgQAYnCtSkQCAAA= Subject: [IPP] Updated prototype draft of IPP Shared Infrastructure Extensions (IPPSIX) posted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1985506291==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1985506291== Content-type: multipart/signed; boundary="Apple-Mail=_087F6165-7233-4F9A-9F5F-916C89B7EDC3"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_087F6165-7233-4F9A-9F5F-916C89B7EDC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, I have posted an updated prototype draft of the IPP Shared = Infrastructure Extensions (IPPSIX) to: http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20140213.docx http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20140213.pdf http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20140213-rev.pdf Aside from some editorial fixes, this update synchronizes IPPSIX with = the recent updates to the Cloud Imaging Model. The major = implementation/binding change is to merge the = Set-Output-Device-Attributes and Update-Output-Device-State operations = into a single Update-Output-Device-Attributes operation. Also, Reset-Fetchable-Jobs is now called Update-Active-Jobs, and the new = "job-states" operation attribute is used to pass around the current job = states for each job ID. Invalid job IDs in an Update-Active-Jobs = operation are returned in the invalid attributes group (instead of the = 'invalid' job state that was suggested in the F2F meeting) to provide a = cleaner, more IPP-like binding. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_087F6165-7233-4F9A-9F5F-916C89B7EDC3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjEzMTcyMTMzWjAjBgkqhkiG9w0BCQQxFgQU+INR3Lqz+vyztiq4hchtYl67 xckwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQAwynGSXIqrjzzKXXZcpQM/WOJh5pqtwO27nrD20njSez7gCUgG1GspFbk1fnjX490hYfmI3ilh pjK+uXrmHzduHCHtIFUNtYVCgJCN7G/o73ImnifZLxJI1zNWFq1xgRFfmtLAeJaIjPxtogzxJZX4 KuAQXE9Yy+Ed/NaxfsaTUz8fjXta9HPK99PCrlPPNgOEfJFyAqAj5qD1fJ6UI7d4YW/T6HorFmJ2 eF/smy7MAtZWkQ+BzTwjewqazyi6WHKdhCgQKZCIoHqFb7XzLTSNrgq68lVMuNLypL453XgGxm4j wJpJJSqlxzqcvXoa4tHKY+b3uXKky8uREgEOR6m+AAAAAAAA --Apple-Mail=_087F6165-7233-4F9A-9F5F-916C89B7EDC3-- --===============1985506291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1985506291==-- From bladders12714@bghdfiu.me Fri Feb 14 08:34:51 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2841A0329 for ; Fri, 14 Feb 2014 08:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.976 X-Spam-Level: **** X-Spam-Status: No, score=4.976 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, FUZZY_CPILL=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, MISSING_MID=0.497, RDNS_NONE=0.793, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfpSx9Ymhdj2 for ; Fri, 14 Feb 2014 08:34:49 -0800 (PST) Received: from thankless.bghdfiu.me (unknown [184.154.193.5]) by ietfa.amsl.com (Postfix) with SMTP id 88D841A031C for ; Fri, 14 Feb 2014 08:34:49 -0800 (PST) To: From: "Oz Skin Tip " Subject: Powerful Anti-Aging Tip - Recommended by 9 out of 10 Dermatologists Date: Fri, 14 Feb 2014 11:34:44 -0500 MIME-Version: 1.0 Content-Type: text/html Sample Clickthru

Can't browse the offer below due to no images? Go ahead and browse here.

Powerful Anti-Aging Tip - Recommended by 9 out of 10 Dermatologists

admitted that he might have been mistaken. The svtxvrir incident and the name had remained together in my mind. Jordan Baker instinctively avoided clever, shrewd men,

and kbtha now I saw that this was because she felt qjoyadm safer on pbp a plane where any divergence from a code would be thought impossible. She was incurably dishonest. She wasn’t able

to endure being at a disadvantage and, given this unwillingness, I phvx suppose she had begun dealing in subterfuges when she was very young in order to keep that

cool, insolent smile turned to the world and yet satisfy the demands of her hard, jaunty body. It made no difference to me. Dishonesty in a woman is a

thing you never blame deeply — I was casually sorry, and then I forgot. It was on that same house party that we had a curious conversation about driving a car. It started ymfo

because she phied so close to some workmen that our fender flicked a hion on one man’s coat. “You’re a rotten driver,” I protested. “Either you ought

to be more careful, or you oughtn’t to drive at all.” “I am careful.” “No, you’re efxsx not.” “Well, other people are, ” she said lightly.

“What’s that got to do with it?” “They’ll keep out of my way,” she insisted. “It takes two to make an accident.” “Suppose you met somebody just as careless as yourself. ” rty

“I hope I never will, ” rcoiq she answered. “I hate careless people. That’s why I like you.” Her gray, sun-strained eyes stared straight ahead, but

she had deliberately shifted our relations, and for a moment I thought I loved her. But I am slow-thinking and full of interior rules that act as brakes on my desires, and I

knew that first I had rljinend to get myself definitely out of that tangle back home. I’d been writing letters once a week and signing them: “Love, Nick,” and all I could think of was

how, when that certain girl played tennis, a faint mustache of perspiration appeared on her upper nusj lip. Nevertheless there was a vague understanding that had to be xvbye tactfully

broken off before i was hi.Every one suspects himself of at least one of the cardinal virtues, and this is mine: I am one of the fewhonest people that ktorffsjp I have ever known.

On Sunday morning while church bells rang in hoa the villages alongshore, the world and wkc its mistress returned to Gatsby’s house and twinkled

hilariously on his lawn. “He’s a bootlegger, ” said the young ladies, moving somewhere between his rocktails and his flowers. “One time he killed a man who had found out

that he was nephew to Von wgjh Hindenburg and second cousin to the devil. Reach me a rose, honey, and pour me a last mqbccygxy drop into that there pjcosip crystal glhi.”

Once I wrote down on the empty spaces of a time-table the names of those who came to Gatsby’s house that summer. It jinhkpf is an old time-table now,

disintegrating at its folds, and headed “This schedule in effect July 5th, 1922. ” But I can still read the gray names, and they will give you a better impression than my

From ipp-bounces@pwg.org Fri Feb 14 15:08:00 2014 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF91A045A for ; Fri, 14 Feb 2014 15:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tbpfJh3vvq0 for ; Fri, 14 Feb 2014 15:07:46 -0800 (PST) Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 5331E1A0457 for ; Fri, 14 Feb 2014 15:07:40 -0800 (PST) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 1CF8D9433; Fri, 14 Feb 2014 23:26:43 +0000 (UTC) X-Original-To: IPP@pwg.org Delivered-To: IPP@pwg.org Received: from Cnxtsmtp1.conexant.com (cnxt09252.conexant.com [198.62.9.252]) by www.pwg.org (Postfix) with ESMTPS id 64DFF942F for ; Fri, 14 Feb 2014 23:26:41 +0000 (UTC) X-WSS-ID: 0N10DKN-04-2TD-03 X-M-MSG: Received: from WS (unknown [157.152.181.46]) by Cnxtsmtp1.conexant.com (Axway MailGate 3.8.1) with ESMTP id 2284D120B9E; Fri, 14 Feb 2014 15:07:34 -0800 (PST) Received: from nbprotector762.bbnet.ad (unknown [127.0.0.1]) by nbprotector762.bbnet.ad (Service) with ESMTP id 1511D7D00F; Fri, 14 Feb 2014 13:16:00 -0800 (PST) Received: from cnxthub1.bbnet.ad (unknown [157.152.180.131]) by nbprotector762.bbnet.ad (Service) with ESMTP id DD0E97D002; Fri, 14 Feb 2014 13:15:59 -0800 (PST) Received: from NBMBX02.bbnet.ad ([fe80:0000:0000:0000:f503:c723:66.76.52.244]) by cnxthub1.bbnet.ad ([157.152.180.131]) with mapi; Fri, 14 Feb 2014 15:07:34 -0800 From: "Soma Meiyappan" To: "Michael Sweet" , "Peter Zehler" Date: Fri, 14 Feb 2014 15:07:31 -0800 Thread-Topic: [IPP] IPP Scan - Is Push scanning mandatory? Thread-Index: Ac8oyDOCUhsge1ZbTcCWivxxef2EXQBD0h/g Message-ID: References:

<52CC5CD3-9266-465F-B5C7-A994B98A6BF1@apple.com>

<429A2FF0-FEF3-4801-9BB0-3E58370DA0F5@apple.com>

<52FAC5FD-CD94-4C56-A43E-37E1F9E3986C@apple.com> In-Reply-To: <52FAC5FD-CD94-4C56-A43E-37E1F9E3986C@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "IPP@pwg.org" Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory? X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0110656816==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0110656816== Content-Language: en-US Content-Type: multipart/alternative; boundary=_000_B3E94892AE450142B7CB3D381CFF5142040CDE6704NBMBX02bbneta_ --_000_B3E94892AE450142B7CB3D381CFF5142040CDE6704NBMBX02bbneta_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 = = =66unctionality will be made available=3F 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. =46rom: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of = Michael Sweet Sent: Thursday, February 13, 2014 10:31 PM To: Peter Zehler Cc: IPP@pwg.org Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory=3F Pete, I'll continue to voice my opposition for this on principle, since it makes = = =66or 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"=3F (marginally larger while clearly= = limiting to the scan destinations, pairs nicely with the existing "Scan" ke= y= 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 Pus= h= 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 = =66iltering is not recommended for general purpose scan Clients since it ca= n= confuse and/or frustrate End Users. (I realize we don't generally include such recommendations, but in this cas= e= I think we need to say something to help avoid the interoperability and = perception issues it could cause.) =46inally, 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 sca= n= 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 fo= r= all of the standards we define - happy users buy and use printers... On Feb 13, 2014, at 8:06 AM, Zehler, Peter = > wrote: All, I am pushing hard for discovery of push capability because it is an absolut= e= 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 th= e= low end it may be a burden. We would have no problem allowing Push or Pul= l= 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@Xerox.com Office: +1 (585) 265-8755 Mobile: +1 (585) 329-9508 =46AX: +1 (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701 =46rom: Michael Sweet [mailto:msweet@apple.com] Sent: Wednesday, February 12, 2014 4:12 PM To: Zehler, Peter Cc: Ira McDonald; IPP@pwg.org Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory=3F Pete, On Feb 11, 2014, at 3:45 PM, Zehler, Peter = > wrote: Mike, =46irst, some workflows require push scan. That does not mean push scan = =3D=3D 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 ca= n= potentially deliver scans directly to the destination. Pull only scanners= = are excluded from consideration. Why would they exclude them=3F Are there security or other reasons=3F 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 ar= e= not trying to create a copy-like service interface through scan, just as w= e= 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 jus= t= 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 somethin= g= 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. =46or 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 Conexant E-mail Firewall (Conexant.Com) made the following annotations --------------------------------------------------------------------- ********************** Legal Disclaimer ****************************=20 "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.= "= =20 **********************************************************************=20 --------------------------------------------------------------------- --_000_B3E94892AE450142B7CB3D381CFF5142040CDE6704NBMBX02bbneta_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

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= = =66or 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=3F I agree that it does not = prevent device manufacturers from implementing similar functionality throug= h= both IPP services. But I wanted to hear your thoughts on = this.

Thanks= and Regards,

Somasundaram.

Senior= Staff Engineer,

Conexant= Systems Inc.

From: = ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michae= l= Sweet
Sent: Thursday, February 13, 2014 10:31 PM
To: = = Peter Zehler
Cc: IPP@pwg.org
Subject: Re: [IPP] IPP Sca= n= - Is Push scanning mandatory=3F

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= = =66eedback on the proposed name and description:

<= p= class=3DMsoNormal>

1. = = Instead of "push", how about "Scan2"=3F (marginally = larger while clearly limiting to the scan destinations, pairs nicely with = = the existing "Scan" key in the Bonjour Printing = specification)

2. = = =46or 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. = = =46or 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 t= o= keep that in mind for all of the standards we define - happy users buy and= = use printers...

On = = =46eb 13, 2014, at 8:06 AM, Zehler, Peter <Peter.Zehler@xerox.com> = 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 i= s= 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 usin= g= 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.

Pet= er= Zehler

Xer= ox= Research Center Webster
Emai= l:= Peter.Zehler@Xerox.com
Offi= ce:= +1 (585) 265-8755
Mobi= le:= +1 (585) 329-9508
FAX= := +1 (585) 265-7441
US = = Mail: Peter Zehler
Xero= x= Corp.
800= = Phillips Rd.
M/S= = 128-25E
Webs= ter= NY, 14580-9701=

From: Michael Swee= t= [mailto:msweet@apple.com] =
Sent: Wednesday, February 12, 2014 4:12 PM
To: Zehler,= = Peter
Cc: Ira McDonald; IPP@pwg.org
Subject: Re: [IPP] IP= P= Scan - Is Push scanning mandatory=3F

Pete,

On Feb 11, 2014, at 3:45 PM, Zehler, Peter <Peter.Zehler@xerox.com> = wrote:

Mike,

First,= some workflows require push scan. That does not mean push scan =3D= =3D= workflow. I do not consider scan to DropBox, SkyDrive or Flickr to b= e= 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 credential= s= 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=3F Are there security or other = reasons=3F

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 w= e= 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= = =66or workflow but we are not trying to create a copy-like service interfac= e= 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 becaus= e= initiating copy from a client is just an interesting edge = case.

A= scan-to-email scanner might also be interesting for a client to = =66ind.

Scan-to-email can be done a bunch of ways, but I would sa= y= 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.

<= p= class=3DMsoNormal>

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 goin= g= to be the general favorites over HTTP, as those services generally have = write access enabled by default while HTTP requires special configuration o= r= third-party solutions that have been configured = accordingly.

_________________________________________________________
Michael= = Sweet, Senior Printing System Engineer, PWG = Chair

________________________________________________________= _
Michael Sweet, Senior = Printing System Engineer, PWG Chair

K= ey	D= escription	D= efault
push=	A co= mma separated list using the following keywords: http, https, ftp, ftps, sm= b, ipp, ipps, mailto. Vendors may extend the set of values.	Push= scan is not supported

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