Hi Mike,
destination-uri-ready (1 setOf collection) sounds like an useful attribute.
It may be useful even for IPP and IPPS schemes (both in FaxOut and Scan) and we could add attributes for authentication (incl password digest/token type(s), MFD managed/user provided) as required. For every destination-uri in Job attributes, we could also specify optional fields for authentication (user, password, password-type). If we start dealing with authentication information here, I'd think that we should strongly recommend that only IPPS clients send authentication information.
One may consider the security aspect of the user providing authentication information for a third party service to the MFD; but we can imagine those third party services generating OTP tokens for use here.
Regards,
Somasundaram.
-----Original Message-----
From: Michael Sweet [msweet at apple.com<mailto:msweet at apple.com>]
Sent: Friday, March 21, 2014 06:40 AM Pacific Standard Time
To: Soma Meiyappan
Cc: Peter Zehler; IPP at pwg.org
Subject: Re: [IPP] Prototype version of IPP Scan Service specification available
Soma,
On Mar 21, 2014, at 7:14 AM, Soma Meiyappan <Soma.Meiyappan at conexant.com<mailto: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> [mailto:ipp-bounces at pwg.org] On Behalf Of Zehler, Peter
Sent: Monday, March 03, 2014 10:10 PM
To: IPP at pwg.org<mailto: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.pdfhttp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227.pdfftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227.docxhttp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227.docxftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227-rev.pdfhttp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227-rev.pdfftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227-rev.docxhttp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140227-rev.docx
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com<mailto: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<http://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<mailto: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/52fbecf7/attachment.html>