I've updated the "IPP Event Notification Specification" document, fixing all
but one remaining issue based on the recent telecon and mailing list
discussion. Its ready for Carl-Uno to send as Internet-Draft 02.
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-spec-02.txtftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000308.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000308.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000308.txtftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000308-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000308-rev.pdf
Here is the Abstract:
This document describes an extension to the IPP/1.0, IPP/1.1, and future
versions that allows a client to subscribe to printing related events.
Subscriptions include "Per-Job subscriptions" and "Per-Printer
subscriptions". One or more Per-Job Submission subscriptions are specified
by the client when submitting a job. Additional Per-Job and Per-Printer
subscriptions are created by performing separate explicit
Create-Job-Subscription Create-Printer-Subscription operations,
respectively. Subscriptions are modeled as Subscription objects. Four
other operations are defined for Subscription objects: Get-Attributes,
Get-Subscriptions, Renew-Subscription, and Cancel-Subscription.
A subscription request and the Subscription object includes: the names of
Job and/or Printer events, the Notification Recipient URL, the Notification
Content format, if several are supported, possibly some opaque data, and the
charset and natural language. In addition, the subscription request
includes: the requested lease time and persistency for the subscription.
When the event occurs, a notification is generated and delivered using the
information specified in the subscription.
1 ISSUE is included in the text.
Here is the change history:
1.1 Changes to the March 6, 2000 version to create the March 8, 2000
version
The following changes were made to the March 6, 2000 version to create the
March 8, 2000 version based on the agreements reached on the mailing list:
1. Changed the name of the SNMP delivery method from 'snmp' to
'snmpnotify', since the Notification Recipient isn't an SNMP agent.
2. Clarified that an implementation with only a single value for
persistent-jobs-supported (boolean) or persistent-subscriptions-supported
(boolean) MAY make it settable to the single value or make it not-settable.
Here is the remaining issue:
The following notification delivery schemes are defined in other documents
for use as part of the URI value of this attribute:
'ipp:' - The Notification Recipient uses server directed polling to
pull Notifications [ipp-method-poll]
'indp:' - The Notification Source sends Send-Notifications
operations to the Notification Recipient [ipp-method-indp]
'mailto:' - The Notification Source sends a email message using SMTP
with possible attachments containing Machine Consumable Notification Content
[ipp-method-mailto]
'snmpnotify:' - The Notification Source sends SNMP traps and/or
informs to the Notification Recipient [ipp-method-snmp]
This list of notification delivery schemes will be added to as needed using
the registration procedures defined in [ipp-mod].
ISSUE 01 - Once a number of delivery solutions have been developed and
evaluated, we may want to make one or several of them REQUIRED for
implementation to ensure a minimum set of interoperability. Which one or
ones should be REQUIRED?