INTERNET-DRAFT
<draft-ietf-ipp-not-change-history-00.txt>
S. Isaacson
Novell, Inc.
J. Martin
Underscore
R. deBry
Utah Valley State College
T. Hastings
Xerox Corporation
M. Shepherd
Xerox Corporation
R. Bergman
Dataproducts Corp.
August 22, 1999
Internet Printing Protocol/1.1: IPP Event Notification Change
History
Copyright (C) The Internet Society (1999). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html.
Abstract
This document contains the change history for the development of the IPP
Notification specification. The IPP Notification specification is an
extension to the IPP/1.0 & IPP/1.1 model that allows clients to
subscribe to printing related events. Subscriptions include "Per-Job
Submission subscriptions" and "Per-Printer subscriptions". Either
subscription may specify job and/or printer events. This specification
has been developed starting in the Fall of 1997.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 1]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [IPP-REQ]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [IPP-RAT]
Internet Printing Protocol/1.1: Model and Semantics [IPP-MOD]
Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
Internet Printing Protocol/1.0: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [IPP LPD]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that are
satisfied in IPP/1.0. Operator and administrator requirements are out
of scope for version 1.0. A few OPTIONAL operator operations have been
added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol" document describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of IPP
specifications, and gives background and rationale for the IETF working
group's major decisions.
The "Internet Printing Protocol/1.1: Model and Semantics", describes a
simplified model with abstract objects, their attributes, and their
operations that are independent of encoding and transport. It introduces
a Printer and a Job object. The Job object optionally supports multiple
documents per Job. It also addresses security, internationalization, and
directory issues.
The "Internet Printing Protocol/1.1: Encoding and Transport" document is
a formal mapping of the abstract operations and attributes defined in
the model document onto HTTP/1.1. It defines the encoding rules for a
new Internet MIME media type called "application/ipp". This document
also defines the rules for transporting over HTTP a message body whose
Content-Type is "application/ipp". This document defines a new scheme
named 'ipp' for identifying IPP printers and jobs. Finally, this
document defines interoperability rules for supporting IPP/1.0 clients.
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives
insight and advice to implementers of IPP clients and IPP objects. It
is intended to help them understand IPP/1.0 and some of the
considerations that may assist them in the design of their client and/or
IPP object implementations. For example, a typical order of processing
requests is given, including error checking. Motivation for some of the
specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 2]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
Table of contents
1 Changed made to the August 17, 1999 version to make the August 22,
1999 version........................................................4
2 Changes made to the August 11, 1999 version to make the August 17,
1999 version:.......................................................5
3 Changes made from August 8, 1999 version to make the August 11, 1999
version.............................................................7
4 Changes to the August 2, 1999 version to make the August 7, version
10
5 Changes to the July 22, 1999 version to make the August 2, 1999
version............................................................10
6 Changes to the July 21, 1999 to make the July 22, 1999 (T Hastings)
10
7 Changes to the July 20, 1999 to make the July 21, 1999 (T Hastings)
10
8 Changes to the May 18, 1999 to make the July 20, 1999 (M Shepherd)11
9 Changes to the May 17, 1999 to make the May 18, 1999 (T Hastings, R
Bergman)...........................................................12
10 Changes to the January 20, 1999 to make the May 17, 1999 version (M
Shepherd)..........................................................13
11 Changes to the January 18, 1999 to make the January 20, 1999 version
14
12 Changes to the December 10, 1998 to make the January 18, 1999 version
15
13 Changes to the July 1, 1998 to make the December 10, 1998 version16
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 3]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
IPP Notification Specification Change History
The change history is maintained in reverse chronological order. Brief
explanations for each change is often included.
1 Changed made to the August 17, 1999 version to make the August 22,
1999 version
1.Integrated the Attribute Summary and New Model documents into
the Specification. Separated the Change History into this
document. Put the attribute summary as an Appendix. Put each
Notification Method description into a separate (short)
document.
2.Added "notify-content-type" (mimeMediaType) so that the client
can specify whether human consumable versus machine consumable.
3.Added "notify-content-type-supported" (1setOf collection)
Printer Description attribute to represent which notification
format types are supported for each supported delivery scheme.
4.Made Per-Printer Subscriptions and the Subscription object
REQUIRED if notification is supported. So both Per-Job and Per-
Printer subscriptions are REQUIRED. There is no longer any
CONDITIONALLY REQUIRED indication in our spec.
5.Added "notify-attributes-charset" to represent "attributes-
charset" in subscription requests and objects to distinguish it
from the request's "attributes-charset" attribute.
6.Added "notify-attributes-natural-language" to represent
"attributes-natural-language" in subscription requests and
objects to distinguish it from the request's "attributes-
natural-language" attribute.
7.Removed the concept of recording events, since there are no
longer any Job or Printer attributes that record the last event,
time, or date-time of the event. Only the Printer's "printer-
state-change-time" and "printer-state-change-date-time" remain
for recording events as the last Printer state change, so that
an application starting up can determine how long the device has
been in its current state.
8.Deleted notify-content-types-supported (1setOf collection).
Require all (1 or 2) content types that are defined for a method
to be supported, if the method is supported.
9.Added the 'server-error-too-many-events' status code.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 4]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
2 Changes made to the August 11, 1999 version to make the August 17,
1999 version:
1.Instead of the "notify-exclude-event-mask" (1setOf
octetString(8)) attribute, we agreed to use introduce the new
'collection' attribute syntax that we have been talking about
for over a year for use in the Job object to specify multiple
subscriptions in a Job creation operation. So the "notify"
operation attribute for Job creation operations will have the
attribute syntax: '1setOf collection'. The member attributes
of each collection value for Per-Job subscriptions are the same
as the attributes of a Subscription object instance for Per-
Printer subscriptions. For terminology a "subscription" is
either a collection value of the "notify" operation attribute in
a Job Creation operation or is a Subscription object.
2.Each subscription will contain only one multi-valued attribute:
"notify-events" (1setOf type2 keyword). The remaining
attributes will be single valued:
"notify-recipients" (uri)
"notify-user-info" (octetString(63))
"attributes-charset" (charset)
"attributes-natural-language" (naturalLanguage)
"request-id" (integer(0:MAX))
3.The client supplies an "attributes-natural-language" in a
subscription in order to get a different natural language than
for the request that creates the subscription. However, the
only time that the natural language has any bearing on the
Notification content, is when that content is the Human
Consumable form. The Machine Consumable form of the
Notification content will have no localization in it.
4.The minimum number of notification recipients that are required
to support is 1. Hence the minimum number of collection values
is 1 and the minimum number of Subscription objects is 1, if
Per-Printer subscriptions are supported at all.
5.Instead of inventing a special operation that sets the Job
attributes related to notification, we will define a single Set-
Job-Attributes operation for changing the values of any Job
attribute that is not defined to be READ-ONLY. We will not
define the corresponding Set-Printer-Attributes operation at
this time, but will lump that operation with the other System
Administration operations, since changing Printer attributes is
an administrative function. Changing Job attributes is an end-
user function for your own jobs, and an operator operation for
other's Jobs.
6.A Printer can grant a larger or smaller least to that requested,
including granting an infinite lease.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 5]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
7.Change "persistence (boolean)" operation attribute to
"persistence-requested (boolean)" in the Create-Printer-
Subscription. Keep it OPTIONAL to support. However, add a
REQUIRED "persistence-granted (boolean)" operation attribute
that MUST be returned in the response. While implementations
are RECOMMENDED to make all Subscriptions persistence, same as
for jobs, they MAY have a more limited number that are
persistent, including none.
8.Add two Printer Descriptions attributes: "persistent-job-
supported" (boolean) and "persistent-subscriptions-supported"
(boolean).
9.The Get-Printer-Subscriptions and Get-Printer-Subscription-
Attributes will return attributes Subscription attributes group,
so there will be a new Subscription attribute tag assigned in
the Encoding and Transport.
10. Changed the name of the "notify-lease-time" (integer(0:MAX))
in the Subscription object to "notify-least-expiration-time"
(integer(0:MAX)) since it is the time at which the lease
expires.
11. Eliminated storing the trigger-event, trigger-time, and
trigger-date-time in the subscription and passed them only in
the Notification content.
12. Add "printer-state-change-time" (integer(MIN:MAX)) and
"printer-state-change-date-time" (dateTime) Printer Description
attributes to record the time that the Printer last changed
state. Then an application that come up after that can tell
when the printer got into its current state by querying the
Printer when the application starts up. Lesson from the Printer
MIB alert table.
13. Defined the "subscription-id" attribute for use with Per-Job
subscriptions as being the index of the 1setOf collection,
starting at '1'. Then a Notification Recipient can have a
unique identification for each subscription whether it be Per-
Job or Per-Printer, for use in catching duplicate or skipped
notifications using the "request-id".
14. Deleted the "delivery-failure-count" (integer(0:MAX)) from the
Subscription object as not necessary.
15. Transports that have limited space, like SNMP, can truncate
the "job-name" to less than 255 octets, in order to fit.
16. Added the "subscription-printer-uri" (uri) to the Subscription
object to go along with the Job's "job-printer-uri" (uri)
attribute.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 6]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
17. Added "job-k-octets-processed" (integer(0:MAX)) to the Job
Notification content for 'job-progress' and 'job-completed'
events.
18. Added the 'job-progress' attributes to also be in the 'job-
completed' Job Notification content.
3 Changes made from August 8, 1999 version to make the August 11, 1999
version
The following changes were made from the 99/08/07 version to make the
99/08/11 version as result of the IPP telecon, 9908/11:
1. Changed the name of the Replace-Job-Subscription operation to Set-
Job-Subscription, since it can add, remove or change Job
notification attributes, not just replace them.
2. Added the configuration pictures.
3. Reduced the size of "notify-user-data" from 255 octets to 63
octets, since it is also send in the Notification content which has
a limit of 480 or so octets on some transports.
4. Changed the conformance requirements for the "notify-exclude-event-
masks (1setOf octetString(8))" operation attributes in Job creation
and Create-Printer-Subscription operations from OPTIONAL to
REQUIRED, since their implementation means that clients can count
on it. Also the minimum number of Per-Printer Subscriptions can be
less, since a client won't be forced to use multiple subscriptions
when recipients have different events. Finally, SNMPv3 has the
exclude mask mechanism.
5. Added the OPTIONAL "notify-natural-languages" (1setOf
naturalLanguage) Job Description attribute so that each
Notification Recipient could get a requested natural language,
instead of the one in the Job creation request.
6. Deleted the "job-trigger-message" Job Description attribute from
Job object attribute. The client can localize the remaining Job
attributes on its slow scan in case Notifications are dropped.
7. Added the "notify-request-ids (1setOf integer(0:MAX))" Job
Description attribute to the Job object to indicate (and remember)
the most recent request-id delivered for each Notification
Recipient.
8. Deleted "previous-job-state (type1 enum)" and "job-state-reasons-
added (1setOf type2 keyword)" and "job-state-reasons-deleted
(1setOf type2 keyword)" from the Job object. The "job-state-
reasons" value has enough information about why the Job is in the
current state, so that we don't need the previous state and state
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 7]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
reasons for the slow scan polling Notification Recipient that is
attempting to overcome possible dropped Notifications.
9. Added REQUIRED "max-recipients-supported (integer(0:MAX))" Printer
Description attribute to the Printer object to indicate the max
number of Per-Job and Per-Printer Notification Recipients supported
in each subscription. REQUIRE a minimum of 3 recipients.
10. Added the requirement that at least 8 Per-Printer Subscription
object instances MUST be supported, if Per-Printer subscriptions
are supported. With the exclude mask, such a low number as 8 isn't
too restrictive on clients and isn't too expensive for low end
devices.
11. Added the OPTIONAL "persistent-subscriptions-supported"
(boolean) Printer Description attribute to the Printer object to
indicate whether or not the Printer supports persistent Per-Printer
Subscriptions.
12. Changed the Printer support requirements for the "notify-
exclude-event-mask" (1setOf octetString(8)) from OPTIONAL to
REQUIRED, so that clients can count on it and to reduce the number
of Subscription objects that a Printer MUST support.
13. Added the OPTIONAL "notify-natural-languages" (1setOf
naturalLanguage) Subscription object attribute so that each
Notification Recipient could get a requested natural language,
instead of the one in the Create-Printer-Subscription request.
14. Added the "subscription-id" attribute to the Subscription
object so that each object instance is identified in a manner
analogous to Job objects.
15. Changed the name of "most-recent-request-id" to "notify-
request-ids" for consistency in naming and to be the same as the
corresponding Job Description attribute ("notify-request-ids").
16. Changed the name of the "notify-lease-time-remaining"
Subscription object attribute to "notify-lease-time". Changed the
semantics from the lease time interval requested to the "printer-
up-time" (time ticks) that the lease expires. The client can
subtract the "printer-up-time" from the "notify-lease-time" to find
out how much time is left on the lease. This change makes the
attribute value be a constant, instead of having to be recomputed
on each Get-Printer-Subscription-Attribute request.
17. Changed the name of the "notify-lease-time (integer(0:MAX))"
Subscription object attribute to "notify-lease-time-granted
(integer(0:MAX))" and indicated that it is set by the Printer not
the client.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 8]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
18. Added 'printer-announce' event, so that the Subscriber can
have the Notification Recipient be warned that other Printer events
are forth coming.
19. Added 'printer-queue-changed' - so that an application that is
monitoring the queue can re-fetch the queue with Get-Jobs.
20. Added "attributes-charset" and "attributes-natural-language"
to the Job and Printer Notification content, since the content is
an 'application/ipp' MIME type for an IPP response.
21. Added "printer-name (name(127))" and "job-name (name(MAX))" to
Job and Printer Notification Content. These are helpful to end
users to identify from whence came a notification.
22. Deleted the "job-trigger-message (text(255))" from the Job
Notification content since the data is already available in other
attributes that the recipient should localize to present to a
human. Also the Human Consumable form will have many of the
attributes when it is used.
23. Deleted "previous-job-state (type1 enum)" and "job-state-
reasons-added (1setOf type2 keyword)" and "job-state-reasons-
deleted (1setOf type2 keyword)" from the Job Notification content.
The current "job-state-reasons" value has enough information about
why the Job is in the current state, so that we don't need the
previous state and state reasons.
24. Deleted the "printer-trigger-message (text(255))" from the
Printer Notification content, since the data is already available
in other attributes that the recipient should localize to present
to a human. Also the Human Consumable form will have many of the
attributes when it is used.
25. Added [job-id (integer(1:MAX))] and [job-name (name(MAX))] to
the Printer Notification content for when the event is from a Per-
Job subscription.
26. Deleted "previous-printer-state (type1 enum)" and "printer-
state-reasons-added (1setOf type2 keyword)" and "printer-state-
reasons-deleted (1setOf type2 keyword)" from the Printer
Notification content. The current "printer-state-reasons" value
has enough information about why the Printer is in the current
state, so that we don't need the previous state and state reasons.
27. Added "printer-is-accepting-jobs (boolean)" attribute to the
Printer Notification content, since it is a state variable and its
change causes the 'printer-state-change' event.
28. Added the definition of the Set-Job-Subscription operation.
29. Changed the name of "notify-lease-time" operation attribute in
the Create-Printer-Subscription operation to "notify-lease-time-
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 9]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
requested" to distinguish it from the "notify-lease-time" (uptime
ticks) and "notify-lease-time-granted" returned in the response.
30. Added the "notify-persistence (boolean)" operation attribute
to the Create-Printer-Subscriptions to indicate whether the
notification content delivery is to make the Per-Printer
Subscription be permanent.
4 Changes to the August 2, 1999 version to make the August 7, version
1.Changed the Subscription object to be used only with the Per-
Printer subscriptions. Per-Job subscriptions are done with Job
Creation operation attributes that are copied to the Job object
as Job Description attributes.
5 Changes to the July 22, 1999 version to make the August 2, 1999
version
1. Introduced the Subscription object for use with both Job
Subscriptions and Printer Subscriptions. A Subscription object is
associated with a Printer object, a Job object, or is an
unassociated Job Subscription waiting for the Job object to be
created and a back association made to it.
2. Add the following operations on the Subscription object:
Create-Subscription recipients, [events,] [user-data,]
[lease-time,] [job-id or printer-uri]
Get-Subscription-Attributes subscription-id, [requested-
attributes]
Renew-Subscription subscription-id, [lease time]
Cancel-Subscription subscription-id
6 Changes to the July 21, 1999 to make the July 22, 1999 (T Hastings)
1. Added the REQUIRED "initial-sequence-numbers" (1setOf
integer(1:MAX)) to the Subscribe-Printer response to indicate the
sequence number to be used in the first notification for each event
subscribed.
2. Added a number of issues and renumbered.
7 Changes to the July 20, 1999 to make the July 21, 1999 (T Hastings)
The following changes were made to the July 20, 1999 to make the July
21, 1999 version:
1.Changed the "job-trigger-events (1setOf type2 keyword)" Job
Description attribute "job-trigger-event (type2 keyword), since
events cannot be batched in a notification.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 10]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
2.Changed the "printer-trigger-events (1setOf type2 keyword)"
Printer Description attribute "printer-trigger-event (type2
keyword), since events cannot be batched in a notification.
3.Changed Subscribe-Job from REQUIRED to OPTIONAL if implementing
"Explicit Subscription".
4.Clarified that events are defined to be disjoint, since the job-
trigger-event is now single-valued. Thus only the 'job-created'
event is generated even if job state reasons are added.
Similarly, only the 'job-completed' event is generated even if
job state reasons are added or removed.
5.Indicated which Job Description and Printer Description
attributes are READ-ONLY, i.e., MUST NOT be settable with Set-
Job-Attributes or Set-Printer-Attributes operations.
6.Clarified which Job attributes cause 'job-config-changed' event:
"job-message-from-operator" and any non-READ-ONLY Job
attributes.
7.Clarified which Printer attributes cause 'printer-config-
changed' event: "printer-message-from-operator" and any non-
READ-ONLY Printer attributes, except "media-ready" which has its
own event.
8.Renamed 'ready-for-job' event to 'printer-is-no-longer-full' and
clarified that it is generated only when a previous Print-Job,
Print-URI, Create-Job, Send-Document, or Send-URI operation had
been rejected due to no more room.
9.Renamed 'ready-for-just-in-time-job' to 'printer-almost-idle',
to make it clearer how this event differs from 'printer-is-no-
longer-full'.
10. Kept 'printer-shutdown' and 'printer-restarted' as separate
and disjoint from 'printer-state-changed' event, so that they
can be subscribed without having to get all state change events.
Also parallel with 'job-created', 'job-state-change', and 'job-
completed'. Also clarified that shutdown means either using the
Shutdown-Printer operation with 'standby' or 'power-down'
options or power-down by other means. Same for 'printer-
restarted' being with the Restart-Printer operation or a power-
up sequence.
8 Changes to the May 18, 1999 to make the July 20, 1999 (M Shepherd)
The following changes were made to the May 18, 1999 to make the July 20,
1999 version:
1.Added new section Conformance Requirements
2.Changed 'event report' to 'notification'
3.Changed 'request-id' to be used as a sequence number inside each
notification.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 11]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
4.Combined job-state-changed and job-state-reason-change into one
notification trigger-event.
5.Combined printer-state-changed and printer-state-reason-change
into one notification trigger event.
6.Added "job-config-changed" event
7.Moved "device-powering-down" event to be encompassed by
"printer-state-change"
8.Combined this spec with the Job Independent Subscriptions spec
(which was renamed to Explicit Subscriptions).
9.Added operation Subscribe-Job.
10. Added server-error-too-many-subscriptions to Status Codes.
9 Changes to the May 17, 1999 to make the May 18, 1999 (T Hastings, R
Bergman)
1.Removed concept of event groups. Subscribe to individual
events. Much simpler. The event determines what data is sent
in the event report. Also allows the client to query the
printer to see what events are supported, rather than which
groups.
2.Replaced all of the job state transition events with a single
'job-state-changed' event. The report contains the old job state
and the new job state.
3.Removed the notification-format attribute to keep the proposal
simple.
4.Added the 'client-error-notify-uri-scheme-not-supported' status
code.
5.Added REQUIRED "previous-job-state", "previous-job-state-
reasons", previous-printer-state", and "previous-printer-state-
reasons" Job Description attributes.
6.Removed the "job-impressions-completed" from the Basic Job Event
Report Content. Bring it back with the "job-progress" events.
7.Removed the "printer-is-accepting-jobs" from the Basic Printer
Event Report Content. Its changing is part of the "config-
change" event.
8.Changed the 'job-state-changed' event, so that it doesn't
include 'job-created', 'job-completed', or 'job-purged' events.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 12]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
9.Made the event names mostly consistent by being in the past
tense to reflect the fact that events reports happen after the
internal event has completed.
10. Combined the 'job-state-reasons-added' and 'job-state-reasons-
removed' into a single event: 'job-state-reasons-changed'. Same
for 'printer-state-reasons-changed'.
11. Changed 'mailto' notification method to REQUIRE
'multipart/report' which all mail agents understand, at least
the text part.
12. Deleted the 'job-warning' and 'job-error' events, since they
are covered by the 'job-state-reasons-changed, 'job-state-
changed' and/or 'job-completed' events.
10 Changes to the January 20, 1999 to make the May 17, 1999 version (M
Shepherd)
1. Changed references to IPP 1.0 to IPP 1.1
2. Implementing the notification specification is optional.
3. Refined the definition of Event
4. Changed 'notification report' to 'event report' for consistent
terminology
5. Changed the terminology of an 'active' job to 'not-complete'.
Included the 'pending-held' state in the 'not-complete' super-
state.
6. Introduced notify-event-groups-default.
7. Changed job-trigger-message and job-impressions-completed to be
CONDITIONAL in the event report, job-trigger-date-time to be
RECOMMENDED, and job-state-reasons to be REQUIRED.
8. Changed printer-trigger-message to be CONDITIONAL in the event
report, and printer-state-reasons to be REQUIRED.
9. Created a table to map job-trigger-events keywords to event-groups
and required status.
10. Modified job-continued to be job-resumed-processing, and job-
received to be job-created. Added job-purged, job-state-reason-
removed, and job-state-reason-added keywords.
11. Modified job-trigger-time and printer-trigger-time to use
values less than zero.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 13]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
12. Created a table to map printer-trigger-events keywords to
event-groups and their required status.
13. Added ready-for-job and printer-state-reason-added to printer-
trigger-events keywords.
14. Updated References section
15. Added notify-format and notify-format-supported attributes.
16. Added subscription-id to the event report attributes of job
and printer.
17. Made job-errors-basic and printer-errors-basic REQUIRED to be
supported.
18. Added printer-media-changed, printer-config-changed, and
ready-for-just-in-time-job to printer events.
19. Added Author's Addresses.
11 Changes to the January 18, 1999 to make the January 20, 1999 version
The following changes were made to the January 18, 1999 to make the
January 20, 1999 version:
1. Made this an INTERNET-DRAFT.
2. Indicated that a new default port is needed for the delivery
methods.
3. Added Appendices in which to put the registration information for
the URL schemes for each delivery method.
4. Clarified which parameters, Operation attributes, and Job/Printer
attributes are supplied in an event content: the request-id is 0,
the status-code is new 'job-event' 0x600 or 'printer-event' 0x601.
5. Changed "job-trigger-event" and "printer-trigger-event" to be
1setOf so that multiple events that occur at the same time MAY be
send as one event content.
6. Added "job-trigger-time" as a REQUIRED Job Description and event
content attribute which is in seconds since power up.
7. Changed "job-trigger-date-time" and "job-state-reasons" to
OPTIONAL.
8. Changed "status-message" to be an OPTIONAL "job-trigger-message"
event content attribute and also made it a Job Description
attribute.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 14]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
9. Added "printer-trigger-time" as a REQUIRED Printer Description and
event content attribute which is in seconds since power up.
10. Changed "printer-trigger-date-time" and "printer-state-
reasons" to OPTIONAL.
11. Changed "status-message" to be an OPTIONAL "printer-trigger-
message" event content attribute and also made it a Printer
Description attribute.
12. Removed the "job-id" attribute from the printer event content.
12 Changes to the December 10, 1998 to make the January 18, 1999 version
The following changes were made to the December 10, 1998 to make the
January 18, 1999 version:
1. Changed the names of the REQUIRED notify-recipient keywords from:
'ipp-tcp-socket' and 'ipp-udp-socket' to 'ipp-tcp-notify' and 'ipp-
udp-notify'.
2. Added '-notify' to the OPTIONAL 'snmpv1', 'snmpv2', and 'snmpv3'
delivery method names.
3. Changed the OPTIONAL 'sense-datagram' to 'sense-notify' to be
consistent.
4. Added 'ndps-notify' as an OPTIONAL keyword.
5. Deleted the 'all-basic', 'all-job-events-basic', and 'all-printer-
events-basic'. Clients should be explicit about which groups they
want. If new groups are added, the clients won't know what to do
with them, if they had subscribed to 'all-xxx' groups.
6. Changed the names of "job-last-event" and "job-last-date-time-of-
event" to "job-trigger-event" and "job-trigger-date-time" events,
since the events trigger the notification delivery, but the
attribute values remain after the event has been delivered.
7. Added "status-message" as an OPTIONAL event report content
attribute.
8. Changed "job-impressions-completed" to OPTIONAL.
9. Indicated that OPTIONAL attributes are not sent in the event report
content if they are not supported.
10. Required that "status-message" and/or "job-impressions-
completed" be sent in an event report content if they are supported
as an Operation attribute and a Job Description attribute,
respectively.
11. Added REQUIRED "printer-trigger-event", REQUIRED "job-id", and
OPTIONAL "status-message" to the printer event report content.
12. Specified the "printer-trigger-event" Printer Description
attribute, naming each event.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 15]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
13. Deleted the 'sheet-completed' and 'collated-copy-completed',
since these events are not part of any 'xxx-basic' event group.
They can be added back when we have an event group that uses them.
13 Changes to the July 1, 1998 to make the December 10, 1998 version
The following changes made from the July 1, 1998 to make the December
10, 1998 version:
1. Clarified the terminology so that an "event" doesn't necessarily
mean that a notification report is delivered.
2. Removed many of the job and printer attributes for being sent in a
notification event report, so that we can get agreement on a basic
set of event report content. Only attributes really needs are
included, including what may be needed for FAX. Changed the names
of the event groups by adding the suffix '-basic' to indicate that
these event groups return only basic information. Additional event
groups can be registered in order to get more attributes as needed
for accounting and more detailed job monitoring purposes.
3. Deleted the "job-progress" event group. We can bring it back when
we agree to all of the extra attributes. Its not very useful with
only the basic attributes.
4. The printer events are indicted using the "printer-state-reasons"
values, instead of the Printer MIB alert codes. Since most of the
Printer MIB alert codes, except for the generic ones, have
equivalent IPP keyword reason values, this should be a problem and
makes IPP more readably implemented in a server that doesn't have
the Printer MIB.
5. Added the "job-last-event" job description attribute to give the
job event some persistence.
6. Changed the job's "time-at-event (integer)" to "job-last-date-time-
of-event (dateTime)" to give an absolute date and time, in case
events are being relayed back through multiple servers, such as in
FAX. Also made it a Job Description attribute to give it
persistence.
7. Changed the printer's "time-at-event(integer)" to "printer-last-
date-time-of-event(dateTime)" to give an absolute date and time, in
case events are being relayed back through multiple servers, such
as in FAX. Also made it a Printer Description attribute to give it
persistence.
8. Added the IPP/1.0 "printer-is-accepting-jobs" to the event report,
since changes in its value are really printer state changes.
9. Added the complete semantics for each job event under the "last-
job-event" Job Description attribute.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 16]
Expires February 25, 2000
INTERNET-DRAFTIPP 1.0 & 1.1: Notification Change HistoryAugust 22, 1999
14 Prior work on Notification
A general notification service and a reference implementation was
developed during the 1995 and Spring of 1996. It is entitled: "System
Event Notification System Environment (SENSE)". It used the publish and
subscribe model with subscribers subscribing to the Notification Service
directly, not the Print Service.
[sense]
Martin, J. et all., "System Event Notification System Environment
(SENSE)", ftp://ftp.pwg.org/pub/pwg/sense/, work in progress, Spring
1996.
Isaacson, Martin, deBry, Hastings, Shepherd, Bergman [page 17]
Expires February 25, 2000
