Re: IPP WG Last Call: IPP Everywhere v1.1 Printer Self-Certification Tools Update 3

"Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email protected]> Fri, 21 May 2021 14:12:01 +0000
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
Hi Mike,

We have observed an issue with I-13 / I-13.x. I-13 is this:

# Test Get-Jobs operation
#
# Required by: RFC 8011 section 4.2.6
{
	SKIP-IF-DEFINED PRINT_JOB_COMPLETED

	NAME "I-13. Get-Jobs Operation (default)"
	OPERATION Get-Jobs
	GROUP operation-attributes-tag
	ATTR charset attributes-charset utf-8
	ATTR naturalLanguage attributes-natural-language en
	ATTR uri printer-uri $uri
	ATTR name requesting-user-name $user

	STATUS successful-ok

	EXPECT ?job-id OF-TYPE integer IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE >0
	EXPECT ?job-uri OF-TYPE uri IN-GROUP job-attributes-tag COUNT 1 WITH-VALUE "$IPP_URI_SCHEME"
	EXPECT !job-name
	EXPECT !job-state
}

I didn't understand why the last two EXPECT lines are negative, and found my answer in RFC 8011 section 4.2.6.1 at the bottom of page 65:

      "requested-attributes" (1setOf type2 keyword):

         The Client MAY supply and the Printer MUST support this
         attribute.  It is a set of Job attribute names and/or attribute
         group names in whose values the requester is interested.  This
         set of attributes is returned for each Job that is returned.
         The allowed attribute group names are the same as those defined
         in the Get-Job-Attributes operation in Section 4.3.4.  If the
         Client does not supply this attribute, the Printer MUST respond
         as if the Client had supplied this attribute with two values:
         "job-uri" and "job-id".

We might want to annotate the tests to more clearly refer the tester to these details, which can be obscure.

I'm also confused why is there the SKIP-IF-NOT-DEFINED PRINT_JOB_COMPLETED? If there is concern about the Job moving to a terminal state too quickly, would it not make more sense to send "job-state = 4" in I-12, do I-13 / I-13.1 / I-13.2, then do a Set-Job-Attributes in I-14 to set its state to 3 (pending), and have the existing I-14 be renumbered to I-14.1? That would ensure the Get-Jobs was tested. Unfortunately, this refactoring would conflict with the test list in 5100.20, which is unfortunate. (We might want to change 5100.20 for IPP Everywhere™ 2.0 to allow the tests to be implemented more flexibly...)

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On May 17, 2021, at 3:59 PM, Michael Sweet via ipp <[email protected]> wrote:
> 
> Signed PGP part
> [This last call starts today, May 17, 2021 and ends no earlier than May 31, 2021]
> 
> All,
> 
> I have posted a beta of the IPP Everywhere v1.1 Printer Self-Certification Tools Update 3 to:
> 
> 	https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert11-20210517-macos.zip
> 	https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert11-20210517-rhel.tar.gz
> 	https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert11-20210517-ubuntu.tar.gz
> 	https://ftp.pwg.org/pub/pwg/ipp/wd/sw-ippeveselfcert11-20210517-windows.msi
> 
> This update fixes the following issues:
> 
> - The DNS-SD tests now look for a TLS key whose value contains a TLS version
>  number (Issue #64)
> - The document tests now wait for each job to complete before proceeding to the
>  next job (Issue #66)
> - Finishing options were not reported correctly by `ippevesubmit` in the JSON
>  file (Issue #67)
> - The `media-needed` test did not work on streaming printers (Issue #68)
> 
> Please respond to this message once you have tested this update, along with any issues you have encountered.
> 
> ________________________
> Michael Sweet
> 
> 
> 
> 
>

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)