Request for Comments: 3997 Xerox Corporation
Category: Informational R. K. deBry
Utah Valley State College
H. Lewis
IBM Corporation
March 2005
Internet Printing Protocol (IPP):
Requirements for IPP Notifications
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is one of a set of documents that together describe all
aspects of the Internet Printing Protocol (IPP). IPP is an
application-level protocol that can be used for distributed printing
on the Internet. There are multiple parts to IPP, but the primary
architectural components are the Model, the Protocol, and an
interface to Directory Services. This document provides a statement
of the requirements for notifications as an optional part of an IPP
Service.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations for IPP Notifications Requirements. . 12
6. Internationalization Considerations . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References. . . . . . . . . . . . . . . . . . 14
8.2. Informative References. . . . . . . . . . . . . . . . . 14
9. Appendix A: Description of the Base IPP Documents . . . . . . 15
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This document is one of a set of documents that together describe all
aspects of the Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
on the Internet. There are multiple parts to IPP, but the primary
architectural components are the Model, the Protocol, and an
interface to Directory Services. This document provides a statement
of the requirements for notifications as an optional part of an IPP
Service. See section 10 for a description of the base IPP documents.
The scope of this requirements document covers functionality used by
the following kinds of IPP Users: End Users, Print Administrators,
and Operators. See [RFC3995] for the extensions to the Internet
Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911],
[RFC2910], and future versions.
2. Terminology
It is necessary to define a set of terms to be able to clearly
express the requirements for notification services in an IPP System.
2.1. Job-Submitting End User
A human end user who submits a print job to an IPP Printer. This
person may or may not be within the same security domain as the
Printer. This person may or may not be geographically near the
printer.
2.2. Administrator
A human user who established policy for and configures the print
system.
2.3. Operator
A human user who carries out the policy established by the
Administrator and controls the day-to-day running of the print
system.
2.4. Job-Submitting Application
An application (for example, a batch application), acting on behalf
of a Job Submitting End User, that submits a print job to an IPP
Printer. The application may or may not be within the same security
domain as the Printer. This application may or may not be
geographically near the printer.
2.5. Security Domain
For the purposes of this discussion, the set of network components
that can communicate without going through a proxy or firewall. A
security domain may be geographically very large; for example,
anywhere within example.com.
2.6. IPP Client
The software component that sends IPP requests to an IPP Printer
object and accepts IPP responses from an IPP Printer.
2.7. Job Recipient
A human who is the ultimate consumer of the print job. In many cases
this will be the same person as the Job-Submitting End User, but this
need not always be the case. For example, if I use IPP to print a
document on a printer in a business partner’s office, I am the Job-
Submitting End User, and the person whom I intend the document for in
my business partner’s office is the Job Recipient. Since one of the
goals of IPP is to be able to print near the Job Recipient, we would
normally expect that person to be in the same security domain as, and
geographically near, the Printer. However, this may not always be
the case. For example, I submit a print job across the Internet to a
XYZ’s print shop. I am both the Submitting End User and the Job
Recipient, but I am neither near nor in the same security domain as
the Printer.
2.8. Job Recipient Proxy
A person acting on behalf of the Job Recipient. The Job Recipient
Proxy physically picks up the printed document from the Printer if
the Job Recipient cannot do so. The Proxy is by definition
geographically near and in the same security domain as the printer.
For example, I submit a print job from home to be printed on a
printer at work. I’d like my secretary to pick up the print job and
put it on my desk. In this case, I am acting as both a Job-
Submitting End User and a Job Recipient. My secretary is acting as a
Job Recipient Proxy.
2.9. Notification Subscriber
A client that requests the IPP Printer to send Event Notifications to
one or more Notification Recipients. A Notification Subscriber may
be a Job-Submitting End User or an End User, an Operator, or an
Administrator that is not submitting a job.
2.10. Notification Source
The entity that sends Event Notifications.
2.11. Notification Recipient
The entity that receives IPP Notifications about Job and/or Printer
events. A Notification Recipient may be a Job Submitting End User, a
Job-Submitting Application, a Job Recipient, a Job Recipient Proxy,
an Operator, an Administrator, etc., and his or her representative,
log file, usage statistics-gathering application, or other active or
passive entities.
2.12. Notification Recipient Agent
A program that receives Event Notifications on behalf of the
Notification Recipient. The agent may take some action on behalf of
the recipient, forward the notification to the recipient via some
alternative means (for example, page the recipient), or queue the
notification for later retrieval by the recipient.
2.13. Event
An Event is an occurrence (either expected or unexpected) within the
printing system of a change of state, condition, or configuration of
a Job or Printer object.
2.14. Event Notification
When an event occurs, an Event Notification is generated that fully
describes the event (what the event was, where it occurred, when it
occurred, etc.). Event Notifications are delivered to all the
Notification Recipients that are subscribed to that Event, if any.
The Event Notification is delivered to the address of the
Notification Recipient by using the notification delivery method
defined in the subscription. However, an Event Notification is sent
ONLY if there is a corresponding subscription.
2.15. Notification Subscription
A Notification Subscription is a request by a Notification Subscriber
to the IPP Printer to send Event Notifications to specified
Notification Recipient(s) when an event occurs.
2.16. Notification Attributes
IPP Objects (for example, a print job) from which notification are
being sent may have associated attributes. A user may want to have
one or more of these returned along with a particular notification.
In general, these may include any attribute associated with the
object emitting the notification. Examples include the following:
number-of-intervening jobs
job-k-octets
job-k-octets processed
job impressions
job-impressions-interpreted
job-impressions-completed
impressionsCompletedCurrentCopy (job MIB)
sheetCompletedCopyNumber (job MIB)
sheetsCompletedDocumentNumber (job MIB)
Copies-requested
Copy-type
Output-destination
Job-state-reasons
Job ID
Printer URI
Subscription ID (for job independent subscription)
2.17. Notification Delivery Method (or Delivery Method for Short)
Event Notifications are delivered by using a Delivery Method. An
example of a Delivery Method is email.
2.18. Immediate Notification
Notifications sent to the Notification Recipient or the Notification
Recipient’s agent in such a way that the notification arrives
immediately, within the limits of common addressing, routing, network
congestion, and quality of service.
2.19. Store-and-Forward Notification
Notifications that are not necessarily delivered to Notification
Recipients immediately but are queued for delivery by an intermediate
network application, for later retrieval. Email is an example of a
store-and-forward notification delivery method.
2.20. Reliable Delivery of Notifications
Notifications that are delivered by a reliable delivery of packets or
character stream, with acknowledgement and retry, so that delivery of
the notification is guaranteed within determinate time limits. For
example, if the Notification Recipient has logged off and gone home
for the day, an immediate notification cannot be guaranteed, even
when sent over a reliable transport, because there is nothing there
to catch it. Guaranteed delivery requires both store-and-forward
notification and a reliable transport.
2.21. Notification over Unreliable Transport
Notifications are delivered via the fundamental transport address and
routing framework, but no acknowledgement or retry is required.
Process-to-process communications, if involved, are unconstrained.
2.22. Human-Consumable Notification
Notifications intended to be consumed by human end users only. Email
would be an example of a Human-Consumable Notification, though it
could also contain Machine-Consumable Notification.
2.23. Machine-Consumable Notification
Notifications that are intended for consumption by a program only,
such as an IPP Client. Machine-Consumable Notifications may not
contain human-readable information. Do we need both human and
machine? Machine readable is intended for application-to-application
only. The Notification Recipient could process the machine-readable
Event Notification into human-readable format.
2.24. Mixed Notification
A mixed notification contains both Human-Consumable and Machine-
Consumable information.
3. Scenarios
1. Sitting in my office, I submit a print job to the printer down
the hall. I am in the same security domain as the printer and,
of course, geographically near. I want to know immediately when
my print job will be completed (or if there is a problem)
because the document I am working on is urgent. I submit the
print job with the following attributes:
- Notification Recipient: Me
- Notification Events: All
- Notification Attributes: Job-state-reason
- Notification Type: Immediate
2. Working from home, I submit a print job to the same printer as
in the previous example. However, I am not at work, I cannot
physically get the print file or do anything with it. It can
wait until I get to work this afternoon. However, I’d like my
secretary to pick up the output and put it on my desk so that it
doesn’t get lost or misfiled. I’d also like a store-and-forward
notification sent to my email so that when I get to work I can
tell whether there was a problem with the print job. I submit a
print job with the following attributes:
- Notification Recipient: My secretary
- Notification Events: Print complete
- Notification Type: Immediate
- Notification Recipient: Me
- Notification Events: Print complete
- Notification Attributes: Impressions completed
- Notification Type: Store and forward
3. Sitting in my office, I submit a print job to a client at an
engineering firm my company works with on a daily basis. The
engineering firm is in Belgium. I would like my client to know
when the print job is complete so that she can pick it up from
the printer in her building. It is important that she review it
right away and send her comments back to me. I submit the print
job with the following attributes:
- Notification Recipient: Client at engineering firm
- Notification Events: Print complete
- Notification Type: Immediate
- Notification Language: French
4. From a hotel room, I send a print job to a Kinko’s store in the
town I am working in, in order to get a printed report for the
meeting I am attending in the morning. As I’m going out to
dinner after I get this job submitted, an immediate notification
won’t do me much good. However, I’d like to check in the
morning before I drive to the Kinko’s store to see whether the
file has been printed. An email notification is sufficient for
this purpose. I submit the print job with the following
attributes:
- Notification Recipient: Me
- Notification Events: Print complete
- Notification Type: Store and forward
5. I am printing a large, complex print file. I want to have some
immediate feedback on the progress of the print job as it
prints. I submit the print job with the following attributes:
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: All state transitions
- Notification Attributes: Impression completed
6. I am an operator and one of my duties is to keep the printer
running. I subscribe independently from a job submission so
that my subscription outlasts any particular job. I subscribe
with the following attributes:
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: All Printer state transitions
- Notification Attributes: Printer state, printer state
reasons, device powering up, device powering down
7. I am a usage statistics gathering application. I subscribe
independently from a job submission so that my subscription
outlasts any particular job. My subscription may persist across
power cycles. I subscribe with the following attributes:
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: Job completion
- Notification Attributes: Impression completed, sheets
completed, time submitted, time started, time completed, job
owner, job size in octets, etc.
8. I am a client application program that displays a list of jobs
currently queued for printing on a printer. I display the
"job-name", "job-state", "job-state-reasons", "page-count", and
"intervening-jobs", either for the user’s jobs or for all jobs.
The window displaying the job list remains open for an
independent amount of time, and it is desired that it represent
the current state of the queue. It is desired that the
application only perform a slow poll in order to recover from
any missed notifications. So the event delivery mechanism
provides the means to update the screen on all needed changes,
including querying for some attributes that may not be delivered
in the Notification.
9. I am a client application program that displays a list of
printers. For each Printer, I display the current state and
configuration. The window displaying the printer list remains
open for an independent amount of time, and it is desired that
it represent the current state of each printer. It is desired
that the application only need to perform a slow poll in order
to recover from any missed notifications. So the event delivery
mechanism provides the means to update the screen on all needed
changes, including querying for some attributes that may not be
delivered in the Notification.
10. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I
want to support IPP Notification for each of the IPP Printer
objects that I implement. Many of these devices do not support
notification (or IPP). So I need to support the IPP
Notification semantics specified for each IPP Printer object
myself on behalf of each of the devices that each of the IPP
Printer objects represents. When I accept an IPP job creation
requests, I convert it to what the device will accept. In some
cases, I must poll the devices in order to be informed of their
job and device state and state changes to be able to send IPP
Notifications to subscribed Notification Recipients.
11. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I
want to support IPP Notification for each of the IPP Printer
objects that I implement. These devices all support IPP,
including IPP Notification. I would like the design choice for
supporting IPP Notification for these objects either (1) by
forwarding the notification to the IPP Printers that I, alone,
control and have them send the notifications to the intended
Notification Recipients without my involvement, or (2) by
replacing the notification submitted with the Job to indicate me
as the Notification Recipient; in turn I will forward
Notifications to the Notification Recipients requested by my
clients. Most of the rest of the contents of the IPP Job I send
to the IPP Printers I control will be the same as those that I
receive from my IPP clients.
12. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I
want to support IPP Notification for each of the IPP Printer
objects that I implement. These devices all support IPP,
including IPP Notification. Because these IPP Printers MAY also
be controlled by other servers (using IPP or other protocols), I
only want job events for the jobs that I send, but I do want
Printer events all the time, so that I can show proper Printer
state to my clients. So I subscribe to these IPP Printers for
Printer events with a long-standing subscription, with myself as
the Notification Recipient. When I get a Job Creation request,
I decide to which IPP Printer to send the job. When I do so, I
also add a job subscription for Job events, with me as the
Notification Recipient to the job’s job subscriptions supplied
by my clients (this usage is called "piggybacking"). These IPP
Printers automatically remove their job subscriptions when the
job finishes, as for all job subscriptions, so that I no longer
get Job events when my jobs are completed.
4. Requirements
The following requirements are intended to be met by the IPP
Notification specification (not the implementation). The following
are true for the resulting IPP Notification Specification document:
1. It must indicate which of these requirements are REQUIRED and
which are OPTIONAL for a conforming implementation to support.
See [RFC2911], section 12.1, for the definition of these
important conformance terms.
2. It must be designed so that an IPP Printer can transparently
support the IPP Notification semantics by using third-party
notification services that exist today or that may be
standardized in the future.
3. It must define a means for a Job-Submitting End User to specify
zero or more Notification Recipients when submitting a print job.
A Submitter will not be able to prevent out-of-band subscriptions
from authorized persons, such as Operators.
4. It must define a means, when specifying a Notification Recipient,
for a Notification Subscriber to specify one or more notification
events for that Notification Recipient, subject to administrative
and security policy restrictions. Any of the following
constitute Job or Printer Events for which a Job Submitting End
User can specify that notifications be sent:
- Any standard Printer MIB alert
- Job Received (transition from Unknown to Pending)
- Job Started (transition from Pending to Processing)
- Page Complete (page is stacked)
- Collated Copy Complete (last sheet of collated copy is
stacked)
- Job Complete (transition from Processing or Processing-stopped
to Completed)
- Job Aborted (transition from Pending, Pending-held,
- Processing, or Processing-stopped to Aborted)
- Job Canceled (transition from Pending, Pending-held,
- Processing, or Processing-held to Canceled)
- Other job state changes, such as paused, purged