Soma,
On Mar 21, 2014, at 7:14 AM, Soma Meiyappan <Soma.Meiyappan at conexant.com> wrote:
> Hi Pete,
>> Minor detail on the ‘http’/’https’ scheme for Scan2:
>> http is a transport for a number of application level protocols: One can use that to refer to standard PUT method or a RESTful method to store data on the destination. It would make sense that PUT is implied. Should the specification explicitly exclude RESTful methods from this and define another mechanism for identifying the supported destinations that are RESTful in nature?
We've never fully-specified how HTTP/HTTPS URIs are used, in SM or IPP.
It would be useful to say something here ("http" and "https" refer to destinations that support the HTTP PUT method using only standard HTTP headers), since POST requests will likely have specific header and/or message body requirements we aren't prepared to deal with. Conceptually new "http+post" and "https+post" URI schemes could be defined that allow for HTTP POST usage, although that would be a bit trickier.
How about adding a "destination-uri-ready (1setOf uri)" (or 1setOf collection to allow for a description/name along with the URI) attribute to list ready/configured destinations? Conceptually that would support typical workflow scenarios and allow the service to be configured for different HTTP protocol bindings. Specifying a URI that hasn't been pre-configured would revert to HTTP PUT.
Thoughts?
(FWIW, the same could be done for document-uri's - that would support forms and other predefined content and make print-by-reference more useful)
>> Regards,
> Somasundaram.
>> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Zehler, Peter
> Sent: Monday, March 03, 2014 10:10 PM
> To: IPP at pwg.org> Subject: [IPP] Prototype version of IPP Scan Service specification available
>> All,
> I have posted the prototype version of “IPP Scan Service. Send any comments to the IPP mail list. We are looking for companies interested in prototyping this specification
>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227.pdf>http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227.pdf>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227.docx>http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227.docx>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227-rev.pdf>http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227-rev.pdf>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227-rev.docx>http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227-rev.docx>>>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>>> 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."
>> **********************************************************************
>> ---------------------------------------------------------------------
> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140321/12122c93/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/20140321/12122c93/attachment.p7s>