Thank you very much for your response, Mike. Please find my comments below with [Soma2].
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Monday, March 17, 2014 10:31 PM
To: Soma Meiyappan
Cc: Peter Zehler; IPP at pwg.org
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?
(Apologies for the late reply; I am still working through a backlog of email...)
On Feb 19, 2014, at 4:22 AM, Soma Meiyappan <Soma.Meiyappan at conexant.com<mailto:Soma.Meiyappan at conexant.com>> wrote:
...
[Soma] When US federal TCPA law talks about fax headers/cover-page for fax machines/senders, should it be interpreted as being applicable for images transmitted through tel: and fax: schemes only and not to mailto:, ipp:, etc..., which inherently involve digital formats with richer meta-data capabilities?
IANAL, but an application claiming to offer Internet Fax capabilities will likely be subject to the same regulations that traditional fax is subject to. Naturally this will depend on local laws and regulations, and certainly if the destination is an ipp: or ipps: URI then the job ticket/accounting information can be passed out-of-band rather than embedded in the delivered images.
[Soma2] Ok. It may be useful to add information related to headers in IPP FaxOut documents. But I can understand if as a standard, IPP does not want to talk about this as it is subject to local laws and regulation.
Document sent using these digital formats can identify the sender through a username that is embedded in the file (be it a PDF, TIFF or JPEG).
Generally speaking, we (the PWG) do not like embedding job ticket/accounting information in the PDL.
[Soma2] Sure. I was trying to imply that there are digital formats in which the originator's (sender's) information can be embedded within it as a meta-data instead of as a fax header as the law's objective is for the receiver to identify the sender. But if the assumption that all FaxOut schemes will be subject to the same regulations as fax/tel is true, then this does not matter anyways.
If the IPP FaxOut specification should be interpreted such that the same content (incl the header) should be sent to all destinations (irrespective of the destination scheme), then it makes the case for "push-scan" in IPP Scan stronger.
I don't think we can require push scan support, as the hardware requirements may preclude support on some printers (think: non-networked MFDs that support IPP USB and the various IPP services...) And more to the point, push scan can be simulated even by embedded/mobile devices that might be used to initiate a scan.
[Soma2] I am not implying that "Push scan" should be made mandatory. I agree that push scan can still be simulated by using an external client to "scan and send". But as a standard, I would expect IPP-Scan to enable the OEMs to differentiate their in-machine's capabilities with built-in 'push scan' functions that can be initiated through a standard client.
...
*If* there is a use case for discovery of fax services that can deliver using a particular URI scheme, we could add a corresponding "Fax2" TXT key, however nobody has asked for it... (and FWIW, I would argue it would be more useful than the Scan2 key, since at least then you are discovering a delivery capability that cannot be easily reproduced in software...)
[Soma] If the case for PushScan exists and if a device supports it, then I can see Scan2 (or Fax2) in TXT record being useful especially with the discovery features in Wifi-Direct/P2P and in a kiosk like environment where the IPP client may not have other network connectivity.
WFDS has its own service descriptors and does not use Bonjour. At present, Bonjour is only used for Infrastructure Wi-Fi and wired networking, not P2P.
[Soma2] Ok.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
---------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140321/2b380e98/attachment.html>