draft-ietf-ipp-not-00.txt   draft-ietf-ipp-not-01.txt 
INTERNET DRAFT Roger K deBry INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-00.txt> IBM Corporation <draft-ietf-ipp-not-01.txt> Utah Valley State College
February 19, 1998 Harry Lewis
1 Requirements for IPP Notifications IBM Corporation
2 Tom Hastings
3 Xerox Corporation
4 June 24, 1999
5 STATUS OF THIS MEMO
6
7 This document is an Internet-Draft. Internet-Drafts are working
8 documents of the Internet Engineering Task Force (IETF), its areas,
9 and its working groups. Note that other groups may also distribute
10 working documents as Internet-Drafts.
11
12 Internet-Drafts are draft documents alid for a maximum of six months
13 and may be updated, replaced, or obsoleted by other documents at any
14 time. It is inappropriate to use Internet-Drafts as reference
15 material or to cite them other than as "work in progress."
16
17 To learn the current status of any Internet-Draft, please check the
18 ''1id-abstracts.txt'' listing contained in the Internet- Drafts
19 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
20 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
21 ftp.isi.edu (US West Coast).
22
23 ABSTRACT
24
25 This document is one of a set of documents which together describe
26 all aspects of a new Internet Printing Protocol (IPP). IPP is an
27 application leel protocol that can be used for distributed printing
28 on the Internet. There are multiple parts to IPP, but the primary
29 architectural components are the Model, the Protocol and an interface
30 to Directory Serices. This document proides a statement of the
31 requirements for notifications as part of an IPP Serice. The full
32 set of IPP documents include:
33
34 Requirements for an Internet Printing Protocol
35 Internet Printing Protocol/1.0: Model and Semantics
36 Internet Printing Protocol/1.0: Protocol Specification
37 Rationale for the Structure of the Model and Protocol
38 for the Internet Printing Protocol
39
Expires August 19, 1998 [Page 1] Internet Printing Protocol/1.1: Requirements for IPP Notifications
Copyright (C) The Internet Society (1999). All Rights Reserved.
INTERNET DRAFT Roger K deBry STATUS OF THIS MEMO
<draft-ietf-ipp-not-00.txt> IBM Corporation
February 19, 1998
40 1.0 Scope
41
42 The scope of this requirements statement is for end users. This
43 document does not address requirements specific to print
44 administrators or operators. Howeer, we fully expect the
45 notification mechanisms defined in support of the requirements set
46 forth in this document to be extendible to print administrators and
47 operators as well. This document describes the requirements for
48 notifications for client-serer, serer-printer, and client-printer
49 connections
50
51 2.0 Terminology
52
53 It is necessary to define a set of terms in order to be able to
54 clearly express the requirements for notification serices in an IPP
55 System.
56
57 2.1 Job Submitting End User
58
59 A human end user who submits a print job to an IPP Printer. This
60 person may or may not be within the same security domain as the
61 Printer. This person may or may not be geographically near the
62 printer.
63
64 2.2 Job Submitting Application
65
66 An application (for example a batch application), acting on behalf of
67 an end user, which submits a print job to an IPP Printer. The
68 application may or may not be within the same security domain as the
69 Printer. This application may or may not be geographically near the
70 printer.
71
72 2.3 Security Domain
73
74 For the purposes of this discussion, the set of network components
75 which can communicate without going through a proxy or firewall. A
76 security domain may be geographically ery large, for example -
77 anyplace within IBM.COM.
78
79 2.4 IPP Client
80
81 The software component on the client system which implements the IPP
82 protocol.
83
84 2.5 Job Recipient
85
86 A human who is the ultimate consumer of the print job. In many cases
87 this will be the same person as the Job Submitting End User, but this
88 need not always be the case. For example, if I use IPP to print a
89 document on a printer in a business partner's office, I am the Job
90 Submitting End User, while the person I intend the document for in my
Expires August 19, 1998 Page [2] 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 DRAFT Roger K deBry Internet-Drafts are draft documents valid for a maximum of six months
<draft-ietf-ipp-not-00.txt> IBM Corporation and may be updated, replaced, or obsoleted by other documents at any
February 19, 1998 time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ''work in progress.''
91 business partner's office is the Job Recipient. Since one of the The list of current Internet-Drafts can be accessed at
92 goals of IPP is to be able to print near the ultimate recipient of http://www.ietf.org/ietf/1id-abstracts.txt
93 the printed output, we would normally expect the Job Recipient to be
94 in the same security domain as, and geographically near the Printer.
95 Howeer, this may not always be the case. For example, I submit a
96 print job across the Internet to a Kinkoís print shop. I am both the
97 Submitting end User and the Job Recipient, but I am neither near nor
98 in the same security domain as the Printer.
99
100 2.6 Job Recipient Proxy
101
102 A person acting on behalf of the Job Recipient. In particular, the
103 Job Recipient Proxy physically picks up the printed document from the
104 Printer, if the Job Recipient cannot perform that function. The Proxy
105 is by definition geographically near and in the same security domain
106 as the printer. For example, I submit a print job from home to be
107 printed on a printer at work. Iíd like my secretary to pick up the
108 print job and put it on my desk. In this case, I am acting as both
109 Job Submitting End User and Job Recipient. My secretary is acting as
110 a Job Recipient Proxy. An issue that needs to be considered in the
111 notification architecture is the impact of a third party receiing
112 many unwanted notifications.
113
114 2.7 Notification Recipient
115
116 Any of: Job Submitting End User, Job Submitting Application, Job
117 Recipient, or Job Recipient Proxy.
118
119 2.8 Notification Recipient Agent
120
121 A program which receies eents on behalf of the notification
122 recipient. The agent may take some action on behalf of the recipient,
123 forward the notification to the recipient ia some alternatie means
124 (for example, page the recipient), or queue the notification for
125 later retrieal by the recipient.
126
127 2.9 Notification Eents
128
129 Any of the following constitute eents that a Job Submitting End User
130 can specify notifications be sent for. Notifications are sent to an
131 end user only for that end userís job, or for eents that affect the
132 processing of that end user's job.
133
134 - Any standard Printer MIB alert (i.e. deice eents that impact the
135 end user's job)
136 - Job Receied (transition from Unknown to Pending or Pending-held)
137 - Job Started (Transition from Pending to Processing)
138 - Page Complete (Page is stacked)
139 - Collated Copy Complete (last sheet of collated copy is stacked)
140 - Job Complete (transition from Processing or Processing-stopped to
141 Completed)
Expires August 19, 1998 [Page 3] The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html.
INTERNET DRAFT Roger K deBry ABSTRACT
<draft-ietf-ipp-not-00.txt> IBM Corporation
February 19, 1998
142 - Job aborted (transition from Pending, Pending-held, Processing, This document is one of a set of documents which together describe all
143 or Processing-stopped to Aborted) aspects of a new Internet Printing Protocol (IPP). IPP is an application
144 - Job canceled (transition from Pending, Pending-held, Processing, level protocol that can be used for distributed printing on the
145 or Processing-held to Canceled) Internet. There are multiple parts to IPP, but the primary architectural
146 components are the Model, the Protocol and an interface to Directory
147 2.10 Notification Registration Services. This document provides a statement of the requirements for
148 notifications as part of an IPP Service. Some ISSUES are indicated in
149 It should be possible for end users to Register for notifications the text.
150 of certain types of eents. These include any of those described in
151 the preceding section.
152
153 2.11 Notification Attributes
154
155 IPP Objects (for example, a print job) from which notification are
156 being sent may hae attributes associated with them. A user may want
157 to hae one or more of these associated attributes returned along
158 with a particular notification. In general, these may include any
159 attribute associated with the object emitting the notification.
160 Examples include:
161
162 number-of-interening jobs
163 job-k-octets
164 job-k-octets processed
165 job impressions
166 job-impressions-interpreted
167 job-impressions-completed
168 impressionsCompletedCurrentCopy (job MIB)
169 sheetCompletedCopyNumber (job MIB)
170 sheetsCompletedDocumentNumber (job MIB)
171 Copies-requested
172 Copy-type
173 Output-destination
174 Job-state-reasons
175
176
177 2.12 Immediate Notification
178
179 Notifications sent to the notification recipient or the notification
180 recipientís agent in such a way that the notification arries
181 immediately , within the limits of common addressing, routing,
182 network congestion and quality of serice.
183
184 2.13 Queued Notification
185
186 Notifications which are not necessarily sent immediately, but are
187 queued for deliery by some intermediate network application, or for
188 later retrieal. Email with store and forward is an example of queued
189 notification.
190
191 2.14 Notification with Reliable Deliery
192
Expires August 19, 1998 [Page 4] The full set of IPP documents include:
INTERNET DRAFT Roger K deBry Design Goals for an Internet Printing Protocol [RFC2567]
<draft-ietf-ipp-not-00.txt> IBM Corporation Rationale for the Structure and Model and Protocol for the Internet
February 19, 1998 Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
193 Notifications which are deliered by a reliable, sequenced deliery The 'Design Goals for an Internet Printing Protocol' document takes a
194 of packets or character stream, with acknowledgment and retry, such broad look at distributed printing functionality, and it enumerates
195 that deliery of the notification is guaranteed within some real-life scenarios that help to clarify the features that need to be
196 reasonable time limits. For example, if the notification recipient included in a printing protocol for the Internet. It identifies
197 has logged off and gone home for the day, an immediate notification requirements for three types of users: end users, operators, and
198 cannot be guaranteed to be deliered, een when sent over a reliable administrators. It calls out a subset of end user requirements that are
199 transport, because there is nothing there to catch it. Guaranteed satisfied in IPP/1.0. Operator and administrator requirements are out
200 deliery requires both queued notification and a reliable transport. of scope for version 1.0.
201 If deliery of the notification requires process to process
202 communications, each session is managed in a reliable manner,
203 assuring fully ordered, end-to-end deliery.
204
205 2.15 Notification with Unreliable Deliery
206
207 Notifications are deliered ia the fundamental transport address and
208 routing framework, but no acknowledgment or retry is required.
209 Process to process communications, if inoled, are unconstrained.
210
211 2.16 Human Consumable Notification
212
213 Notifications which are intended to be consumed by human end users
214 only. They contain no machine readable encodings of the eent. Email
215 would be an example of a Human consumable notification.
216
217 2.17 Machine Consumable Notification
218
219 Notifications which are intended for consumption by a program only,
220 such as an IPP Client. Machine Consumable notifications may not
221 contain human readable information.
222
223 2.18 Mixed Notification
224
225 A mixed notification may contain both human readable and human
226 readable information.
227
228 3.0 Requirements
229
230 3.1 A Job Submitting End User must be able to specify zero or more
231 notification recipients when submitting a print job.
232
233 3.2 When specifying a notification recipient, a Job Submitting End
234 user must be able to specify one or more notification eents for
235 that notification recipient.
236
237 3.3 When specifying a notification recipient, the Job Submitting End
238 User must be able to specify either immediate or queued
239 notification for that notification recipient. This may be
240 explicit, or implied by the method of deliery chosen by the Job
241 Submitting End User.
242
Expires August 19, 1998 [Page 5] 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.
INTERNET DRAFT Roger K deBry The 'Internet Printing Protocol/1.0: Encoding and Transport' document is
<draft-ietf-ipp-not-00.txt> IBM Corporation a formal mapping of the abstract operations and attributes defined in
February 19, 1998 the model document onto HTTP/1.1. It defines the encoding rules for a
new Internet media type called 'application/ipp'.
243 3.4 When specifying a notification eent, a Job Submitting End User The 'Internet Printing Protocol/1.0: Implementer's Guide' document gives
244 must be able to specify that zero or more notification attributes insight and advice to implementers of IPP clients and IPP objects. It
245 be sent along with the notification, when that eent occurs. is intended to help them understand IPP/1.0 and some of the
246 considerations that may assist them in the design of their client and/or
247 3.5 Common deliery methods should be utilized where they are IPP object implementations. For example, a typical order of processing
248 appropriate and meet the requirements expressed in this document. requests is given, including error checking. Motivation for some of the
249 specification decisions is also included.
250 3.6 There is no requirement for the IPP Printer receiing the print
251 request to alidate the identity of an eent recipient, nor the
252 ability of the system to delier an eent to that recipient as
253 requested (for example, if the eent recipient is not at work
254 today).
255
256 3.7 Howeer, an IPP Printer must alidate its ability to deliver an
257 eent using the specified deliery scheme. If it does not support
258 the specified scheme, or the specified scheme is inalid for some
259 reason, then it should respond to the print request with an error
260 condition.
261
262 3.8 There must be a class of IPP eent notifications which can flow
263 through corporate firewalls. Howeer, an IPP printer need not test
264 to guarantee deliery of the notification through a firewall
265 before accepting a print job.
266
267 3.9 A mechanism must be proided for deliering a notification to the
268 submitting client when the deliery of an eent notification to a
269 specified Notification Recipient fails.
270
271 3.10 There must be a mechanism for localizing human consumable
272 notifications.
273
274 4.0 Scenarios
275
276 4.1 I am sitting in my office and submit a print job to the printer
277 down the hall. I am in the same security domain as the printer and
278 of course, geographically near. I want to know immediately when
279 my print job will be completed (or if there is a problem) because
280 the document I am working on is urgent. I submit the print job
281 with the following attributes:
282
283 - Notification Recipient - me
284 - Notification Eents - all
285 - Notification Attributes - job-state-reason
286 - Notification Type - immediate
287
288 4.2 I am working from home and submit a print job to the same printer
289 as in the preious example. Howeer, since I am not at work, I
290 cannot physically get the print file or do anything with it. It
291 can wait until I get to work this afternoon. Howeer, I'd like my
292 secretary to pick up the output and put it on my desk so it
293 doesn't get lost or mis-filed. I'd also like a queued notification
Expires August 19, 1998 [Page 6] The 'Mapping between LPD and IPP Protocols' document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
INTERNET DRAFT Roger K deBry Table of Contents
<draft-ietf-ipp-not-00.txt> IBM Corporation
February 19, 1998
294 sent to my email so that when I get to work I can tell if there 1 Scope..............................................................3
295 was a problem with the print job. I submit a print job with the 2 Terminology........................................................3
296 following attributes: 3 Requirements.......................................................7
297 4 Scenarios..........................................................8
298 - Notification Recipient - my secretary
299 - Notification Eents - print complete
300 - Notification Type - immediate
301
302 - Notification Recipient - me
303 - Notification Eents - print complete
304 - Notification Attributes - impressions completed
305 - Notification Type - queued
306
307 4.3 I am sitting in my office and submit a print job to a client at
308 an engineering firm we work with on a daily basis. The engineering
309 form is in Belgium. I would like my client to know when the print
310 job is complete, so that she can pick it up from the printer in
311 her building. It is important that she reiew it right away and
312 get her comments back to me. I submit the print job with the
313 following attributes:
314
315 - Notification Recipient - client at engineering firm
316 - Notification Eents - print complete
317 - Notification Type - immediate
318 - Notification Language - French
319
320 4.4 I am in a hotel room and send a print job to a Kinkoís store in
321 the town I am working in, in order to get a printed report for the
322 meeting I am attending in the morning. Since I'm going out to
323 dinner after I get this job submitted, an immediate notification
324 wonít do me much good. Howeer, Iíd like to check in the morning
325 before I drie to the Kinkoís store to see if the file has been
326 printed. An email notification is sufficient for this purpose. I
327 submit the print job with the following attributes:
328
329 - Notification Recipient - me
330 - Notification Eents - print complete
331 - Notification Type - email
332
333 4.5 I am printing a large, complex print file. I want to hae some
334 immediate feedback on the progress of the print job as it prints.
335 I submit the print job with the following attributes:
336
337 - Notification Recipient - me
338 - Notification Type - immediate
339 - Notification Eents - all state transitions
340 - Notification Attributes - impression completed
341
Expires August 19, 1998 [Page 7] 1 Scope
INTERNET DRAFT Roger K deBry The scope of this requirements statement is for end users, print
<draft-ietf-ipp-not-00.txt> IBM Corporation administrators and operators.
February 19, 1998
5.0 Author's Address 2 Terminology
Roger K deBry It is necessary to define a set of terms in order to be able to clearly
IBM Corporation express the requirements for notification services in an IPP System.
003G
P.O. Box 1900
Boulder, CO 80301-9191
email rdebry@us.ibm.com
Expires August 19, 1998 [Page 8] 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 an
end user, which 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 which
can communicate without going through a proxy or firewall. A security
domain may be geographically very large, for example - anyplace within
IBM.COM.
2.6 IPP Client
The software component on the client system which implements the IPP
protocol.
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, while the person 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 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
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
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. In particular, the Job
Recipient Proxy physically picks up the printed document from the
Printer, if the Job Recipient cannot perform that function. 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 Job Submitting End
User and 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 reports 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 notification events
2.11 Notification Recipient
Any of: Job Submitting End User, Job Submitting Application, Job
Recipient, or Job Recipient Proxy or admin etc folks and their
representatives or log file or accounting/audit application or other
active or passive entities or President Clinton. Or Monica.
2.12 Notification Recipient Agent
A program which receives events 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
A event is some occurrence (either expected or unexpected) within the
printing system. Any of the following constitute 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 on which the job is destine for
@ Job (interpreter) issues
2.14 Event report
When an event occurs, an event report is generated that fully describes
the event (what the event was, where it occurred, when it occurred,
etc.). Event reports are delivered to all the notification recipients
that are subscribed to that event, if any. The event report is
delivered to the address of the notification recipient using the
notification delivery method defined in the subscription. However, an
Event Report is sent ONLY if there is a corresponding subscription.
2.15 Notification Subscription
It should be possible for end users and operators to 'subscribe' for
notifications of certain types of events, independent of Job Submission.
An end user or operator may subscribe for
@ 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
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
one or more of these associated attributes returned along with a
particular notification. In general, these may include any attribute
associated with the object emitting the notification. Examples include:
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 reports are delivered using a method, such as email, TCP/IP, etc.
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 Queued Notification
Notifications which are not necessarily sent immediately, but are queued
for delivery by some intermediate network application, or for later
retrieval. Email with store and forward is an example of queued
notification.
2.20 Notification over Reliable Transport
Notifications which are delivered by a reliable, sequenced delivery of
packets or character stream, with acknowledgment and retry, such that
delivery of the notification is guaranteed within some reasonable time
limits. For example, if the notification recipient has logged off and
gone home for the day, an immediate notification cannot be guaranteed to
be delivered, even when sent over a reliable transport, because there is
nothing there to catch it. Guaranteed delivery requires both queued
notification and a reliable transport. If delivery of the notification
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
Notifications are delivered via the fundamental transport address and
routing framework, but no acknowledgment or retry is required. Process
to process communications, if involved, are unconstrained.
2.22 Human Consumable Notification
Notifications which are intended to be consumed by human end users only.
They contain no machine readable encoding of the event. Email would be
an example of a Human 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
Notifications which 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 report into
human readable format.
2.24 Mixed Notification
A mixed notification may contain both human readable and human readable
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
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
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.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
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 it doesn't get lost or
miss-filed. I'd also like a queued notification sent to my email so
that when I get to work I can tell if 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 - queued
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
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 get 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.I am in a hotel room and 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. Since 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 if 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 - email
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 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 an accounting or audit application. I subscribe independently
from a job submission so that my subscription outlasts any particular
job. My subscription may persists 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.
 End of changes. 

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