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: ipp at pwg.org; HOSODA Osamu
Subject: Re: [IPP] [!!]Re: PWG: Canon proposal to extend the IPP Presetdraftspecification
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 <msweet at apple.com> wrote:
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 <kaneda.takeshi at canon.co.jp> wrote:
Hello, Mr. Smith Kennedy.
Hello, Mr. Michael Sweet.
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".
If you have any questions, please reply this mail. (Even if you contact Rick, it is OK.)
Thank you.
--
Takeshi KANEDA <kaneda.takeshi at canon.co.jp>
<IPP_Preset_improvement_proposal_20171025.pdf>
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
_______________________________________________
ipp mailing list
ipp at pwg.orghttps://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20171026/853b2fa0/attachment.html>