[IPP] [!]Re: PWG: Canon proposal to extend the IPPPresetdraftspecification

[IPP] [!]Re: PWG: Canon proposal to extend the IPPPresetdraftspecification

[IPP] [!]Re: PWG: Canon proposal to extend the IPPPresetdraftspecification

HOSOKAWA Yuko hosokawa.yuko at canon.co.jp
Thu Oct 26 23:51:47 UTC 2017


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
<wamwagner at comcast.net> wrote:

> 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.org
> https://www.pwg.org/mailman/listinfo/ipp
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System?Engineer
> 
> 

--------
Yuko Hosokawa <hosokawa.yuko at canon.co.jp>
Office Imaging Products System Development Center
Canon Inc. 
621-46449 (Toride:Mon-Wed, Fri)  
612-85770 (Shimomaruko:Thu)
+81-3-3758-2111
--------



More information about the ipp mailing list