Subject: [IPP] The testability of "document-charset", as an IPP design discussion

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Thu, 22 Aug 2019 20:15:53 +0000

Hi there,

I'm reviewing some of the Linux Open Printing GSoC contributions, and one of them is a test suite for PWG 5100.7. In reviewing that, I came across how to test for the support of "document-charset". It seems awkward to me, and I wonder if there is an attribute design lesson here to be learned.

PWG 5100.7-2019 includes this:
5.5.1 document-charset-default (charset)

This CONDITIONALLY REQUIRED attribute specifies the default charset that the Printer will assume for charset-ambiguous Document formats when the Client omits the “document- charset” operation attribute [PWG5100.5]. Printers that support the "document-charset" operation attribute MUST support this attribute.

5.5.2 document-charset-supported (1setOf charset)

This CONDITIONALLY REQUIRED attribute lists the charsets that the Printer supports for charset-ambiguous Document formats. Printers that support the "document-charset" operation attribute [PWG5100.5] MUST support this attribute.

And PWG 5100.5 has this:

6.4.1 document-charset (charset)
This RECOMMENDED operation attribute specifies the character set used by the Document data.
This is kind of a chicken-and-egg problem from a normative language / testability point of view. If the former two are CONDITIONALLY REQUIRED depending on whether the Printer supports the latter, how does one determine whether the Printer supports it? (Of course it is kind of a bummer that these are spread across two specs...). It seems to me that the document-charset-default and document-charset-supported should be RECOMMENDED and the document-charset should be CONDITIONALLY REQUIRED depending on whether the document-charset-default and document-charset-supported attributes are supported.

The more general design pattern or principle would be to mandate that the definitions of the Printer Description attribute(s) indicating attribute feature support to be the "primary" normative indicators.

(All that said, I am not sure we want to twiddle the normative language in 5100.5 / 5100.7 to resolve this. But now might be an opportune time to do so.)

Smith

/**
    Smith Kennedy
    HP Inc.
*/

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

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 22 Aug 2019 16:57:51 -0400

Smith,

If the Printer supports the attribute, then the document-charset-default and document-charset-supported attributes will be present when you query using Get-Printer-Attributes.  I don't see how this is any different than something like "media" or "print-quality" - the Client queries the Printer capabilities and then only sends it attributes and values that are listed as supported.

More specifically, in the case of document-charset (and document-natural-language), it is important for the Client to supply the intended document-format value in order to get attributes and values that are applicable to it - this is already recommended behavior in the IIG...

Anyways, IIRC the reason that document-charset is just RECOMMENDED is that we didn't have the infrastructure in place (JOBEXT came after DOCUMENT).  And we don't require document-charset support in 5100.7 because it is rarely needed - most file formats used for printing explicitly define a character set *or* don't need one (images). And STD92 expects that you'll use the charset parameter for things like plain text files...

> On Aug 22, 2019, at 4:15 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked]> wrote:
> 
> Hi there,
> 

________________________
Michael Sweet