[IPP] Prototype version of IPP Scan Service specification available

[IPP] Prototype version of IPP Scan Service specification available

[IPP] Prototype version of IPP Scan Service specification available

Ira McDonald blueroofmusic at gmail.com
Fri Mar 21 19:02:50 UTC 2014


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/blueroofmusic
http://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>


More information about the ipp mailing list