Hi Mike,
Please find my thoughts inline with the prefix [Soma]
Regards,
Somasundaram.
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Tuesday, February 18, 2014 9:10 PM
To: Soma Meiyappan
Cc: Peter Zehler; IPP at pwg.org
Subject: Re: [IPP] IPP Scan - Is Push scanning mandatory?
Soma,
On Feb 14, 2014, at 6:07 PM, Soma Meiyappan <Soma.Meiyappan at conexant.com<mailto:Soma.Meiyappan at conexant.com>> wrote:
Gentlemen,
The proposed Scan2 seems to bear a resemblance to FaxOut's send-from-glass capabilities. Of course, one may consider a slight difference in scan capabilities between a scan service and a faxout service for the scan service to be a more suitable host for non-fax digital sends. However, should we consider any potential duplication of features between IPP services and a confusion between clients/servers on the service where this functionality will be made available? I agree that it does not prevent device manufacturers from implementing similar functionality through both IPP services. But I wanted to hear your thoughts on this.
This does come up from time to time.
FaxOut has certain legal requirements that Scan does not. So, you'll find in the Scan spec a prohibition to support tel:, fax:, and other facsimile schemes because the Scan service does not support the things required for it.
And while we don't have a similar prohibition in the FaxOut service for non-fax schemes, the addition of fax headers to the scanned documents may make using FaxOut as a replacement for Scan-to-Email (for example) less likely, unless the user truly wants to meet some arbitrary legal requirement (i.e. faxed documents are acceptable, digital documents are not...)
[Soma] When US federal TCPA law talks about fax headers/cover-page for fax machines/senders, should it be interpreted as being applicable for images transmitted through tel: and fax: schemes only and not to mailto:, ipp:, etc..., which inherently involve digital formats with richer meta-data capabilities? Document sent using these digital formats can identify the sender through a username that is embedded in the file (be it a PDF, TIFF or JPEG). If the IPP FaxOut specification should be interpreted such that the same content (incl the header) should be sent to all destinations (irrespective of the destination scheme), then it makes the case for "push-scan" in IPP Scan stronger.
If the MFD's FaxOut processing can format the scanned data according to the destination scheme, then one can imagine the MFD sending the scanned data without fax like headers for destinations of specific schemes like mailto:, ipp:, http:. If this holds, then for a "push-scan" like workflow, the user will anyways provide digital destinations like mailto:, http:, etc.... only for the "FaxOut from glass job" and the same content from glass is both fax'ed and shared/archived through other schemes using IPP's FaxOut thereby making the case for "push-scan" in IPP Scan service weaker.
*If* there is a use case for discovery of fax services that can deliver using a particular URI scheme, we could add a corresponding "Fax2" TXT key, however nobody has asked for it... (and FWIW, I would argue it would be more useful than the Scan2 key, since at least then you are discovering a delivery capability that cannot be easily reproduced in software...)
[Soma] If the case for PushScan exists and if a device supports it, then I can see Scan2 (or Fax2) in TXT record being useful especially with the discovery features in Wifi-Direct/P2P and in a kiosk like environment where the IPP client may not have other network connectivity. Anyways, I do not want to revisit that discussion on Scan2 TXT key now. While I will be concerned about the TXT record length if we were to include the schemes for the key, I hope that we will not breach the often used 400/512 byte limit for compatibility reasons.
_________________________________________________________
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/20140219/a166a670/attachment.html>