> On Mar 17, 2016, at 6:11 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>> Wouldn't this be an instance of that? I am guessing you have in mind more something like a late notice of a constraints conflict like "sides" = 'two-sided-long-edge' and "media-type" = 'transparency', but this seems like a similar condition - two attributes that have conflicting values.
RFC 2911 says the following about client-error-conflicting-attributes:
18.104.22.168 client-error-conflicting-attributes (0x040E)
The request is rejected because some attribute values conflicted with
the values of other attributes which this document does not permit to
be substituted or ignored. The Printer object MUST also return in
the Unsupported Attributes Group the conflicting attributes supplied
by the client. See sections 3.1.7 and 22.214.171.124.
Given that PWG 5100.7 does not say anything about conflicting values or substitution, I'm not sure client-error-conflicting-attributes makes sense.
(seems like we should file an issue for this so we can track an eventual errata update for 5100.7, which needs a fair amount of work...)
>>>>> On 2016-03-17, at 3:28 PM, Michael Sweet <msweet at apple.com> wrote:
>>>>> On Mar 17, 2016, at 5:19 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>>>>> Would rejecting the operation with "client-error-conflicting-attributes" be an appropriate response?
>>>> Possibly, although that status code is usually reserved for Job Template attribute conflicts...
>>>>>>>>>>>> On 2016-03-17, at 3:09 PM, Michael Sweet <msweet at apple.com<mailto:msweet at apple.com>> wrote:
>>>>>> On Mar 17, 2016, at 5:00 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com<mailto:smith.kennedy at hp.com>> wrote:
>>>>>> PWG 5100.7 defined the "document-format-details" attribute, and one of its children is "document-format". There is also a "document-format" attribute, which is essential to the proper operation of IPP in general (filtering printer description attributes and so forth). But the definition of "document-format-details" is ambiguous in situations where "document-format" is not a "packaging" format.
>>>>>> If "document-format" is not a packaging format, but is rather a conventional format such as "application/pdf" or "image/pwg-raster", and "document-format-details" is provided by the Client, but the "document-format" child of "document-format-details" doesn't match "document-format", what should the Printer do?
>>>>>> Given the lack of firm conformance requirements, the Printer is free to return client-error-attributes-or-values-not-supported or successful-ok-ignored-or-substituted-attributes, or to ignore the value completely and just return successful-ok. (any of those is allowed by 2911)
>>> Michael Sweet, Senior Printing System Engineer
>> Michael Sweet, Senior Printing System Engineer
Michael Sweet, Senior Printing System Engineer