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 <ipp at pwg.org> 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
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210521/7956a5a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210521/7956a5a2/attachment.sig>