Subject: Re: [IPP] Prototype version of IPP Scan Service specification available

From: Soma Meiyappan <[email-masked]>
Date: Fri, 21 Mar 2014 07:52:40 -0700

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 [[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 21, 2014 06:40 AM Pacific Standard Time
To: Soma Meiyappan
Cc: Peter Zehler; [email-masked]
Subject: Re: [IPP] Prototype version of IPP Scan Service specification available

Soma,

On Mar 21, 2014, at 7:14 AM, Soma Meiyappan <[email-masked]<mailto:[email-masked]>> 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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Zehler, Peter
Sent: Monday, March 03, 2014 10:10 PM
To: [email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Fri, 21 Mar 2014 15:02:50 -0400

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: [email-masked]
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 <
[email-masked]> wrote:

> 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.
>
>
>
>
> *From: *Michael Sweet [[email-masked]]
> *Sent: *Friday, March 21, 2014 06:40 AM Pacific Standard Time
> *To: *Soma Meiyappan
> *Cc: *Peter Zehler; [email-masked]
> *Subject: *Re: [IPP] Prototype version of IPP Scan Service specification
> available
>
> Soma,
>
>  On Mar 21, 2014, at 7:14 AM, Soma Meiyappan <[email-masked]>
> 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?
>
>
> 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:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of* Zehler, Peter
> *Sent:* Monday, March 03, 2014 10:10 PM
> *To:* [email-masked]
> *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
>
>
>
> Email: [email-masked]
> 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
> "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."
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 24 Mar 2014 11:04:41 -0400

Ira,

On Mar 21, 2014, at 3:02 PM, Ira McDonald <[email-masked]> wrote:
> Hi,
> 
> I don't like "destination-uri-ready" at all.  It doesn't scale.  It doesn't add any

The "destination-uri-ready" attribute would *not* be used for Print since there we specify destination with "printer-uri" and potentially "output-device", and there we already have an "output-device-supported" attribute that clients can use for fan-out services.

However, for Scan, FaxOut, etc. where the destination is not specified by the "printer-uri" attribute, it would give clients and way to tell the Client about site-configured destinations, beyond the simple "you can scan to email" kinds of things the current "destination-uri-schemes-supported" attribute provides.  There is also precedent for such an attribute - JPS2 defines a similar "save-location-supported (1setOf uri)" attribute for Job save.

I am specifically thinking of Pete's workflow environment where the Scan service might need to submit scanned documents to a local service - by having an attribute that lists local bookmarks/presets the Client can present this as a choice to the user beyond entering a URL or email address.  And it allows for implementation-specific things in the case of HTTP, since there you might want something other than a bare PUT of the document images.

So, let's say we define "destination-uri-ready" as follows:

    destination-uri-ready (1setOf collection)
      destination-is-directory (boolean)      [true if the URI refers to a directory; Client adds /name to the end]
      destination-name (name(MAX))            [localized name of URI]
      destination-uri (uri)                   [destination-uri that can be included in job creation request]

And a Scan service reports:

    destination-uri-schemes-supported = "ftp", "http", "https", "ipp", "ipps", "mailto", "smb"
    destination-uri-ready =
        { destination-is-directory=true destination-name="Archive" destination="http://storage.example.com/archives/" },
        { destination-name="OCR and Email" destination="ipps://ocr.example.com/ipp/ocr+email" },
        { destination-name="OCR and Archive" destination="https://storage.example.com/ocr" }

The Client would then allow the user to enter a URI and/or email address, or pick from one of the three "ready" destinations that have been configured on the Scan service.  It specifically would *not* be used as an address book of all local email addresses - that's what LDAP is for.  Instead, it is about Client discovery of local receiving services with implementation-specific configuration of those services by a local owner/operator/administrator.

....

The other attribute I proposed was "document-uri-ready", which would be applicable to Print, EmailOut, and FaxOut, and could be a lightweight way to expose document resources provided by the service or by other local services, such as cover pages, brochures, and other standard content that has been configured on the service.

I am less enthusiastic about this attribute because practical applications of print-by-reference tend to be tightly controlled/managed in integrated solutions that have already "solved" this particular discovery problem.  That said, the same kind of solution could be defined if there is interest...