I've updated the Notification specification from the agreements reached at
the October and December IPP WG meetings and as reflected in the published
minutes of those meetings. This spec will be on the agenda for the Feb 9-10
IPP WG meeting. This spec is very stable now. While there are still 6
issues, they are all trivial, except for the first one: which delivery
methods are REQUIRED? If you haven't reviewed this spec recently, this
would be a good time. The remaining work is on the separate notification
delivery method papers.
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000202.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000202.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000202-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000202-rev.pdf
Here is the Abstract:
Abstract
This document describes an extension to the IPP/1.0 & IPP/1.1 model 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 text format
if Human Consumable notification is requested, 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.
Changes to the October 14, 1999 version to create the February 2, 2000
version
The following changes were made to the October 14, 1999 version to create
the February 2, 2000 version based on the agreements reached at the October
and December IPP WG meetings and reflected in the minutes:
1. Added a Java Listener as an example of a Notification Recipient.
2. Clarified the object relationships in section 4.1.
3. Clarified how job events differ for Per-Job versus Per-Printer
Subscriptions.
4. Added the ability for the Machine Consumable form to contain a Human
Readable "human-readable-report" (text) attribute so that both forms could
be sent in the same Notification.
5. Clarified that the 'none' value for notify-text-format
(mimeMediaType) has to be out-of-band, not the text string 'none' as a
mimeMediaType.
6. Clarified that 'none' means send the Machine Consumable form without
the "human-readable-report" (text) attribute, if it is defined.
7. Clarified that Notification Recipients MUST be able to accept
unrecognized attributes.
8. Allowed the notification delivery method definition to be modeled as
(1) a request with an operation code without a response, (2) a request with
a operation code with a response or (3) a response with a status code.
9. Added "notify-text-format" (mimeMediaType) and
"human-readable-report" (text(MAX)) to be able to be sent in a Notification
content, if the notification delivery method document permits it.
10. Added "job-k-octets" (integer(0:MAX)), "job-impressions"
(integer(0:MAX)), and "job-media-sheets" (integer(0:MAX)) as OPTIONAL for
Notification content for use in job-progress events to show the target
values so that the Notification Recipient can show a thermometer.
11. Added a Subscription Attributes group (and subscription-attributes
tag) the Create-Job-Subscription and Create-Printer-Subscription requests
and responses.
12. Added the 'none' out-of-band value for use with "notify-text-format"
(mimeMediaType) attribute.
13. Changed the job progress attributes from using -2 to mean 'unknown' as
in the PWG Job Monitoring MIB, to use the 'unknown' out-of-band value.
The following issues remain (all but the first one are trivial):
ISSUE 1 - 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?
ISSUE 02 - Ok that "job-uri" isn't defined for use with the
Create-Job-Subscription operation?
ISSUE 03 - Should Renew-Subscription Request have a Group 2 for its two
Subscription attributes?
ISSUE 04 - Should Renew-Subscription Response have a Group 3 for its two
Subscription attributes?
ISSUE 05 - The out-of-band 'none' value is also defined in the PWG
Production Printing document. Should we keep the definition here in the
Notification document? And/or should we move the definition to the
'collection' specification (ipp-coll) which is also defining the tag for the
'collection' attribute syntax that is the province of the IPP Transport and
Encoding document?
ISSUE 06 - Should we add references to the notification delivery documents
that are in progress?