Subject: [IPP] Are these attributes what were agreed to for IPP Scan?

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 8 Apr 2014 19:07:14 +0000

All,
Before I put out the Stable version of the IPP Scan specification I wanted to check with you regarding the addition of the attributes below.  Let me know if it does not capture what we agreed to at the IPP teleconference.  I plan to publish it on Thursday.
Pete

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]<mailto:[email-masked]>
Office: +1 (585) 265-8755
Mobile: +1 (585) 329-9508
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

Added the following new member element to the Job Template Attribute "destination-uris"

8.2.1.1  destination-attribute-collection (1setOf collection)

This OPTIONAL attribute allows the client to specify attributes to be applied to the method implied by the "destination".  For example if the destination uri scheme is "ipp://" this attribute would contain Operation and Job Template Attributes to be used in the creation of the IPP Print Job.

Added the following new IPP Scan Service Description Attribute

8.4.2        destination-uri-ready  (1setOf collection)

The OPTIONAL "destination-uri-ready" IPP Scan Service attribute lists the configured destinations.  This does not limit the destinations that a user may specify.  It is a list of administratively set destinations to assist the user in selecting an appropriate destination. IPP Scan Services that support Push Scan MAY support this attribute.

8.4.2.1  destination-info (text(MAX))

The OPTIONAL "destination-info" member attribute provides a human readable description of the destination.

8.4.2.2  destination-is-directory (boolean)

  The OPTIONAL "destination-is-directory" member attribute indicates if the destination is a folder that can contain multiple files.  The default value if this attribute is not included is 'false'.

8.4.2.3  destination-name (name(MAX))

The OPTIONAL "destination-name" member attribute provides a human readable user friendly name for the destination.

8.4.2.4  destination-uri (uri)

The REQUIRED "destination-uri" member attribute specifies the destination.

8.4.2.5  destination-attribute-collection (1setOf collection)

This OPTIONAL "destination-attribute-collection" member attribute allows the administrator to specify attributes to be applied to the "destination-attribute-collection" Job Template Attribute (See section 8.2.1.1).

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

---

From: Ira McDonald <[email-masked]>
Date: Tue, 8 Apr 2014 15:15:06 -0400

Hi Pete,

These all look right to me.

Mike - WDYT?

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 Tue, Apr 8, 2014 at 3:07 PM, Zehler, Peter <[email-masked]>wrote:

>  All,
>
> Before I put out the Stable version of the IPP Scan specification I wanted
> to check with you regarding the addition of the attributes below.  Let me
> know if it does not capture what we agreed to at the IPP teleconference.  I
> plan to publish it on Thursday.
>
> Pete
>
>
>
> Peter Zehler
>
> Email: [email-masked]
> This OPTIONAL attribute allows the client to specify attributes to be
> applied to the method implied by the "destination".  For example if the
> destination uri scheme is "ipp://" this attribute would contain Operation
> and Job Template Attributes to be used in the creation of the IPP Print Job.
>
>
>
> The OPTIONAL "destination-uri-ready" IPP Scan Service attribute lists the
> configured destinations.  This does not limit the destinations that a user
> may specify.  It is a list of administratively set destinations to assist
> the user in selecting an appropriate destination. IPP Scan Services that
> support Push Scan MAY support this attribute.
>
>   The OPTIONAL "destination-is-directory" member attribute indicates if
> the destination is a folder that can contain multiple files.  The default
> value if this attribute is not included is 'false'.
>
> This OPTIONAL "destination-attribute-collection" member attribute allows
> the administrator to specify attributes to be applied to the
> "destination-attribute-collection" Job Template Attribute (See section
> 8.2.1.1).
>
>
>
>
>
>
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 08 Apr 2014 15:28:21 -0400

Pete,

My only beef with the proposed additions are the "destination-attribute-collection" attributes.

We should just include Job Template attributes directly in the destination-uris and destination-uri-ready collections. Thus, it would just be:

    destination-uris
        destination-uri
        [number-or-retries]
        [retry-interval]
        [retry-time-out]
        [any Job Template attribute]

    destination-uri-ready
        destination-uri
        [destination-info]
        [destination-is-directory]
        [destination-name]
        [any Job Template attribute]

This would be consistent with how other attributes (job-sheets-col, covers, etc.) deal with embedding Job Template attributes in collection attributes.

If you really want to put the Job Template attributes in their own collection, call it "destination-attributes"; we never use "collection" spelled out in the name, and generally only add -col if there is already a non-collection form of the attribute (e.g. media and media-col, finishings and finishings-col, etc.)

On Apr 8, 2014, at 3:07 PM, Zehler, Peter <[email-masked]> wrote:

> Added the following new member element to the Job Template Attribute “destination-uris”
> This OPTIONAL attribute allows the client to specify attributes to be applied to the method implied by the “destination”.  For example if the destination uri scheme is “ipp://” this attribute would contain Operation and Job Template Attributes to be used in the creation of the IPP Print Job.
>  
> The OPTIONAL “destination-uri-ready” IPP Scan Service attribute lists the configured destinations.  This does not limit the destinations that a user may specify.  It is a list of administratively set destinations to assist the user in selecting an appropriate destination. IPP Scan Services that support Push Scan MAY support this attribute. 
> The OPTIONAL “destination-info” member attribute provides a human readable description of the destination.
>   The OPTIONAL “destination-is-directory” member attribute indicates if the destination is a folder that can contain multiple files.  The default value if this attribute is not included is ‘false’.
> The OPTIONAL “destination-name” member attribute provides a human readable user friendly name for the destination.
> The REQUIRED “destination-uri” member attribute specifies the destination.
> This OPTIONAL “destination-attribute-collection” member attribute allows the administrator to specify attributes to be applied to the “destination-attribute-collection” Job Template Attribute (See section 8.2.1.1).
>  
>  
>  

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Soma Meiyappan <[email-masked]>
Date: Tue, 8 Apr 2014 21:13:23 -0700

Mike/Pete,

May I know how PWG solves supporting IPP destinations (and other HTTP destinations) that need authentication when used as a destination in FaxOut/Scan2 defined workflows?

Are authentication information for URIs under destination-uri-ready  (implicitly) managed by the MFD as it appears that the specification does not provide any destination specific attributes in the destination-uri collection to provide authentication credentials? Or should authentication information be provided in the URI as it is done for some http URI allows like http://user:[email-masked]/folder? If so, I would wonder about IPP destinations and ipp/ipps URIs.

Please see the attached email that I had sent earlier on the topic.

Thanks and Regards,
Somasundaram.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Wednesday, April 09, 2014 3:28 AM
To: Peter Zehler
Cc: [email-masked]
Subject: Re: [IPP] Are these attributes what were agreed to for IPP Scan?

Pete,

    destination-uris
        destination-uri
        [number-or-retries]
        [retry-interval]
        [retry-time-out]

    destination-uri-ready
        destination-uri
        [destination-info]

On Apr 8, 2014, at 3:07 PM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:

All,

Peter Zehler

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

Subject: Re: [IPP] Prototype version of IPP Scan Service specification available
From: Soma Meiyappan <[email-masked]>
To: 'Michael Sweet' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Fri, 21 Mar 2014 07:52:40 -0700
List-Id: Internet Printing Protocol Workgroup discussion list <ipp.pwg.org>

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

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

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 9 Apr 2014 10:49:00 +0000

Mike,
I really want to put the Job Template Attributes in a collection.  I will change the name and drop "-collection".  The contents of the collection is not strictly limited to IPP Job Template Attributes.
Pete

Peter Zehler

From: Michael Sweet [mailto:[email-masked]]
Sent: Tuesday, April 08, 2014 3:28 PM
To: Zehler, Peter
Cc: [email-masked]
Subject: Re: [IPP] Are these attributes what were agreed to for IPP Scan?

Pete,

    destination-uris
        destination-uri
        [number-or-retries]
        [retry-interval]
        [retry-time-out]

    destination-uri-ready
        destination-uri
        [destination-info]

All,

Peter Zehler

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 9 Apr 2014 11:23:04 +0000

Somasundaram,
In IPP the destinations for fax/scan are handled the same way sources are handled for print by reference.  Authentication credentials of the user are not given to the IPP Printer/FaxOut/Scanner to gain access.  AAA of the referenced document/destination is not incorporated into the protocol or model.  Based on market and customer requirements the appropriate security scheme is used in the implementation.  The IPP specification does not dictate the required security model.  For example the destination could be public or restricted to only allowing write access by the scan service.  Other alternatives include the inclusion of access tokens in the URL as is used with OAUTH's Resource Owner Credentials Grant.  One of the reasons for the "destination-uri-ready" was to assist the user in a secure environment determine the destinations available for the deployment.  As with any IPP attributes the values returned by the Server can be filtered based on the Client's current role.
Pete

Peter Zehler

From: Soma Meiyappan [mailto:[email-masked]]
Sent: Wednesday, April 09, 2014 12:13 AM
To: Michael Sweet; Zehler, Peter
Cc: [email-masked]
Subject: RE: [IPP] Are these attributes what were agreed to for IPP Scan?

Mike/Pete,

Thanks and Regards,
Somasundaram.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Wednesday, April 09, 2014 3:28 AM
To: Peter Zehler
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [IPP] Are these attributes what were agreed to for IPP Scan?

Pete,

    destination-uris
        destination-uri
        [number-or-retries]
        [retry-interval]
        [retry-time-out]

    destination-uri-ready
        destination-uri
        [destination-info]

All,

Peter Zehler

---

From: Michael Sweet <[email-masked]>
Date: Wed, 09 Apr 2014 08:19:22 -0400

Soma,

> May I know how PWG solves supporting IPP destinations (and other HTTP destinations) that need authentication when used as a destination in FaxOut/Scan2 defined workflows?

It is currently undefined at the protocol level (meaning that it is up to each implementation to do something about it), just as how to deal with authentication of document URIs is at present.

This is pending work in the IDS workgroup.  CUPS has the "auth-info" and "auth-info-required" attributes, as well as a job-state-reasons keyword and IPP operation as extensions to IPP for dealing with authentication for a printer's output device (usually another computer/server that is sharing a print queue), but there are practical limitations to the approach.

> Are authentication information for URIs under destination-uri-ready  (implicitly) managed by the MFD as it appears that the specification does not provide any destination specific attributes in the…

Embedding user credentials in HTTP and IPP URIs is not recommended, and in fact the current HTTP and IPP URI scheme definitions forbid it.

(FWIW, CUPS also supports this kind of authentication for the output device URI, but we've had to go through a lot of hoops over the years to hide the information from prying eyes.  Definitely not recommended!)

---

From: "Soma Meiyappan" <[email-masked]>
Date: Wed, 9 Apr 2014 05:46:55 -0700

Mike/Pete,

Thank you very much for your response.

I wanted to follow-up on that as it appeared 'authentication for destination' wasn't addressed for FaxOut/Scan2 destinations while those IPP/http destinations may require authentication. So, wanted to understand what all of you think about that.

I am certainly not a fan of passing down credentials unless the client sends OTP over a secure connection. Of course, there is always a risk of a fake service.

It helps to know that dealing with authentication for destination was consciously left 'undefined'. And thanks for letting me know that the current HTTP URI scheme "forbids" the use of embedding credentials in the URI. So, it appears that MFDs do not have to necessarily add support for credentials in the 'http' destination-uri after all as the standards do not allow that technical possibility.

Thanks and Regards,
Somasundaram.

From: Michael Sweet [mailto:[email-masked]]
Sent: Wednesday, April 09, 2014 8:19 PM
To: Soma Meiyappan
Cc: Peter Zehler; [email-masked]
Subject: Re: [IPP] Are these attributes what were agreed to for IPP Scan?

Soma,

On Apr 9, 2014, at 12:13 AM, Soma Meiyappan <[email-masked]<mailto:[email-masked]>> wrote:
Mike/Pete,

Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer ****************************

---

From: Michael Sweet <[email-masked]>
Date: Wed, 09 Apr 2014 09:26:01 -0400

Pete,

Which operation attributes do you want to include?

attributes-charset
attributes-natural-language

These can be taken from the Job already.

compression or compression-accepted

Certainly a possibility, although the Client probably doesn't know the destination's capabilities so we might want to use "compression-accepted" attribute to list what is acceptable to the Client.  Using "compression-accepted" would also address security considerations for compression (BEAST and other attacks) that we've never talked about in the PWG - the Client is the only entity with the context to know whether it is safe to compress the output from a security perspective...

document-charset
document-metadata
document-name
document-natural-language

These can be taken from the Job or generated by the Scan service.

document-digital-signature
document-format
document-format-details
job-impressions
job-impressions-estimated

These are generated/set by the Scan service.

document-password
job-password
job-password-encryption

These are explicitly *not* part of the Job Ticket for security reasons, and thus we cannot include them in the "destination-attributes" collection.  And while it is possible we could introduce a parallel operation attribute ("destination-operation-attributes (1setOf collection)"?) that seems a bit too hackish.

ipp-attribute-fidelity
job-mandatory-attributes

These could be take from the Job, but I can see how you might want to apply fidelity to a specific destination.

job-authorization-uri

Implementation-defined behavior until we have a standard for passing credentials through (to be used with Validate-Job to get the job-authorization-uri value...)

original-requesting-user-name
requesting-user-name
requesting-user-uri

These can be taken from the Job; supporting it per-destination seems like we are trying to address identity-passing without authentication...

....

Also, if we do a "destination-attributes (collection)" Job Template and member attribute then we'll need a "destination-attributes-supported" Printer Description attribute.  I don't see a need for a -default version, as there is no -default for the destination, but we'll need to make it clear whether any "destination-attributes" attribute in the "destination-uri-ready" value is used as the default for that destination URI.

On Apr 9, 2014, at 6:49 AM, Zehler, Peter <[email-masked]> wrote:

> Mike,
> I really want to put the Job Template Attributes in a collection.  I will change the name and drop “-collection”.  The contents of the collection is not strictly limited to IPP Job Template Attributes.
> Pete
>  
> Peter Zehler
>