Hi there,
I agree that Push should be optional.
Would we imagine that a client would filter on the Push URI schemes it supported? If so, Pete’s key with a value listing the supported schemes is preferable.
For advertising Push via DNS-SD, the design decision should come down to balancing the size of the TXT record against the desire to discover or filter this capability using purely the values in the TXT record vs. having to do a follow-up interrogation, which is generally expensive and not desirable.
Also, should IPP Scan include a way for the MFD to find Push scan destinations?
Smith
/**
Smith Kennedy
ATB Wireless Architect - PPS
Hewlett-Packard Co.
*/
On 2014-02-10, at 3:31 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> Hi Mike and Pete,
>> What about a simple TXT record discovery attribute for Push capability that's boolean?
> Since a bunch of URI schemes are conditionally mandatory anyway, that gets 90% of
> the discovery need.
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
>http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc> mailto: blueroofmusic at gmail.com> Winter 579 Park Place Saline, MI 48176 734-944-0094
> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
>>>> On Mon, Feb 10, 2014 at 3:29 PM, Michael Sweet <msweet at 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 at 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 at Xerox.com>> Office: +1 (585) 265-8755
>>>> Mobile: +1 (585) 329-9508
>> FAX: +1 (585) 265-7441
>> US Mail: Peter Zehler
>> Xerox Corp.
>> 800 Phillips Rd.
>> M/S 128-25E
>> Webster NY, 14580-9701
>>>>>> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Michael Sweet
>> Sent: Monday, February 10, 2014 3:07 PM
>> To: Zehler, Peter
>> Cc: IPP at 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 at 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 “http”, “https”, “ftp” and “ftps URI schemes MUST be supported.
>>>>>>>> Any objections?
>>>>>>>> Peter Zehler
>>>> Xerox Research Center Webster
>> Email: Peter.Zehler at Xerox.com>> Office: +1 (585) 265-8755
>>>> Mobile: +1 (585) 329-9508
>> FAX: +1 (585) 265-7441
>> US Mail: Peter Zehler
>> Xerox Corp.
>> 800 Phillips Rd.
>> M/S 128-25E
>> Webster NY, 14580-9701
>>>>>>>> _______________________________________________
>> ipp mailing list
>>ipp at 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 at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140210/ab0f10a7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3319 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140210/ab0f10a7/attachment.p7s>