draft-ietf-ipp-not-02.txt   draft-ietf-ipp-not-03.txt 
INTERNET DRAFT Roger K deBry INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-02.txt> Utah Valley State College <draft-ietf-ipp-not-03.txt> Utah Valley State College
Harry Lewis Harry Lewis
IBM Corporation IBM Corporation
Tom Hastings Tom Hastings (editor)
Xerox Corporation Xerox Corporation
June 24, 1999 August 11, 1999
Internet Printing Protocol/1.1: Requirements for IPP Notifications Internet Printing Protocol/1.1: Requirements for IPP Notifications
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working provisions of Section 10 of [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
skipping to change at page 2, line 12 skipping to change at page 2, line 12
notifications as part of an IPP Service. Some ISSUES are indicated in notifications as part of an IPP Service. Some ISSUES are indicated in
the text. the text.
The full set of IPP documents include: The full set of IPP documents include:
Design Goals for an Internet Printing Protocol [RFC2567] Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568] Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC2566] Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] Internet Printing Protocol/1.0: Implementer's Guide [RFC 2639]
Mapping between LPD and IPP Protocols [RFC2569] Mapping between LPD and IPP Protocols [RFC2569]
The 'Design Goals for an Internet Printing Protocol' document takes a The 'Design Goals for an Internet Printing Protocol' document takes a
broad look at distributed printing functionality, and it enumerates broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that are administrators. It calls out a subset of end user requirements that are
satisfied in IPP/1.0. Operator and administrator requirements are out satisfied in IPP/1.0. Operator and administrator requirements are out
of scope for version 1.0. of scope for version 1.0.
skipping to change at page 2, line 51 skipping to change at page 2, line 51
specification decisions is also included. specification decisions is also included.
The 'Mapping between LPD and IPP Protocols' document gives some advice The 'Mapping between LPD and IPP Protocols' document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon) to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations. implementations.
Table of Contents Table of Contents
1 Scope..............................................................3 1 Scope..............................................................3
2 Terminology........................................................3 2 Terminology........................................................3
3 Requirements.......................................................7 3 Scenarios..........................................................6
4 Scenarios..........................................................8 4 Requirements.......................................................9
5 Security considerations for IPP Notifications requirements........11
6 Internationalization Considerations...............................12
7 IANA Considerations...............................................12
8 References........................................................12
9 Author's Address..................................................13
1 Scope 1 Scope
The scope of this requirements statement is for end users, print The scope of this requirements document covers functionality used by the
administrators and operators. following kinds of IPP Users: End Users, Print Administrators and
Operators.
2 Terminology 2 Terminology
It is necessary to define a set of terms in order to be able to clearly It is necessary to define a set of terms in order to be able to clearly
express the requirements for notification services in an IPP System. express the requirements for notification services in an IPP System.
2.1 Job Submitting End User 2.1 Job Submitting End User
A human end user who submits a print job to an IPP Printer. This person 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 may or may not be within the same security domain as the Printer. This
person may or may not be geographically near the printer. person may or may not be geographically near the printer.
2.2 Administrator 2.2 Administrator
A human user who established policy for and configures the print system A human user who established policy for and configures the print system.
2.3 Operator 2.3 Operator
A human user who carries out the policy established by the Administrator A human user who carries out the policy established by the Administrator
and controls the day to day running of the print system. and controls the day to day running of the print system.
2.4 Job Submitting Application 2.4 Job Submitting Application
An application (for example a batch application), acting on behalf of an An application (for example, a batch application), acting on behalf of a
end user, which submits a print job to an IPP Printer. The application Job Submitting End User, which submits a print job to an IPP Printer.
may or may not be within the same security domain as the Printer. This The application may or may not be within the same security domain as the
application may or may not be geographically near the printer. Printer. This application may or may not be geographically near the
printer.
2.5 Security Domain 2.5 Security Domain
For the purposes of this discussion, the set of network components which For the purposes of this discussion, the set of network components which
can communicate without going through a proxy or firewall. A security can communicate without going through a proxy or firewall. A security
domain may be geographically very large, for example - anyplace within domain may be geographically very large, for example - anyplace within
IBM.COM. IBM.COM.
2.6 IPP Client 2.6 IPP Client
The software component on the client system which implements the IPP The software component that sends IPP requests to an IPP Printer object
protocol. and accepts IPP responses from an IPP Printer.
2.7 Job Recipient 2.7 Job Recipient
A human who is the ultimate consumer of the print job. In many cases 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 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 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 document on a printer in a business partner's office, I am the Job
Submitting End User, while the person I intend the document for in my Submitting End User, while the person I intend the document for in my
business partner's office is the Job Recipient. Since one of the goals business partner's office is the Job Recipient. Since one of the goals
of IPP is to be able to print near the ultimate recipient of the printed
output, we would normally expect the Job Recipient to be in the same
security domain as, and geographically near the Printer. However, this of IPP is to be able to print near the Job Recipient of the printed
may not always be the case. For example, I submit a print job across the output, 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 Kinko's print shop. I am both the Submitting end User and Internet to a Kinko'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 the Job Recipient, but I am neither near nor in the same security domain
as the Printer. as the Printer.
2.8 Job Recipient Proxy 2.8 Job Recipient Proxy
A person acting on behalf of the Job Recipient. In particular, the Job A person acting on behalf of the Job Recipient. In particular, the Job
Recipient Proxy physically picks up the printed document from the Recipient Proxy physically picks up the printed document from the
Printer, if the Job Recipient cannot perform that function. The Proxy is Printer, if the Job Recipient cannot perform that function. The Proxy is
by definition geographically near and in the same security domain as the 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. 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 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 Job Submitting End it on my desk. In this case, I am acting as both Job Submitting End
User and Job Recipient. My secretary is acting as a Job Recipient Proxy. User and Job Recipient. My secretary is acting as a Job Recipient Proxy.
2.9 Notification Subscriber 2.9 Notification Subscriber
A client that requests the IPP Printer to send event reports to one or A client that requests the IPP Printer to send Event Notifications to
more Notification Recipients. A Notification Subscriber may be a Job one or more Notification Recipients. A Notification Subscriber may be a
Submitting End User or an End User, an Operator, or an Administrator Job Submitting End User or an End User, an Operator, or an Administrator
that is not submitting a job. that is not submitting a job.
2.10 Notification Source 2.10 Notification Source
The entity that sends notification events The entity that sends Event Notifications.
2.11 Notification Recipient 2.11 Notification Recipient
Any of: Job Submitting End User, Job Submitting Application, Job The entity that receives IPP Notifications about Job and/or Printer
Recipient, or Job Recipient Proxy or admin etc folks and their events. A Notification Recipient may be a: Job Submitting End User, Job
representatives or log file or accounting/audit application or other Submitting Application, Job Recipient, Job Recipient Proxy, Operator, or
active or passive entities or President Clinton. Or Monica. Administrator, etc., and their representatives or log file or usage
statistics gathering application or other active or passive entities.
2.12 Notification Recipient Agent 2.12 Notification Recipient Agent
A program which receives events on behalf of the notification recipient. A program which receives Event Notifications on behalf of the
The agent may take some action on behalf of the recipient, forward the Notification Recipient. The agent may take some action on behalf of the
notification to the recipient via some alternative means (for example, recipient, forward the notification to the recipient via some
page the recipient), or queue the notification for later retrieval by alternative means (for example, page the recipient), or queue the
the recipient. notification for later retrieval by the recipient.
2.13 Event 2.13 Event
A event is some occurrence (either expected or unexpected) within the A Event is some occurrence (either expected or unexpected) within the
printing system. Any of the following constitute events that a Job printing system of a change of state, condition, or configuration of a
Submitting End User can specify notifications be sent for: Job or Printer object.
@ Any standard Printer MIB alert (i.e. device alerts) (critical and
warning?) (state change notifications)?
@ 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 like 'paused', purged?
@ Device problems on which the job is destine for
@ Job (interpreter) issues
2.14 Event report 2.14 Event Notification
When an event occurs, an event report is generated that fully describes When an event occurs, an Event Notification is generated that fully
the event (what the event was, where it occurred, when it occurred, describes the event (what the event was, where it occurred, when it
etc.). Event reports are delivered to all the notification recipients occurred, etc.). Event Notifications are delivered to all the
that are subscribed to that event, if any. The event report is Notification Recipients that are subscribed to that Event, if any. The
delivered to the address of the notification recipient using the Event Notification is delivered to the address of the Notification
notification delivery method defined in the subscription. However, an Recipient using the notification delivery method defined in the
Event Report is sent ONLY if there is a corresponding subscription. subscription. However, an Event Notification is sent ONLY if there is a
corresponding subscription.
2.15 Notification Subscription 2.15 Notification Subscription
It should be possible for end users and operators to 'subscribe' for A Notification Subscription is a request by a Notification Subscriber to
notifications of certain types of events, independent of Job Submission. the IPP Printer to send Event Notifications to specified Notification
An end user or operator may subscribe for Recipient(s) when the event occur.
@ All Job Traps
@ All Traps (Job and Printer)
@ None (Reserves a slot in some limited stable of 'notification hosts')
ISSUE: Need to discuss granularity and categorization in the context of
anticipated event frequency
2.16 Notification Attributes 2.16 Notification Attributes
IPP Objects (for example, a print job) from which notification are being IPP Objects (for example, a print job) from which notification are being
sent may have attributes associated with them. A user may want to have sent may have attributes associated with them. A user may want to have
one or more of these associated attributes returned along with a one or more of these associated attributes returned along with a
particular notification. In general, these may include any attribute particular notification. In general, these may include any attribute
associated with the object emitting the notification. Examples include: associated with the object emitting the notification. Examples include:
number-of-intervening jobs number-of-intervening jobs
skipping to change at page 6, line 10 skipping to change at page 5, line 47
Copies-requested Copies-requested
Copy-type Copy-type
Output-destination Output-destination
Job-state-reasons Job-state-reasons
Job ID Job ID
Printer URI Printer URI
Subscription ID (for job independent subscription) Subscription ID (for job independent subscription)
2.17 Notification Delivery Method (or Delivery Method for short) 2.17 Notification Delivery Method (or Delivery Method for short)
Event reports are delivered using a method, such as email, TCP/IP, etc. Event Notifications are delivered using a method, such as email, TCP/IP,
etc.
2.18 Immediate Notification 2.18 Immediate Notification
Notifications sent to the notification recipient or the notification Notifications sent to the Notification Recipient or the Notification
recipient's agent in such a way that the notification arrives Recipient's agent in such a way that the notification arrives
immediately , within the limits of common addressing, routing, network immediately , within the limits of common addressing, routing, network
congestion and quality of service. congestion and quality of service.
2.19 Queued Notification 2.19 Store and Forward Notification
Notifications which are not necessarily sent immediately, but are queued Notifications which are not necessarily delivered to Notification
for delivery by some intermediate network application, or for later Recipients immediately, but are queued for delivery by some intermediate
retrieval. Email with store and forward is an example of queued network application, for later retrieval. Email is an example of a store
notification. and forward notification delivery method.
2.20 Notification over Reliable Transport 2.20 Reliable Delivery of Notifications
Notifications which are delivered by a reliable, sequenced delivery of Notifications which are delivered by a reliable delivery of packets or
packets or character stream, with acknowledgment and retry, such that character stream, with acknowledgment and retry, such that delivery of
delivery of the notification is guaranteed within some reasonable time the notification is guaranteed within some determinate time limits. For
limits. For example, if the notification recipient has logged off and example, if the Notification Recipient has logged off and gone home for
gone home for the day, an immediate notification cannot be guaranteed to the day, an immediate notification cannot be guaranteed to be delivered,
be delivered, even when sent over a reliable transport, because there is even when sent over a reliable transport, because there is nothing there
nothing there to catch it. Guaranteed delivery requires both queued to catch it. Guaranteed delivery requires both store and forward
notification and a reliable transport. If delivery of the notification notification and a reliable transport.
requires process to process communications, each session is managed in a
reliable manner, assuring fully ordered, end-to-end delivery.
2.21 Notification over Unreliable Transport 2.21 Notification over Unreliable Transport
Notifications are delivered via the fundamental transport address and Notifications are delivered via the fundamental transport address and
routing framework, but no acknowledgment or retry is required. Process routing framework, but no acknowledgment or retry is required. Process
to process communications, if involved, are unconstrained. to process communications, if involved, are unconstrained.
2.22 Human Consumable Notification 2.22 Human Consumable Notification
Notifications which are intended to be consumed by human end users only. Notifications which are intended to be consumed by human end users only.
They contain no machine readable encoding of the event. Email would be Email would be an example of a Human consumable notification, though it
an example of a Human consumable notification. could also contain Machine Consumable Notification.
ISSUE: Do we need both human and machine or is machine sufficient?
There is no intent to attempt to standardize human readable strings.
Human readable is intended for certain protocols, like e-mail, though
email can also convey machine readable MIME types as well using
multipart/report.
ISSUE: Is e-mail the only, or most likely, means of conveying the
notification through the firewall (which would drive a requirement for
mixed text, binary content).
2.23 Machine Consumable Notification 2.23 Machine Consumable Notification
Notifications which are intended for consumption by a program only, such Notifications which are intended for consumption by a program only, such
as an IPP Client. Machine Consumable notifications may not contain human as an IPP Client. Machine Consumable notifications may not contain human
readable information. Do we need both human and machine? Machine readable information. Do we need both human and machine? Machine
readable is intended for application to application only. The readable is intended for application to application only. The
Notification Recipient could process the machine readable report into Notification Recipient could process the machine readable Event
human readable format. Notification into human readable format.
2.24 Mixed Notification 2.24 Mixed Notification
A mixed notification may contain both human readable and human readable A mixed notification contains both Human Consumable and Machine
information. Consumable information.
ISSUE: Do we need mixed?
Mail Services, DNS, Instant Messaging, Distributions lists etc.?
3 Requirements
The following requirements are intended to be met by the IPP
Notification specification.
1.The specification must indicate which of these requirements are
MANDATORY and which are OPTIONAL for a conforming implementation.
2.It must be possible to support the IPP Notification interface using
third party notification services that exist today or that may be
standardized in the future.
3.A Job Submitting End User must be able to specify zero or more
notification recipients when submitting a print job. But don't expect
a submitter to be able to circumvent out of band subscriptions.
4.When specifying a notification recipient, a Notification Subscriber
must be able to specify one or more notification events for that
notification recipient.
5.When specifying a notification recipient, the Notification Subscriber
must be able to specify either immediate or queued notification for
that notification recipient. This may be explicit, or implied by the
method of delivery chosen by the Job Submitting End User.
6.When specifying a notification event, a Notification Subscriber must
be able to specify that zero or more notification attributes (or
attribute categories) be sent along with the notification, when that
event occurs.
7.Common delivery methods, e.g. email, must be supported.
8.There is no requirement for the IPP Printer receiving the print
request to validate the identity of an event recipient, nor the
ability of the system to deliver an event to that recipient as
requested (for example, if the event recipient is not at work today).
9.However, an IPP Printer must validate its ability to deliver an event
using the specified delivery scheme. If it does not support the
specified scheme, or the specified scheme is invalid for some reason,
then it should respond to the print request with an error condition.
10. There must be a class of IPP event notification schemes or methods
which can flow through corporate firewalls. However, an IPP printer
need not test to guarantee delivery of the notification through a
firewall before accepting a print job.
11. A mechanism must be provided for delivering a notification to the
submitting client when the delivery of an event notification to a
specified Notification Recipient fails. (Optional? Or not necessary?)
Fall back means of subscribers determining if notifications have
failed. I.e. polling?
12. There must be a mechanism for localizing human consumable
notifications by the Notification Source.
13. There must be a way to specify whether or not event delivery
requires acknowledgement back to the Event Source.
14. There must be a mechanism to indicate the quality of service for
delivery of event reports. The policy must include stopping the
Printer and allowing the Printer to continue, when delivery of the
event report is not acknowledged. ISSUE: Should that policy be
specified by the Notification Subscriber (and authorized by the
Printer) or by the administrator in configuring the Printer?
15. There must be a mechanism so that job independent subscriptions do
not become stale and do not require human intervention to remove
stale subscriptions. However, stale must not be the inability to
deliver a notification report, since temporary event delivery
problems must be tolerated.
4 Scenarios 3 Scenarios
1.I am sitting in my office and submit a print job to the printer down 1.I am sitting in my office and submit a print job to the printer down
the hall. I am in the same security domain as the printer and of the hall. I am in the same security domain as the printer and of
course, geographically near. I want to know immediately when my course, geographically near. I want to know immediately when my
print job will be completed (or if there is a problem) because the 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 document I am working on is urgent. I submit the print job with the
following attributes: following attributes:
@ Notification Recipient - me @ Notification Recipient - me
@ Notification Events - all @ Notification Events - all
@ Notification Attributes - job-state-reason @ Notification Attributes - job-state-reason
@ Notification Type - immediate @ Notification Type - immediate
2.I am working from home and submit a print job to the same printer as 2.I am working from home and submit a print job to the same printer as
in the previous example. However, since I am not at work, I cannot in the previous example. However, since I am not at work, I cannot
physically get the print file or do anything with it. It can wait 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 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 it doesn't get lost or pick up the output and put it on my desk so it doesn't get lost or
miss-filed. I'd also like a queued notification sent to my email so miss-filed. I'd also like a store and forward notification sent to my
that when I get to work I can tell if there was a problem with the email so that when I get to work I can tell if there was a problem
print job. I submit a print job with the following attributes: with the print job. I submit a print job with the following
attributes:
@ Notification Recipient - my secretary @ Notification Recipient - my secretary
@ Notification Events - print complete @ Notification Events - print complete
@ Notification Type - immediate @ Notification Type - immediate
@ Notification Recipient - me @ Notification Recipient - me
@ Notification Events - print complete @ Notification Events - print complete
@ Notification Attributes - impressions completed @ Notification Attributes - impressions completed
@ Notification Type - queued @ Notification Type - store and forward
3.I am sitting in my office and submit a print job to a client at an 3.I am sitting in my office and submit a print job to a client at an
engineering firm we work with on a daily basis. The engineering form engineering firm we work with on a daily basis. The engineering firm
is in Belgium. I would like my client to know when the print job is 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 complete, so that she can pick it up from the printer in her
building. It is important that she review it right away and get her building. It is important that she review it right away and get her
comments back to me. I submit the print job with the following comments back to me. I submit the print job with the following
attributes: attributes:
@ Notification Recipient - client at engineering firm @ Notification Recipient - client at engineering firm
@ Notification Events - print complete @ Notification Events - print complete
@ Notification Type - immediate @ Notification Type - immediate
@ Notification Language - French @ Notification Language - French
skipping to change at page 9, line 47 skipping to change at page 7, line 50
town I am working in, in order to get a printed report for the town I am working in, in order to get a printed report for the
meeting I am attending in the morning. Since I'm going out to dinner meeting I am attending in the morning. Since I'm going out to dinner
after I get this job submitted, an immediate notification won't do me 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 much good. However, I'd like to check in the morning before I drive
to the Kinko's store to see if the file has been printed. An email to the Kinko's store to see if the file has been printed. An email
notification is sufficient for this purpose. I submit the print job notification is sufficient for this purpose. I submit the print job
with the following attributes: with the following attributes:
@ Notification Recipient - me @ Notification Recipient - me
@ Notification Events - print complete @ Notification Events - print complete
@ Notification Type - email @ Notification Type - store and forward
5.I am printing a large, complex print file. I want to have some 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 immediate feedback on the progress of the print job as it prints. I
submit the print job with the following attributes: submit the print job with the following attributes:
@ Notification Recipient - me @ Notification Recipient - me
@ Notification Type - immediate @ Notification Type - immediate
@ Notification Events - all state transitions @ Notification Events - all state transitions
@ Notification Attributes - impression completed @ Notification Attributes - impression completed
skipping to change at page 10, line 16 skipping to change at page 8, line 18
subscribe independently from a job submission so that my subscription subscribe independently from a job submission so that my subscription
outlasts any particular job. I subscribe with the following outlasts any particular job. I subscribe with the following
attributes: attributes:
@ Notification Recipient - me @ Notification Recipient - me
@ Notification Type - immediate @ Notification Type - immediate
@ Notification Events - all Printer state transitions @ Notification Events - all Printer state transitions
@ Notification Attributes - Printer state, printer state reasons, @ Notification Attributes - Printer state, printer state reasons,
device powering up, device powering down. device powering up, device powering down.
7.I am an accounting or audit application. I subscribe independently 7.I am a usage statistics gathering application. I subscribe
from a job submission so that my subscription outlasts any particular independently from a job submission so that my subscription outlasts
job. My subscription may persists across power cycles. I subscribe any particular job. My subscription may persists across power
with the following attributes: cycles. I subscribe with the following attributes:
@ Notification Recipient - me @ Notification Recipient - me
@ Notification Type - immediate @ Notification Type - immediate
@ Notification Events - job completion @ Notification Events - job completion
@ Notification Attributes - impression completed, sheets completed, @ Notification Attributes - impression completed, sheets completed,
time submitted, time started, time completed, job owner, job size time submitted, time started, time completed, job owner, job size
in octets, etc. 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 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.
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 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 represent. When I accept IPP
job creation requests, I convert the request 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 in order to
be able to send IPP Notifications to subscribed Notification
Recipients.
11. I am an IPP Server that controls one or more devices and 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 IPP Printer objects that I implement 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) replace the
notification submitted with the Job to indicate me as the
Notification Recipient and I will in turn forward Notifications to
the Notification Recipients requested by my clients. Most of the
rest of the contents of the IPP Job that I send to the IPP Printers
that I control will be the same as the IPP Job that I receive from my
IPP clients.
12. I am an IPP Server that controls one or more devices and 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 being
controlled by other servers (using IPP or other protocols), I only
want job events for the jobs that I send, but 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 to 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 "piggy-
backing"). These IPP Printers automatically remove their job
subscriptions when the job completes 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 resulting IPP
Notification Specification document:
1.must indicate which of these requirements are REQUIRED and which are
OPTIONAL for a conforming implementation to support.
2.must be designed to that an IPP Printer can transparently support
the IPP Notification semantics using third party notification
services that exist today or that may be standardized in the future.
3.must define 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.must define means when specifying a Notification Recipient, for a
Notification Subscriber to be able 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 that a Job Submitting End
User can specify notifications be sent for:
@ Any standard Printer MIB alert (i.e. device alerts) (critical
and warning?) (state change notifications)?
@ 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 like 'paused', purged?
@ Device problems for which the job is destined
@ Job (interpreter) issues
5.must define how an End User or Operator subscribes for:
@ Any set of Job Events for a specific job.
@ Any set of Printer Events while a specific job is not complete.
6.must define how an End User or Operator subscribes for the following
without having to submit a Job:
@ Any set of Printer Events for a defined period.
@ Any set of Job Events for all jobs with no control over which
jobs.
ISSUE - Ok if there isn't a way for an End-User to submit an empty Per-
Printer Subscription, in case such a Subscription slot is a scarce
commodity, and then enable the Per-Printer Subscription when the data
arrives and disable later without deleting the subscription?
7.must define how the Notification Subscriber is able to specify either
immediate or store and forward notification independently for each
Notification Recipient. The means may be explicit, or implied by the
method of delivery chosen by the Job Submitting End User.
8.must define common delivery methods, e.g. email, must be defined.
9.must define how an IPP Printer validates its ability to deliver an
Event using the specified delivery scheme. If it does not support
the specified scheme, or the specified scheme is invalid for some
reason, then the IPP Printer accepts and performs the request anyway
and responds indicating the unsupported attribute values. There is
no requirement for the IPP Printer receiving the print request to
validate the identity of an Notification Recipient, nor the ability
of the system to deliver an event to that recipient as requested (for
example, if the Notification Recipient is not at work today).
10. must define a class of IPP event notification delivery methods
which can flow through corporate firewalls. However, an IPP printer
need not test to guarantee delivery of the notification through a
firewall before accepting a print job.
11. may define means for delivering a notification to the submitting
client when the delivery of an event notification to a specified
Notification Recipient fails. Fall back means of subscribers
determining if notifications have failed, i.e. polling, may be
provided.
12. must define a mechanism for localizing Human Consumable
notifications by the Notification Source.
13. may define a way to specify whether or not event delivery requires
acknowledgement back to the Notification Source.
ISSUE - Ok if spec doesn't have means for a Notification Recipient
acknowledging receipt of a notification to the Notification Source?
14. There must be a mechanism defined so that job independent
subscriptions do not become stale and do not require human
intervention to remove stale subscriptions. However, stale must not
be the inability to deliver an Event Notification , since temporary
Notification delivery problems must be tolerated.
15. A mechanism must be defined so that an Event Subscriber is able to
add an Event Subscription to a Job after the Job has been submitted.
16. A mechanism must be defined so that a client is able to cancel an
Event Subscription on a job or printer after the job has been
submitted.
17. A mechanism must be defined so that a client can obtain the set of
current Subscriptions.
5 Security considerations for IPP Notifications requirements
By far the biggest security concern is the abuse of notification:
sending unwanted notifications to third parties (i.e., spam). The
problem is made worse by notification addresses that may be
redistributed to multiple parties (e.g. mailing lists). There exist
scenarios where third party notification is required (see Scenario #2
and #3). The fully secure solution would require active agreement of
all recipients before sending out anything. However, requirement #9
(.There is no requirement for IPP Printer receiving the print request to
validate the identity of an event recipient.) argues against this.
Certain systems may decide to disallow third party notifications (a
traditional fax model).
Clients submitting notification requests to the IPP Printer has the same
security issues as submitting an IPP/1.1 print job request. The same
mechanisms used by IPP/1.1 can therefore be used by the client
notification submission. Operations that require authentication can use
the HTTP authentication. Operations that require privacy can use the
HTTP/TLS privacy.
The notification access control model should be similar to the IPP
access control model. Creating a notification subscription is
associated with a user. Only the creator or an operator can cancel the
subscription. The system may limit the listing of items to only those
items owned by the user. Some subscriptions (e.g. those that have a
lifetime longer than a job) can be done only by privileged users
(operators and/or administrators), if that is the authorization policy.
The standard security concerns (delivery to the right user, privacy of
content, tamper proof content) apply to the notification delivery. IPP
should use the security mechanism of the delivery method used. Some
delivery mechanisms are more secure than others. Therefore, sensitive
notifications should use the delivery method that has the strongest
security.
6 Internationalization Considerations
The Human Consumable notification must be localized to the natural
language and charset that Notification Subscriber specifies within the
choice of natural languages and charsets that the IPP Printer supports.
The Machine Consumable notification data uses the 'application/ipp' MIME
media type. It contains some attributes whose text values are required
to be in the natural language and charset that the Notification
Subscriber specifies within the choice of natural languages and charsets
that the IPP Printer supports. See [RFC2566].
7 IANA Considerations
There will be some notification delivery methods registered with IANA
for use in URLs.
8 References
[ipp-mod]
deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
"Internet Printing Protocol/1.1: Model and Semantics", < draft-
ietf-ipp-model-v11-04.txt>, work in progress, June 23, 1999.
[RFC2565]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2566]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April 1999.
[RFC2567]
Wright, D., "Design Goals for an Internet Printing Protocol",
draft-ietf-ipp-req-03.txt, November, 1998.
[RFC2568]
Zilles, S., "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", draft-ietf-ipp-rat-04.txt,
November, 1998.
[RFC2569]
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-05.txt, November
1998.
[RFC2639]
T. Hastings, C. Manros. "Internet Printing Protocol/1.0:
Implementer's Guide", RFC 2639, July 1999.
9 Author's Address
Harry Lewis
HUC/003G
IBM Corporation
P.O. Box 1900
Boulder, CO 80301-9191
Phone: (303) 924-5337
Fax: (303) 924-9889
e-mail: harryl@us.ibm.com
Roger deBry
Utah Valley State College
Orem, UT 84058
Phone: (801) 222-8000
e-mail: debryro@uvsc.edu
Tom Hastings (editor)
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/