Smith,
> On May 21, 2021, at 10:12 AM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>> 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.
Can you file an issue for this? I'm happy to add comments here so things are clear.
> I'm also confused why is there the SKIP-IF-NOT-DEFINED PRINT_JOB_COMPLETED?
If the job is completed then it won't be returned by the Get-Jobs request since the default is to return not-completed jobs... This was added to prevent a false-failure.
Alternately I could have added IF-NOT-DEFINED to each of the job-id/job-uri and added "EXPECT !job-xxx IF-DEFINED ..." lines to make sure that the printer returns nothing if the job is already completed. (and that might actually be better to ensure proper conformance)
> 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...)
Can you add that to the ippsample Wiki page for IPP Everywhere 2.0? Thanks!
________________________
Michael Sweet