Smith,
On Feb 10, 2014, at 5:51 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at 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’s key with a value listing the supported schemes is preferable.
See my other message to Ira; I don't see clients doing this, if for any other reason that having the printer push the content to a destination is simply a software optimization - the client is perfectly capable of pulling the content and forwarding it to the destination on its own.
> For advertising Push via DNS-SD, the design decision should come down to balancing the size of the TXT record against the desire to discover or filter this capability using purely the values in the 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140211/3e6c3a68/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140211/3e6c3a68/attachment.p7s>