Subject: [IPP] PWG: Canon proposal to extend the IPP Preset draft specification

From: "Yardumian, Rick" <[email-masked]>
Date: Fri, 20 Oct 2017 17:49:19 +0000

Hi,

Please read and send feedback on the attached Canon proposal  for extending the current IPP Preset draft specification. It allows printers to apply preset job attributes that a client does not directly support. I personally find this proposal interesting and useful since one of the biggest issues with driverless printing (aka universal driver) is that typical IPP clients only support a small subset of the possible IPP printer capabilities.

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

---

From: Michael Sweet <[email-masked]>
Date: Fri, 20 Oct 2017 15:59:16 -0400

Rick,

The current proposal allows a client to display a single "chooser" control to select a named preset provided by the printer, so it seems like the functionality requested here is already covered.

The difference in implementation is that right now the client is responsible for copying the Job Template attributes from the job-presets-supported collection value to the job creation request, instead of having the printer do so.

A client UI might not display controls for every job template attribute, but it can certainly copy attributes from the preset to the job creation attributes and/or to the controls it does provide.

I think having the printer copy preset attributes into the job is more complicated and somewhat problematic. It would require us to define the order of precedence, how to handle attribute fidelity, when to copy preset attributes, and amend the job creation operations to support all of it.  It would probably also warrant making this registration a full specification since we'd be extending the job creation operations.

So maybe the action to take here is to clarify how the attributes are used and how a client can support arbitrary attributes in the preset without necessarily supporting those attributes in the client UI?

> On Oct 20, 2017, at 1:49 PM, Yardumian, Rick <[email-masked]> wrote:
> 
> Hi,
>  
> <IPP_Preset_improvement_proposal_20171020_E.pptx>_______________________________________________
> ipp mailing list
> [email-masked]

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 23 Oct 2017 20:02:01 +0000

Hi Rick,

Thanks very much for posting this! Mike already replied with feedback, and I'm going to contribute to that as well, but I wanted to voice my appreciation for you raising this topic, because it is important for unlocking some of the value that Presets provides, especially in "omni-driver" systems like IPP Everywhere™.

Cheers,

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
    Chair, IEEE ISTO Printer Working Group
    HP Inc.
*/

> On Oct 20, 2017, at 11:49 AM, Yardumian, Rick <[email-masked]> wrote:
> 
> Hi,
>  
> [email-masked] <mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 23 Oct 2017 21:16:17 +0000

Hi Mike,

It seems to me that Canon's proposal is simply to require that the Client pass back to the Printer the "preset-name" if one is chosen. But if I understand your feedback, if the Client provides the "preset-name" in the Job Creation operation, then we have to be clear about which attribute value takes precedence when one value is also included in the Job Creation operation and is also present in the Preset.  This might arise if a user selects a preset and then makes further selections that effectively overwrite the value(s) listed in the preset.

I like your alternative, because it keeps things simpler. But from a purely PWG / certification / compliance point of view, I'm not sure how we would go about certifying that the Client will behave properly.

As you said, let's please discuss at this week's call.

Smith

/**
    Smith Kennedy

> On Oct 20, 2017, at 1:59 PM, Michael Sweet <[email-masked]> wrote:
> 
> Rick,
>

---

From: Takeshi KANEDA <[email-masked]>
Date: Thu, 26 Oct 2017 19:36:19 +0900

Hello, Mr. Smith Kennedy. 
Hello, Mr. Michael Sweet.

This is Kaneda at Canon Inc. Thank you for your opinions. 

We would like to express our opinion on Canon as to the feedback wereceived. 
Please refer to attached file. 

The password is "ipp-preset".

If you have any questions, please reply this mail. (Even if you contact Rick, it is OK.)

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

---

From: Michael Sweet <[email-masked]>
Date: Thu, 26 Oct 2017 15:00:30 -0400

OK, I've reviewed your PDF.  Some feedback:

- Slide 3: Aside from some server implementations, Clients pretty much universally have greater resources than Printers. And RFC 8011 places specific requirements on Client implementations WRT supporting all defined attribute syntaxes, including the collection attribute syntax used for job-presets-supported.  So IMHO Client limitations are not a realistic concern for this attribute.

- Slide 5: There is no such thing as non-IPP attributes in a preset.  They are all IPP attributes, and by definition the only member attribute in the collection that is not used by the Client as a Job Template attribute is the "preset-name" member attribute.

- Slide 6: Conforming client implementations MUST support all of the attribute syntaxes defined in RFC 8011, so this is not a realistic concern IMHO.  We can make this explicit in the definition of job-presets-supported if you like, but it isn't explicitly necessary since the definition of the attribute says that the collection contains Job Template attributes to be copied to the job creation request.

> On Oct 26, 2017, at 6:14 AM, Takeshi KANEDA <[email-masked]> wrote:
> 
> 
> This is Takeshi Kaneda at Canon Inc. Thank you for your opinions. 
> 
> we would like to express our opinion on Canon as to the feedback we received. 
> Please refer to attached file. The password is "ipp-preset".
> 
> <IPP_Preset_improvement_proposal_20171025.pdf>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 26 Oct 2017 15:23:04 -0400

WRT slide 5, during the IPP WG concall today the following question came up:

- What is meant by "non-IPP attributes"?  Is it a vendor-specific attribute ("canon-foo", etc.), or is it out-of-band data associated with the named preset, or ???

> On Oct 26, 2017, at 3:00 PM, Michael Sweet <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 16:31:12 -0400

Kaneda-san,
I would add the following to Michael’s comments, based on the IPP workgroup discussion:
1. We agree with your observation that the document is not clear with respect to  “the  client is responsible for copying the Job Template attributes from the job-presets-supported collection value to the job creation request” and  that  these preset-specified  Job Template attribute values in the Job Creation request may be overwritten by the Client upon input from the User.  The document will be updated so that this is clearly stated.
2. Because the client is to return the contents of the selected preset in the job creation request (except for values changed by the User or Client), regardless of whether or not  the client displays the Preset collection to the user, the contents of the selected preset is returned to the printer (except for any attribute values changed). 
3. If the printer needs to the know the preset selected, possibly for handling of  non-standard IPP attributes that may be unknown to the Client, 
perhaps the best approach would be to include in the Preset  a vendor extension  attribute  that would also be returned with the Job Template attributes.

Thank you for your contribution to defining this proposed IPP capability.

Bill Wagner

From: Michael Sweet
Sent: Thursday, October 26, 2017 3:33 PM
To: Takeshi KANEDA
Cc: [email-masked]; HOSODA Osamu
Subject: Re: [IPP] [!!]Re: PWG: Canon proposal to extend the IPP Presetdraftspecification

Thank you.

---

From: HOSOKAWA Yuko <[email-masked]>
Date: Fri, 27 Oct 2017 08:51:47 +0900

Bill-san, attended members,

This is Yuko Hosokawa from Canon. 

First of all, thank you for reviewing our slides even though none of Canon
member could attend the meeting.. :-)

I think we have confused you by using the term "non-IPP-attributes"
What we meant was "vendor-specific-attributes" which the client does not know.

> 1. We agree with your observation that the document is not clear with respect to 
Thank you and we appreciate it.

> 2. Because the client is to return the contents of the selected preset in the job creation request
> 3. perhaps the best approach would be to include in the Preset  a vendor extension  attribute  that would also be returned with the Job Template attributes.

If client is to return all the contents of preset including 
"vendor-specific extension" is clearly defined in the document,
yes, we agree with your proposal.

We would like to see the final draft.

Thank you.
Yuko Hosokawa[Canon-OIP]

On Thu, 26 Oct 2017 16:31:12 -0400
<[email-masked]> wrote:

> 2. Because the client is to return the contents of the selected preset in the job creation request 
(except for values changed by the User or Client), regardless of whether
or not  the client displays the Preset collection to the user, the
contents of the selected preset is returned to the printer (except for
any attribute values changed). 

> - What is meant by "non-IPP attributes"? ?Is it a vendor-specific attribute ("canon-foo", etc.), or is it out-of-band data associated with the named preset, or ???
> 
> 
> 
> OK, I've reviewed your PDF. ?Some feedback:
> 
> - Slide 3: Aside from some server implementations, Clients pretty much universally have greater resources than Printers. And RFC 8011 places specific requirements on Client implementations WRT supporting all defined attribute syntaxes, including the collection attribute syntax used for job-presets-supported. ?So IMHO Client limitations are not a realistic concern for this attribute.
> 
> - Slide 5: There is no such thing as non-IPP attributes in a preset. ?They are all IPP attributes, and by definition the only member attribute in the collection that is not used by the Client as a Job Template attribute is the "preset-name" member attribute.
> 
> - Slide 6: Conforming client implementations MUST support all of the attribute syntaxes defined in RFC 8011, so this is not a realistic concern IMHO. ?We can make this explicit in the definition of job-presets-supported if you like, but it isn't explicitly necessary since the definition of the attribute says that the collection contains Job Template attributes to be copied to the job creation request.
> 
> 
> 
> Michael Sweet, Senior Printing System?Engineer
> 
> 

--------
Yuko Hosokawa <[email-masked]>
Office Imaging Products System Development Center
Canon Inc. 
621-46449 (Toride:Mon-Wed, Fri)  
612-85770 (Shimomaruko:Thu)
+81-3-3758-2111
--------

---

From: Takeshi KANEDA <[email-masked]>
Date: Thu, 26 Oct 2017 19:14:37 +0900

Thank you.