I've down loaded the files for the "Internet Printing Protocol (IPP): The
'ipp' Notification Polling Method", including the first I-D .txt file which
Carl-Uno will send to the IETF.
It is only 14 page long, so please read it. It is the most likely event
notification delivery method candidate to be the REQUIRED method for IPP
Notification. Therefore, it needs careful review by everyone (and
prototyping).
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-notify-poll-00.txtftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000308.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000308.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000308.txtftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000308-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000308-rev.pdf
Here is the 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'
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' delivery method, it holds each Event
Notification for a certain length of time. The amount of time is called the
"event-lease time".. A Printer may assign the same event-lease time to each
Event Notification or different times. If a Notification Recipient does not
want to miss Event Notifications, the time between consecutive pollings of
Subscription objects must be less than the event-lease time of the events
that occur between pollings. The Get-Notifications request indicates
whether the client wants to receive all pending event Notifications for (1)
any Subscription for which the client is the owner, (2) any Subscription
associated with a Job, (3) any Subscription with a particular
delivery-method URL, or (4) an identified set of Subscription objects. With
the Get-Notifications operation, the Printer returns all existing Event
Notifications along with two time intervals. One specifies the minimum time
at which event-leases of future events of the type returned will begin to
expire and the other specifies the recommended interval for the client to
wait before sending 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 Event Notifications.
Since the time interval between consecutive client requests is normally less
than the event-lease time, consecutive responses will normally contain some
Event Notifications that are identical. The youngest ones in the previous
response will become the oldest 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 Event Notification.
There are 6 issues:
ISSUE 1: The 'ipp' is a convenient reuse of 'ipp', but does it imply the
existence of a print service at each client that is not a reality?
Issue 2: Now that the Get-Notification operation does not affect the Event
Notifications in the Printer, it should not require write access to access
them.
Issue 3: Is it possible for this operation to have an option that causes it
to delay completing its response? It would initially returns all existing
Event Notifications. Then it would return additional notifications as they
occur for some period of time. The client would receive these Event
Notifications as they occur. The question is whether http servers or
proxies would behave in this manner so that the client would get the Event
Notifications without delay after they are sent by the http server? It has
been suggested that the Printer send each burst of Event Notifications be in
a separate message body where each message body is part of a multipart MIME
content-type.
ISSUE 4: The "notification-recipient" option allows a client to group
multiple Subscription-ids with a single URL. A client might decide to use
the same URL for all subscriptions for a user, or it might have a separate
URL for each client program. In addition a client might use an URL
belonging to some other known user and let that user access Event
Notifications using that URL. Is the above option useful?
ISSUE 5: Does the mechanism described in the above paragraph describe a
useful option that "notification-recipient" alone cannot do? Should this
case be an error instead?
ISSUE 6: Is it better if "notification-recipient" is the only way to request
Event Notification? If so, this behaves more like other notification
delivery methods where a recipient receives those and only those events with
its delivery URL. Furthermore, if there is a single mechanism of
"notification-recipient" for a client to specify Event Notifications, a
Printer can better optimize event-leases because it knows which events will
be accessed together. If client can specify subscription-ids, each request
can contain a different mix of subscription-ids.
Please send comments to the mailing list. We're going to forward ISSUE 03
to the HTTP WG mailing list now and hope to engages them in Australia.
Tom and Bob
P.S. the .doc file has been updated some with some editorial fixes since Bob
posted it below:
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
Sent: Wednesday, March 08, 2000 23:33
To: ipp at pwg.org
Subject: IPP>NOT latest notify poll document
The latest document has updates based on feedback at the Wednesday
teleconference. It also has 6 issues, some new.
The URL is
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000308-rev.doc
Bob Herriot