I think that the time window should be able to be different for different
Subscription objects, depending on the events that are wanted.
Not a fixed time for all events for the Printer.
Introduction
IPP printers that support the OPTIONAL IPP notification extension [ipp-ntfy]
either a) accept, store, and use notification subscriptions to generate
event Notification reports and implement one or more delivery methods for
notifying interested parties, or b) support a subset of these tasks and farm
out the remaining tasks to a Notification Delivery Service. The 'ipp' event
notification delivery method specified in this document defines a
Get-Notifications operation that may be used in a variety of notification
scenarios. Its primary intended use is for clients that want to be
Notification Recipients. However, the Get-Notifications operation may also
be used by Notification Delivery Services for subsequent distribution to the
Ultimate Notification Recipients.
When a Printer supports the 'ipp' delivery method, it holds each
Notification event for a certain length of time \. The amount of time is
called the "lease time" and it is the same for all events in a Printer. If
a Notification Recipient does not want to miss events, the time between
consecutive pollings of Subscription objects must be less than the lease
time. 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, (2) any Subscription associated with a particular
Job or (3) a particular Subscription object. With the Get-Notifications
operation, the Printer returns all existing Notifications along with two
time intervals. One specifies the length of the lease for all future events
and the other specifies the recommended interval to wait to the next
Get-Notifications operation. The second time interval is less than the
first..
The Printer may keep the channel open if the recommended interval is
sufficiently short, but in any case the client performs a new
Get-Notifications operation each time it wants more Notifications. Since the
time interval between consecutive client requests is normally less than the
lease time, consecutive responses will normally contain some events that are
identical. 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. The reason for not removing the Notifications from the
Subscription object with every Get-Notifications request, is so that
multiple Notification Recipients can be polling the same subscription object
and so the Get-Notification operation satisfies the rule of idempotency.
The former is useful if someone is logged in to several desktops at the same
time and wants to see the same events at both places. The latter is useful
if the network loses the response.
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
Sent: Tuesday, March 07, 2000 19:47
To: ipp at pwg.org
Subject: IPP>NOT lastest notify-poll document
I just downloaded the latest notify-poll document.
It is
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000306-rev.doc
We may discuss the issues at the IPP teleconference tomorrow.
Bob Herriot