Bob Herriot and I have collaborated on synthesizing Harry's polling method
and Carl-Uno's polling method into a single polling delivery method. The
revision mark version shows the changes from Carl-Uno's Get-Notifications
polling method (which returned multiple responses over an extended period of
time using multi-part MIME). The 'ipp-notify-poll' method also uses the
Get-Notifications operation but returns recent events in a single response,
not future events. The Get-Notifications (and Job Creation) operations
return the min and max times to poll next, as in Harry's polling scheme.
We'd like to discuss this method at next week's meeting when we discuss our
various delivery methods. I've posted the files at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000202.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000202.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000202-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000202-rev.pdf
Here is the abstract:
Abstract
The IPP notification specification [ipp-ntfy] is an OPTIONAL extension to
IPP/1.0 and IPP/1.1 that requires the definition of one or more delivery
methods for dispatching event notification reports to Notification
Recipients. This document describes the semantics and syntax of the
'ipp-notify-poll' event notification delivery method. For this delivery
method, the client uses an explicit IPP Get-Notifications Printer operation
in order to request (pull) event Notifications from the IPP Printer.
When a Printer supports the 'ipp-notify-poll' delivery method, it queues
Notification events for a sliding window of time for each Subscription
object. Notification Recipients poll these Subscription objects at the rate
specified by the time window. The Get-Notifications request indicates
whether the client wants to receive all pending events Notifications for (1)
any Subscription for which the client is the owner or (2) a particular
Subscription object. The Get-Notifications operation retrieves all pending
Notifications that occurred for an interval of time in the past for the
requested Subscription objects. The Printer returns all pending
Notifications along with two time intervals that specify the next time
window: one is the minimum interval that the client should wait before
performing another Get-Notifications on the subscription-id and the other is
the maximum interval that the Printer is guaranteed to keep any new
Notifications associated with the subscription-id.
The Printer may keep the channel open if the minimum interval is
sufficiently short, but in any case the client performs a new
Get-Notifications operation each time it wants more Notifications. Since
the client will be making Get-Notification requests before the time window
expires, the Printer will, on occasion, return the same event Notification
in two successive responses. The later ones in the previous response will
become the earliest in the next response. The client is expected to filter
out these duplicates which is easy to do because of the sequence number in
each Notification.
There are 4 issues:
ISSUE 01: Should it be possible for a client to ask for the Per-Job
Subscriptions for a particular job using a "job-id", instead of the
subscription-id, which currently isn't returned by a Job Creation operation?
ISSUE 02: Is there anything useful that we could define for the rest of the
"notification-recipient" (uri) attribute, since there is no recipient
address needed after the 'ipp-notify-poll://' since the recipient(s) poll?
ISSUE 04 - Or MUST the Printer discard events that occurred earlier than the
sliding time window specified by the difference between these two values?
Otherwise, the clients may get back a lot of duplicate events on subsequent
requests.
ISSUE 05: if we don't want to have Job Creation operations return
subscription id's, then allow a "job-ids" operation attribute in the
Get-Notifications request in addition to the "subscription-ids" operation
attribute.