Hi,
I don't like "destination-uri-ready" at all. It doesn't scale. It doesn't
add any
visible utility. It's actively a bad idea for IPP Everywhere as a pervasive
print protocol.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Fri, Mar 21, 2014 at 10:52 AM, Soma Meiyappan <
Soma.Meiyappan at conexant.com> wrote:
> 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]
> *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>
> 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<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
>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140321/f5a4ea0e/attachment.html>