transport, the actual order that a Notification Recipient receives
separate Event Notifications may differ from the order sent by the
Printer (e.g., email).
Example: Consider two Per-Printer Subscription Objects: SO1 and SO2.
SO1 requests ’job-state-changed’ events and SO2 requests ’printer-
state-changed’ events. The number in parens is the time stamp. The
following Event Notification sequences are the only ones that conform
to the ordering requirements for the Printer to deliver the Event
Notifications:
(a) SO1: ’job-created’ (1000), SO1: ’job-stopped’ (1005), SO1:
’job-completed’ (1009), SO2: ’printer-stopped’ (1005)
(b) SO1: ’job-created’ (1000), SO1: ’job-stopped’ (1005), SO2:
’printer-stopped’ (1005), SO1: ’job-completed’ (1009)
(c) SO1: ’job-created’ (1000), SO2: ’printer-stopped’ (1005), SO1:
’job-stopped’ (1005), SO1: ’job-completed’ (1009)
(d) SO2: ’printer-stopped (1005), SO1: ’job-created’ (1000), SO1:
’job-stopped’ (1005), SO1: ’job-completed’ (1009)
Examples (b) and (c) are interleaved; examples (a) and (d) are not
interleaved and are not appropriate for some Delivery Methods.
If two different Events occur simultaneously, or nearly so (e.g.,
"printer-up-time" has the same value for both), the Printer MUST
create a separate Event Notification for each Event, even if the
associated Subscription Object is the same for both Events. However,
the Printer MAY combine these distinct Event Notifications into a
single Compound Event Notification if the Delivery Method supports
Compound Event Notifications. For example, suppose that two nearly-
simultaneously Events represent two successive ’printer-state-
changed’ Events, one from ’idle’ to ’processing’ and another from
’processing’ to ’stopped’. These two Events have the same name but
are different instances of the Event. Then the Printer MUST create a
separate Event Notification for each Event and SHOULD accurately
report the "printer-state" of the first Event as ’processing’ and the
second Event as ’stopped’.
If a Subscription Object contains more than one Subscribed Event, and
several Events occur in quick succession each matching a different
Subscribed Event in the Subscription Object, the Printer MUST NOT
generate a single Event Notification from several of these Events,
but MAY combine distinct Event Notifications into a single Compound
Event Notification if the Delivery Method supports Compound Event
Notifications.
After the Printer has created the Event Notification, the Printer
delivers it via either a:
Push Delivery Method: The Printer delivers the Event Notification
shortly after an Event occurs. For some Push Delivery Methods,
the Notification Recipient MUST deliver a response; for others it
MUST NOT deliver a response.
Pull Delivery Method: The Printer saves Event Notifications for
some Event Life and expects the Notification Recipient to request
Event Notifications. The Printer returns the Event Notifications
in a response to such a request.
If an error that meets the following conditions occurs, the Printer
MUST cancel the Subscription Object.
a) the error occurs during the delivering of an Event Notification
generated from Subscription Object S AND
b) the error would continue to occur every time the Printer delivers
an Event Notification generated from Subscription Object S in the
future.
For example, if the address of the "notify-recipient-uri" of
Subscription Object A references a non-existent target and the
Printer determines this fact, it MUST delete Subscription Object A.
The next two sections describe the values that a Printer delivers in
the content of Machine Consumable and Human Consumable Event
Notifications, respectively.
The tables in the sub-sections of this section contain the following
columns:
a) Source Value: the name of the attribute that supplies the value
for the Event Notification. Asterisks in this field refer to a
note below the table.
b) Delivers: if the Printer supports the value (column 1) on the
Source Object (column 3) the Delivery Method MUST specify:
MUST: that the Printer MUST deliver the value.
SHOULD: either that the Printer MUST deliver the value or that
the value is incompatible with the Delivery Method.
MAY: that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT,
or NEED NOT deliver the value. The Delivery Method specifies
the level of conformance for the Printer.
c) Source Object: the object from which the source value comes. If
the object is "Event Notification", the Printer fabricates the
value when it delivers the Event Notification. See section 8.
9.1. Content of Machine Consumable Event Notifications
This section defines the attributes that a Delivery Method MUST
mention in a Delivery Method Document when specifying the Machine
Consumable Event Notification’s contents.
This document does not define the order of attributes in Event
Notifications. However, Delivery Method Documents MAY define the
order of some or all of the attributes.
A Delivery Method Document MUST specify additional attributes (if
any) that a Printer implementation delivers in a Machine Consumable
Event Notification.
Notification Recipients MUST be able to accept Event Notifications
containing attributes they do not recognize. What a Notification
Recipient does with an unrecognized attribute is implementation-
dependent. Notification Recipients MAY attempt to display
unrecognized attributes anyway or MAY ignore them.
The next three sections define the attributes in Event Notification
Contents that are:
1. for all Events
2. for Job Events only
3. for Printer Events only
9.1.1. Event Notification Content Common to All Events
This section lists the attributes that a Delivery Method Document
MUST specify for all Events.
Table 5 lists potential values in each Event Notification.
Table 5 - Attributes in Event Notification Content
Source Value Delivers Source Object
notify-subscription-id (integer(1:MAX)) MUST Subscription
notify-printer-uri (uri) MUST Subscription
notify-subscribed-event (type2 keyword) MUST Event
Notification
printer-up-time (integer(MIN:MAX)) MUST Printer
printer-current-time (dateTime) * MUST Printer
notify-sequence-number (integer (0:MAX)) SHOULD Subscription
notify-charset (charset) SHOULD Subscription
notify-natural-language (naturalLanguage) SHOULD Subscription
notify-user-data (octetString(63)) ** SHOULD Subscription
notify-text (text) SHOULD Event
Notification
attributes from the "notify-attributes" MAY Printer
attribute ***
attributes from the "notify-attributes" MAY Job
attribute ***
attributes from the "notify-attributes" MAY Subscription
attribute ***
*A Printer MUST deliver this value only if and only if it supports
the Printer’s "printer-current-time" attribute.
** If the Subscription Object does not contain a "notify-user-data"
attribute and the Delivery Method Document REQUIRES the Printer to
deliver the "notify-user-data" source value in the Event
Notification, the Printer MUST deliver an octet-string of length 0.
*** The last three rows represent additional attributes that a client
MAY request via the "notify-attributes" attribute. A Printer MAY
support the "notify-attributes" attribute. The Delivery Method MUST
say that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, or NEED
NOT support the "notify-attributes" attribute and specific values of
this attribute. The Delivery Method MAY say that support for the
"notify-attributes" is conditioned on support of the attribute by the
Printer or it MAY say that Printer MUST support the "notify-
attributes" attribute if the Printer supports the Delivery Method.
9.1.2. Additional Event Notification Content for Job Events
This section lists the additional attributes that a Delivery Method
Document MUST specify for Job Events. See Table 6.
Table 6 - Additional Event Notification Content for Job Events
Source Value Delivers Source
Object
job-id (integer(1:MAX)) MUST Job
job-state (type1 enum) MUST Job
job-state-reasons (1setOf type2 keyword) MUST Job
job-impressions-completed (integer(0:MAX)) * MUST Job
* The Printer MUST deliver the "job-impressions-completed" attribute
in an Event Notification only for the combinations of Events and
Subscribed Events shown in Table 7.
Table 7 - Combinations of Events and Subscribed Events for "job-
impressions-completed"
Job Event Subscribed Job Event
’job-progress’ ’job-progress’
’job-completed’ ’job-completed’
’job-completed’ ’job-state-changed’
9.1.3. Additional Event Notification Content for Printer Events
This section lists the additional attributes that a Delivery Method
Document MUST specify for Printer Events. See Table 8.
Table 8 - Additional Event Notification Content for Printer Events
Source Value Delivers Source Object
printer-state (type1 enum) MUST Printer
printer-state-reasons (1setOf type2 MUST Printer
keyword)
printer-is-accepting-jobs (boolean) MUST Printer
9.2. Content of Human Consumable Event Notification
This section defines the information that a Delivery Method MUST
mention in a Delivery Method Document when specifying the Human
Consumable Event Notifications contents or the value of the "notify-
text" attribute.
Such a Delivery Method MUST specify the following information and a
Printer SHOULD deliver it:
a) the Printer name (see Table 9)
b) the time of the Event (see Table 11)
c) for Printer Events only:
i) the Event (see Table 10) and/or Printer state information (see
Table 14)
d) for Job Events only:
i) the job identity (see Table 12)
ii) the Event (see Table 10) and/or Job state information (see
Table 13)
The subsections of this section specify the attributes that a Printer
MUST use to obtain this information.
A Delivery Method Document MUST specify additional information (if
any) that a Printer implementation delivers in a Human Consumable
Event Notification or in the "notify-text" attribute.
A client MUST NOT request additional attributes via the "notify-
attributes" attribute because this attribute works only for Machine
Consumable Event Notifications.
Notification Recipients MUST NOT expect to be able to parse the Human
Consumable Event Notification contents or the value of the "notify-
text" attribute.
The next three sections define the attributes in Event Notification
Contents that are:
a) for all Events
b) for Job Events only
c) for Printer Events only
9.2.1. Event Notification Content Common to All Events
This section lists the source of the information that a Delivery
Method MUST specify for all Events.
There is a separate table for each piece of information. Each row in
the table represents a source value for the information and the
values are listed in order of preference, with the first one being
the preferred one. An implementation SHOULD use the source value
from the earliest row in each table. It MAY use the source value
from another row instead, or it MAY combine the source values from
several rows. An implementation is free to determine the best way to
present this information.
In all tables of this section, all rows contain a "MAY" in order to
state that the Delivery Method specifies the conformance.
Table 9 lists the source of the information for the Printer Name.
The "printer-name" is more user-friendly unless the Notification
Recipient is in a place where the Printer name is not meaningful.
For example, an implementation could have the intelligence to deliver
the value of the "printer-name" attribute to a Notification Recipient
that can access the Printer via value of the "printer-name" attribute
and otherwise deliver the value of the "notify-printer-uri"
attribute.
Table 9 - Printer Name in Event Notification Content
Source Value Delivers Source Object
printer-name (name(127)) MAY Printer
notify-printer-uri (uri) MAY Subscription
Table 10 lists the source of the information for the Event name. A
Printer MAY combine this information with state information described
for Jobs in Table 13 or for Printers in Table 14.
Table 10 - Event Name in Event Notification Content
Source Value Delivers Source Object
notify-subscribed-event (type2 keyword) MAY Subscription
Table 11 lists the source of the information for the time that the
Event occurred. A Printer can deliver this value only if it supports
the Printer’s "printer-current-time" attribute. If a Printer does
not support the "printer-current-time" attribute, it MUST NOT deliver
the "printer-up-time" value instead, since it is not an allowed
option for human consumable information.
Table 11 - Event Time in Event Notification Content
Source Value Delivers Source Object
printer-current-time (dateTime) MAY Printer
9.2.2. Additional Event Notification Content for Job Events
This section lists the source of the additional information that a
Delivery Method MUST specify for Job Events.
Table 12 lists the source of the information for the job name. The
"job-name" is likely more meaningful to a user than "job-id".
Table 12 - Job Name in Event Notification Content
Source Value Delivers Source Object
job-name (name(MAX)) MAY Job
job-id (integer(1:MAX)) MAY Job
Table 13 lists the source of the information for the job state. If a
Printer supports the "job-state-message" and "job-detailed-state-
message" attributes, it SHOULD use those attributes for the job state
information, otherwise, it should fabricate such information from the
"job-state" and "job-state-reasons". For some Events, a Printer MAY
combine this information with Event information.
Table 13 - Job State in Event Notification Content
Source Value Delivers Source
Object
job-state-message (text(MAX)) MAY Job
job-detailed-status-messages (1setOf text(MAX)) MAY Job
job-state (type1 enum) MAY Job
job-state-reasons (1setOf type2 keyword) MAY Job
9.2.3. Additional Event Notification Content for Printer Events
This section lists the source of the additional information that a
Delivery Method MUST specify for Printer Events.
Table 14 lists the source of the information for the printer state.
If a Printer supports the "printer-state-message", it SHOULD use that
attribute for the job state information, otherwise it SHOULD
fabricate such information from the "printer-state" and "printer-
state-reasons". For some Events, a Printer MAY combine this
information with Event information.
Table 14 - Printer State in Event Notification Content
Source Value Delivers Source
Object
printer-state-message (text(MAX)) MAY Printer
printer-state (type1 enum) MAY Printer
printer-state-reasons (1setOf type2 keyword) MAY Printer
printer-is-accepting-jobs (boolean) MAY Printer
10. Delivery Methods
A Delivery Method is the mechanism, i.e., protocol, by which the
Printer delivers an Event Notification to a Notification Recipient.
There are several potential Delivery Methods for Event Notifications,
standardized, as well as proprietary. This specification REQUIRES
that the ’ippget’ Pull Delivery Method [RFC3996] be supported.
Conforming implementations MAY support additional Push or Pull
Delivery Methods as well. This document does not define any of these
delivery mechanisms. Each Delivery Method MUST be defined in a
Delivery Method Document that is separate from this document. New
Delivery Methods will be created as needed using an extension to the
registration procedures defined in [RFC2911]. Such documents are
registered with IANA (see section 23.7.3).
The following sorts of Delivery Methods are possible:
- The Notification Recipient polls for Event Notifications at
intervals directed by the Printer
- The Printer delivers Event Notifications to the Notification
Recipient using http as the transport.
- The Printer delivers an email message.
This section specifies how to define a Delivery Method Document and
what to put in such a document.
A Delivery Method Document MUST contain an exact copy of the
following paragraph, caption and table. In addition, column 2 of the
table in the Delivery Method Document MUST contain answers to
questions in column 1 for the Delivery Method. Also, the Delivery
Method document MUST contain a reference to this document and call
that reference [RFC3995] because the table contains an [RFC3995]
reference.
If a Printer supports this Delivery Method, the following are its
characteristics.
Table 15 - Information about the Delivery Method
Document Method Conformance Requirement Delivery Method
Realization
1. What is the URL scheme name for the Push Delivery Method or the
keyword method name for the Pull Delivery Method?
2. Is the Delivery Method REQUIRED, RECOMMENDED, or OPTIONAL for an
IPP Printer to support?
3. What transport and delivery protocols does the Printer use to
deliver the Event Notification Content, i.e., what is the entire
network stack?
4. Can several Event Notifications be combined into a Compound Event
Notification?
5. Is the Delivery Method initiated by the Notification Recipient
(pull), or by the Printer (push)?
6. Is the Event Notification content Machine Consumable or Human
Consumable?
7. What section in this document answers the following question?
For a Machine Consumable Event Notification, what is the
representation and encoding of values defined in section 9.1 of
[RFC3995] and the conformance requirements thereof? For a Human
Consumable Event Notification, what is the representation and
encoding of pieces of information defined in section 9.2 of
[RFC3995] and the conformance requirements thereof?
8. What are the latency and reliability of the transport and
delivery protocol?
9. What are the security aspects of the transport and delivery
protocol, e.g., how it is handled in firewalls?
10. What are the content length restrictions?
11. What are the additional values or pieces of information that a
Printer delivers in an Event Notification content and the
conformance requirements thereof?
12. What are the additional Subscription Template and/or
Subscription Description attributes and the conformance
requirements thereof?
13. What are the additional Printer Description attributes and the
conformance requirements thereof?
11. Operations for Notification
This section defines all of the operations for Notification. Section
7.1 assigns the "operation-id" for each operation. The following two
sub-sections define Subscription Creation Operations, and other
operations.
11.1. Subscription Creation Operations
This section defines the Subscription Creation Operations. The first
section on Create-Job-Subscriptions gives most of the information.
The other Subscription Creation Operations refer to the section on
Create-Job-Subscriptions, even though the Create-Job-Subscriptions
operation is the only OPTIONAL operation in this document (see
section 12).
A Printer MUST support Create-Printer-Subscriptions and the
Subscription Template Attributes Group in Job Creation operations.
It MAY support Create-Job-Subscriptions operations.
11.1.1. Create-Job-Subscriptions Operation
The operation creates one or more Per-Job Subscription Objects. The
client supplies one or more Subscription Template Attributes Groups
each containing one or more of Subscription Template Attributes
(defined in section 5.3).
Except for errors, the Printer MUST create exactly one Per-Job
Subscription Object from each Subscription Template Attributes Group
in the request, even if the newly created Subscription Object would
have identical behavior to some existing Subscription Object. The
Printer MUST associate each newly created Per-Job Subscription Object
with the target Job, which is specified by the "notify-job-id"
operation attribute.
The Printer MUST accept the request in any of the target job’s ’not-
completed’ states, i.e., ’pending’, ’pending-held’, ’processing’, or
’processing-stopped’. The Printer MUST NOT change the job’s "job-
state" attribute because of this operation. If the target job is in
any of the ’completed’ states, i.e., ’completed’, ’canceled’, or
’aborted, then the Printer MUST reject the request and return the
’client-error-not-possible’ status code; the response MUST NOT
contain any Subscription Attribute Groups.
Access Rights: To create Per-Job Subscription Objects, the
authenticated user (see [RFC2911] section 8.3) performing this
operation MUST (1) be the job owner, (2) have Operator or
Administrator access rights for this Printer (see [RFC2911] sections
1 and 8.5), or (3) be otherwise authorized by the Printer’s
administrator-configured security policy to create Per-Job
Subscription Objects for the target job. Otherwise the Printer MUST