Subject: [IPP] Question about PWG 5100.7 and "document-format-details"

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 17 Mar 2016 21:00:24 +0000

Hello,

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?

Smith

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

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

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Mar 2016 17:09:03 -0400

Smith,

> On Mar 17, 2016, at 5:00 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Hello,
> 

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

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 17 Mar 2016 21:19:38 +0000

Would rejecting the operation with "client-error-conflicting-attributes" be an appropriate response?

Smith

On 2016-03-17, at 3:09 PM, Michael Sweet <[email-masked]<mailto:[email-masked]>> wrote:

Smith,

On Mar 17, 2016, at 5:00 PM, Kennedy, Smith (Wireless Architect) <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Mar 2016 17:28:54 -0400

Smith,

> On Mar 17, 2016, at 5:19 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 

Possibly, although that status code is usually reserved for Job Template attribute conflicts...

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 17 Mar 2016 22:11:44 +0000

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.  

Smith

> On 2016-03-17, at 3:28 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Mar 2016 18:54:49 -0400

Smith,

> On Mar 17, 2016, at 6:11 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 

RFC 2911 says the following about client-error-conflicting-attributes:

   13.1.4.15 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 3.2.1.2.

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...)