Re: [IPP] Posted 1.1 release candidate tools

Michael Sweet via ipp <> Mon, 18 May 2020 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DE8E3A0B80 for <>; Mon, 18 May 2020 06:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PDueCCM9wNRn for <>; Mon, 18 May 2020 06:04:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 96AA53A0B6F for <>; Mon, 18 May 2020 06:04:21 -0700 (PDT)
Received: by (Postfix, from userid 1002) id 9FEA08B39; Mon, 18 May 2020 13:04:19 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 832903A80; Mon, 18 May 2020 13:04:16 +0000 (UTC)
Received: by (Postfix, from userid 1002) id 320D87FC; Mon, 18 May 2020 13:04:15 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id B4FFB7FC; Mon, 18 May 2020 13:04:14 +0000 (UTC)
Received: from mbp16.lan ( []) by (Postfix) with ESMTPSA id 0658A808B8; Mon, 18 May 2020 13:04:13 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
In-Reply-To: <>
Date: Mon, 18 May 2020 09:04:12 -0400
Message-Id: <>
References: <> <>
To: Smith Kennedy <>
X-Mailer: Apple Mail (2.3608.
Cc: PWG IPP Workgroup <>, PWG IPP Everywhere Self-Certification Reflector <>
Subject: Re: [IPP] Posted 1.1 release candidate tools
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ISTO-PWG Internet Printing Protocol workgroup discussion forum <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
From: Michael Sweet via ipp <>
Reply-To: Michael Sweet <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: "ipp" <>


Go ahead and file Github issues for the first two issues and I'll get them fixed.

The last two issues probably need a little discussion (see below)

> On May 16, 2020, at 7:07 PM, Kennedy, Smith (Wireless & IPP Standards) <> wrote:
> Hi Mike,
> Just now getting time to test these tools with a printer that is already IPP Everywhereâ„¢ 1.0 certified, and I'm observing some interesting deltas / issues.
> 1. The printer is failing test I-10:
>     I-10. Get-Printer-Attributes Operation (default)                     [FAIL]
>         RECEIVED: 13004 bytes in response
>         status-code = successful-ok (successful-ok)
>         EXPECTED: finishing-template-supported
>         EXPECTED: finishing-template-supported
>         EXPECTED: finishings-col-database OF-TYPE collection (got no-value)
>         EXPECTED: finishings-col-database/finishing-template OF-TYPE keyword|name (got no-value)
>         EXPECTED: finishings-col-default OF-TYPE collection (got no-value)
>         EXPECTED: finishings-col-default/finishing-template OF-TYPE keyword|name (got no-value)
>         EXPECTED: finishings-col-ready OF-TYPE collection (got no-value)
>         EXPECTED: finishings-col-ready/finishing-template OF-TYPE keyword|name (got no-value)
> Here's a dump of the Printer's attributes relating to finishing:
> Serenity: ipptool-server-captures [503]$ grep finishing _Kennedy\ DeskJet\ 3755_.conf 
> ATTR keyword job-creation-attributes-supported "copies","finishings","finishings-col","job-pages-per-set","sides","orientation-requested","media","print-quality","printer-resolution","output-bin","media-col","output-mode","print-content-optimize","pclm-source-resolution","print-color-mode","ipp-attribute-fidelity","job-name","page-ranges","multiple-document-handling","job-mandatory-attributes","print-rendering-intent","print-scaling"
> ATTR no-value finishings-col-database
> ATTR no-value finishings-col-ready
> ATTR keyword finishings-col-supported "finishing-template"
> ATTR enum finishings-default 3
> ATTR no-value finishings-col-default
> ATTR enum finishings-supported 3
> The problematic line in ipp-tests.test seems to be this:
> EXPECT finishings-supported OF-TYPE enum IN-GROUP printer-attributes-tag DEFINE-MATCH HAVE_FINISHINGS
> Since the Printer's "finishings-supported" contains only 3 (none), I think the line should instead be:
> EXPECT finishings-supported OF-TYPE enum IN-GROUP printer-attributes-tag WITH-VALUE >3 DEFINE-MATCH HAVE_FINISHINGS


> 2. The new "I-9" test for Identify-Printer never gets exercised because it has SKIP-IF-NOT-DEFINED HAVE_IDENTIFY_PRINTER at the start, but HAVE_IDENTIFY_PRINTER isn't defined until test I-10. I moved I-9 to after I-10.7 and renumbered so that I-10.7 is now I-9.7, I-9 is now I-10. Now it gets executed.

Better to define HAVE_IDENTIFY_PRINTER sooner, as a renumbering will require changes to the self-cert manual...

> 3. The current I-10.5 and I-10.6 are failing on my IPP Everywhere 1.0 certified printer. I'm wondering whether these tests ought to be enabled only if some DEFINE is defined ("PEDANTIC" / "WARNINGS" etc.). I know they should pass, but if that hasn't been exercised previously, that can cause some additional thrash. I don't want to lower the bar and remove those tests, but if there was some grace period, that might help teams who are trying to certify in the near term. I'm not sure what others think. Asking my firmware teams whether fixing that in pending devices' certifications will cause thrash.

These tests (for requested-attributes='printer-description' and ='job-template') were added because the non-conformance to STD92 was causing problems with getting full IPP Everywhere support working in CUPS.

I'd like to know what the failures were - too many attributes returned, too few?  Too many isn't a serious interoperability issue - might lead to some laziness on the Client side but testing will catch that - but too few prevents Clients from working which *is* a serious interoperability issue...

Michael Sweet

ipp mailing list