[cups-devel] Queries related to Ipptool testfile, ippserver, Event notifications and subscriptions

[Lakshay Bandlish]

Hello everyone,

I have been working on https://github.com/istopwg/ippsample/issues/113 and
https://github.com/istopwg/ippsample/issues/114 (RFC 3995: IPP Event
Notifications and Subscriptions and RFC 3996: The 'ippget' Delivery Method
for Event Notifications), regarding which I have the following doubts:

1. There are 2 modes of Event notification delivery in ipp - *push delivery
method* and *pull delivery method*. In the pull delivery method, the client
requests the printer to send a notification if there is a change in the
status of concerned printers/jobs, and the printer sends the notification
in the form of a response to this request. In the push delivery method, the
client provides the printer with a notify-recipient-uri while creating the
subscription, so that the printer can send the notification to this
uri whenever
any event occurs. The uri must follow a format which is specified by
the notify-schemes-supported printer-description attribute. Here are my
doubts regarding this topic:

a. Ippserver by-default does not provide the notify-schemes-supported
printer-description attribute in response to the get-printer-attributes
request. This has led me to believe that ippserver does not have native
support for push delivery method. Therefore I tried to include support for
this. I used ipptool's --ippserver flag to generate the attributes file for
the ippserver. Then I added the line - *ATTR uriScheme
notify-schemes-supported "ftp", "http" *to the attribute file. On running
ippserver using -a flag (using this edited attribute file for ippserver), I
sent get-printer-attributes request again. This time, it included the
notify-schemes-supported in the response. But I still wasn't able to figure
out how to create a printer subscription using push delivery method. I tried
 http://127.0.0.1 as the notify-recipient-uri for the
create-printer-subscription.test file, and sent it to the printer using
ipptool, but the response had a status -
client-error-ignored-all-subscriptions. So I have 2 doubts here -
1. What to supply as the notify-recipient-uri?
2. Is adding a line that I mentioned in the attribute file enough for
adding functionality for event notification using push delivery method?

b. I tried exploring the notify-wait attribute for the pull delivery
method. With its value as false, there is no issue. But I wasn't able to
understand the behaviour when I set its value to true. I created a
printer-subscription object using the create-printer-subscription.test
file. Then I gave a get-notifications request. I didn't receive any
response. Then I requested disable-printer.test. I received 2 responses.
First, for the disable request, and second, for the initial
get-notifications request. I requested to enable the printer. I received a
response only for the enable request, and no new response for the initial
get-notifications request. On all further state changes of the printer, I
didn't receive any new responses to the initial get-notifications request.
I disabled the printer and re-created the subscription object. Then I
enabled the printer. Then, I ran the get-notifications request, and I
received an immediate response for it. On making further printer
state-changes, I received no new responses to the initial get-notifications
request. Here is my doubt regarding this-
   My interpretation of what I read in RFC 3996 regarding notify-wait
attribute is that when the notify-wait attribute is set to true, the
printer would respond to the request immediately if there have been any new
changes, and continue to send more responses as and when related events
occur, to the same request for some time. What happened in my case was that
there was only a single response to a single get-notifications request. If
there was some change(s) in printer-state before the get-notifications
request was passed, there was an immediate response highlighting the
change(s). But if there wasn't any change until then, a response arrived
immediately when the first state change was made. I am not able to
understand this. Is this acceptable? and how to alter this behaviour?


2. What is the use of EXPECT feature in an ipptool testfile? Using EXPECT
hasn't led to any alteration in responses from ippserver printers. Only
when using the -t flag with ipptool, a statement - "EXPECTED: __ GOT:__" is
added at the end when the expected attribute is not found. Is only this the
purpose of EXPECT and its predicates?


Thanks,
Lakshay Bandlish.