At the 8/9/01 IPPGET telecon, we came to the conclusion that the Printer
cannot return a "notify-get-interval" operation attribute time value that
exceeds the Printer's "ippget-event-life" configured value. Otherwise, an
unforeseen event could occur and the Notification Recipient would poll with
the Get-Notifications request too late and miss the event.
Here is a proposal that I ran by Ira, and we think it holds up. It would
allow the Printer to return a larger value for the time to poll next than
the Printer's "ippget-event-life" configured value. The idea is to add the
Event Life Time to each Subscription object so that the Printer can set it
higher than the Printer's "ippget-event-life" configured value on a
Subscription Object basis depending on which events and job that
Subscription Object is waiting for.
Here is the list of changes:
1. Rename the Printer's "ippget-event-life" (integer(15:MAX)) to
"notify-event-life" to be parallel (and possibly used in the future with
some other Delivery Method).
2. Add "notify-event-life" (integer(15:MAX)) Subscription Description
attribute to the Subscription Object for use with IPPGET Delivery method
(and possibly used in the future with some other Delivery Method).
3. By default, the Printer MUST set the Subscription object's
"notify-event-life" attribute from the configured value of the Printer's
notify-event-life" attribute. However, at any time the Printer MAY set the
Subscription object's "notify-event-life" to a higher value, if it suspects
that the events that the Subscription object are waiting for are unlikely to
happen soon. Once set to a higher value, the Printer can never set it lower
in the Subscription object, though the Printer can raise it more
subsequently.
4. The Printer MUST return Event Notifications until the Subscription
object's "notify-event-life" expires for each Event. So if the Printer has
increased the Subscription object's "notify-event-life", then the Printer is
promising to return Event Notifications for Events for that Subscription
object for that longer life time.
5. As suggested by Marty, instead of returning the "notify-event-life" as an
operation attribute, return an "event-wait" (boolean) operation attribute to
the Get-Notification (and Job Creation) Response, which indicates whether or
not the Printer is continuing Event Wait Mode. This would mirror the
"event-wait" (boolean) operation attribute that the client supplies in the
Get-Notifications (and Job Creation) request. If the client supplies
'false' (or omits), the Printer responds with 'false' (or omits). If the
client supplies 'true', the Printer responds with 'true' or 'false',
depending on whether it is continuing Event Wait Mode or not, respectively.
6. For Get-Notifications response, it might be simpler for the Printer to
always return each Subscription object's current "notify-event-life" value
in each Event Notification Attributes Group, rather than making it
conditional on whether or not the Printer is discontinuing Event Wait Mode.
The client then tries the Get-Notifications for the shortest value returned
and can regroup, if the values returned were different.
7. For Job Creation responses, the Subscription Attribute Group(s) are
returned, so the Printer includes the Subscription object's current
"notify-event-life" in each group.
Comments?
Here is the ISSUE 11 and notes from the telecon:
ISSUE 11: Should the Printer return a "end-wait" (boolean) attribute,
rather than a "notify-get-interval" (integer) with the number of seconds to
try again later?
<MJ> Regarding the whole try-again time issue, I don't think the Receiver
should be sending that, and should indicate the desire to stop or not
start wait mode with a boolean or a status code. The Sender can do a
Get-Printer-Attributes to learn how long events are retained. The
Sender knows by when it must issue another Get-Notifications to avoid
the risk of losing events. If it isn't in keep-alive mode, the Sender
must take into account how long it might take to connect, so the
returning of the number of seconds to wait before trying again is
misleading.
<TH> Or we could clarify the "notify-get-interval" attribute that the
Printer is returning to be the value of the Printer's
"ippget-event-life" Printer Description attribute and the client needs to
take into the account the time to make the connection.
AGREED> That the "notify-get-interval" operation attribute returned in the
response MUST be at least as long as the value of the "ippget-event-life"
Printer Description attribute.
NOT AGREED> However, if the value is greater than the Printer's
"ippget-event-life" value, then a Notification Recipient could miss an event
if it didn't poll at the "ippget-event-life" rate. What to do?
We are still debating whether it is possible for the Printer to return a
time to next poll that is ever larger than the Event Life time? If the
Printer ever returns a larger value, the client could miss an event, unless
the Printer magically increases its Life for that (those) Subscription
object(s).
So is returning a boolean the best the Printer can ever do?