The PDF form of this paper was accidentally stored as a zero-length
file. I've just spoken to Tom and he's fixing it (reposting to
the PWG FTP server) right now, so it should be available shortly.
Cheers,
- Ira McDonald
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Wednesday, December 08, 1999 12:54 AM
To: ipp
Subject: IPP> NOT - 'ipp-get' Event Notification Delivery Method (method
3) pos ted
Carl-Uno and I have posted a complete spec (9-pages) for the 'ipp-get' Event
Notification Delivery Method (method 3). This is one of the "pull" delivery
methods:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-get-delivery-991207.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-get-delivery-991207.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-get' 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. The
Get-Notifications request indicates whether the client wants to receive all
future events Notifications for (1) any Subscription for which the client is
the owner or (2) a particular Subscription object. In either case, the
event Notifications are returned as MIME multi-part-related responses to the
Get-Notifications request. The HTTP channel is kept open, so that
subsequence event Notifications are returned using additional MIME
multi-part-related responses.
We'd like to introduce this at tomorrow's IPP telecon, 12/8/99, 1-3 EST
(10-12 PST) and review at the upcoming L.A. IPP WG meeting, 12/15-16/99.
Please send comments to the DL as well.
Thanks,
Tom and Carl-Uno