One document matched: draft-ietf-ipp-not-01.txt
Differences from draft-ietf-ipp-not-00.txt
INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-01.txt> IBM Corporation
March 11, 1998
1 Requirements for IPP Notifications
2
3
4
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
9 areas, and its working groups. Note that other groups may also
10 distribute working documents as Internet-Drafts.
11
12 Internet-Drafts are draft documents valid for a maximum of six
13 months and may be updated, replaced, or obsoleted by other
14 documents at any time. It is inappropriate to use Internet-
15 Drafts as reference material or to cite them other than as
16 "work in progress."
17
18 To learn the current status of any Internet-Draft, please check
19 the "1id-abstracts.txt" listing contained in the Internet-
20 Drafts Shadow Directories on ftp.is.co.za (Africa),
21 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
22 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
23
24 ABSTRACT
25
26 This document is one of a set of documents which together
27 describe all aspects of a new Internet Printing Protocol (IPP).
28 IPP is an application level protocol that can be used for
29 distributed printing on the Internet. There are multiple parts
30 to IPP, but the primary architectural components are the Model,
31 the Protocol and an interface to Directory Services. This
32 document provides a statement of the requirements for
33 notifications as part of an IPP Service. The full set of IPP
34 documents include:
35
36 Requirements for an Internet Printing Protocol
37 Internet Printing Protocol/1.0: Model and Semantics
38 Internet Printing Protocol/1.0: Protocol Specification
39 Rationale for the Structure of the Model and Protocol
40 for the Internet Printing Protocol
41
Expires September 11, 1998
[Page 1]
INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-01.txt> IBM Corporation
March 11, 1998
42 1.0 Scope
43
44 The scope of this requirements statement is for end users. This
45 document does not address requirements specific to print
46 administrators or operators. However, we fully expect the
47 notification mechanisms defined in support of the requirements
48 set forth in this document to be extendible to print
49 administrators and operators as well. This document describes
50 the requirements for notifications for client-server, server-
51 printer, and client-printer connections
52
53 2.0 Terminology
54
55 It is necessary to define a set of terms in order to be able to
56 clearly express the requirements for notification services in an
57 IPP System.
58
59 2.1 Job Submitting End User
60
61 A human end user who submits a print job to an IPP Printer. This
62 person may or may not be within the same security domain as the
63 Printer. This person may or may not be geographically near the
64 printer.
65
66 2.2 Job Submitting Application
67
68 An application (for example a batch application), acting on
69 behalf of an end user, which submits a print job to an IPP
70 Printer. The application may or may not be within the same
71 security domain as the Printer. This application may or may not
72 be geographically near the printer.
73
74 2.3 Security Domain
75
76 For the purposes of this discussion, the set of network
77 components which can communicate without going through a proxy
78 or firewall. A security domain may be geographically very large,
79 for example - anyplace within IBM.COM.
80
81 2.4 IPP Client
82
83 The software component on the client system which implements the
84 IPP protocol.
85
86 2.5 Job Recipient
87
88 A human who is the ultimate consumer of the print job. In many
89 cases this will be the same person as the Job Submitting End
Expires September 11, 1998
[Page 2]
INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-01.txt> IBM Corporation
March 11, 1998
90 User, but this need not always be the case. For example, if I
91 use IPP to print a document on a printer in a business partner's
92 office, I am the Job Submitting End User, while the person I
93 intend the document for in my business partner’s office is the
94 Job Recipient. Since one of the goals of IPP is to be able to
95 print near the ultimate recipient of the printed output, we
96 would normally expect the Job Recipient to be in the same
97 security domain as, and geographically near the Printer.
98 However, this may not always be the case. For example, I submit
99 a print job across the Internet to a Kinko's print shop. I am
100 both the Submitting end User and the Job Recipient, but I am
101 neither near nor in the same security domain as the Printer.
102
103 2.6 Job Recipient Proxy
104
105 A person acting on behalf of the Job Recipient. In particular,
106 the Job Recipient Proxy physically picks up the printed document
107 from the Printer, if the Job Recipient cannot perform that
108 function. The Proxy is by definition geographically near and in
109 the same security domain as the printer. For example, I submit a
110 print job from home to be printed on a printer at work. I'd like
111 my secretary to pick up the print job and put it on my desk. In
112 this case, I am acting as both Job Submitting End User and Job
113 Recipient. My secretary is acting as a Job Recipient Proxy. An
114 issue that needs to be considered in the notification
115 architecture is the impact of a third party receiving many
116 unwanted notifications.
117
118 2.7 Notification Recipient
119
120 Any of: Job Submitting End User, Job Submitting Application, Job
121 Recipient, or Job Recipient Proxy.
122
123 2.8 Notification Recipient Agent
124
125 A program which receives events on behalf of the notification
126 recipient. The agent may take some action on behalf of the
127 recipient, forward the notification to the recipient via some
128 alternative means (for example, page the recipient), or queue
129 the notification for later retrieval by the recipient.
130
131 2.9 Notification Events
132
133 Any of the following constitute events that a Job Submitting End
134 User can specify notifications be sent for. Notifications are
135 sent to an end user only for that end user's job, or for events
136 that affect the processing of that end user's job.
137
Expires September 11, 1998
[Page 3]
INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-01.txt> IBM Corporation
March 11, 1998
138 - Any standard Printer MIB alert (i.e. device events that
139 impact the end user's job)
140 - Job Received (transition from Unknown to Pending or Pending-
141 held)
142 - Job Started (Transition from Pending to Processing)
143 - Page Complete (Page is stacked)
144 - Collated Copy Complete (last sheet of collated copy is
145 stacked)
146 - Job Complete (transition from Processing or Processing-
147 stopped to Completed)
148 - Job aborted (transition from Pending, Pending-held,
149 Processing, or Processing-stopped to Aborted)
150 - Job canceled (transition from Pending, Pending-held,
151 Processing, or Processing-held to Canceled)
152 - The job has not ended (Completed, Aborted, Canceled, etc.)
153 within a specified time limit.
154
155 2.10 Notification Registration
156
157 It should be possible for end users to "Register" for
158 notifications of certain types of events. These include any of
159 those described in the preceding section.
160
161 2.11 Notification Attributes
162
163 IPP Objects (for example, a print job) from which notification
164 are being sent may have attributes associated with them. A user
165 may want to have one or more of these associated attributes
166 returned along with a particular notification. In general, these
167 may include any attribute associated with the object emitting
168 the notification. Examples include:
169
170 number-of-intervening jobs
171 job-k-octets
172 job-k-octets processed
173 job impressions
174 job-impressions-interpreted
175 job-impressions-completed
176 impressionsCompletedCurrentCopy (job MIB)
177 sheetCompletedCopyNumber (job MIB)
178 sheetsCompletedDocumentNumber (job MIB)
179 Copies-requested
180 Copy-type
181 Output-destination
182 Job-state-reasons
183
184
185 2.12 Immediate Notification
Expires September 11, 1998
[Page 4]
INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-01.txt> IBM Corporation
March 11, 1998
186
187 Notifications sent to the notification recipient or the
188 notification recipient's agent in such a way that the
189 notification arrives immediately , within the limits of common
190 addressing, routing, network congestion and quality of service.
191
192 2.13 Queued Notification
193
194 Notifications which are not necessarily sent immediately, but
195 are queued for delivery by some intermediate network
196 application, or for later retrieval. Email with store and
197 forward is an example of queued notification.
198
199 2.14 Notification with Reliable Delivery
200
201 Notifications which are delivered by a reliable, sequenced
202 delivery of packets or character stream, with acknowledgment and
203 retry, such that delivery of the notification is guaranteed
204 within some reasonable time limits. For example, if the
205 notification recipient has logged off and gone home for the day,
206 an immediate notification cannot be guaranteed to be delivered,
207 even when sent over a reliable transport, because there is
208 nothing there to catch it. Guaranteed delivery requires both
209 queued notification and a reliable transport. If delivery of the
210 notification requires process to process communications, each
211 session is managed in a reliable manner, assuring fully ordered,
212 end-to-end delivery.
213
214 2.15 Notification with Unreliable Delivery
215
216 Notifications are delivered via the fundamental transport
217 address and routing framework, but no acknowledgment or retry is
218 required. Process to process communications, if involved, are
219 unconstrained.
220
221 2.16 Quality of Service
222
223 Some notification delivery methods may allow users to select
224 quality of service parameters. These will depend upon the
225 specific delivery method chosen, and may include parameters such
226 as priority, security, number of retries, and the like.
227
228 2.17 Human Consumable Notification
229
230 Notifications which are intended to be consumed by human end
231 users only. They contain no machine readable encodings of the
232 event. Email would be an example of a Human consumable
233 notification.
Expires September 11, 1998
[Page 5]
INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-01.txt> IBM Corporation
March 11, 1998
234
235 2.18 Machine Consumable Notification
236
237 Notifications which are intended for consumption by a program
238 only, such as an IPP Client. Machine Consumable notifications
239 may not contain human readable information.
240
241 2.19 Mixed Notification
242
243 A mixed notification may contain both human readable and human
244 readable information.
245
246 3.0 Requirements
247
248 3.1 A Job Submitting End User must be able to specify zero or
249 more notification recipients when submitting a print job.
250
251 3.2 When specifying a notification recipient, a Job Submitting
252 End user must be able to specify one or more notification
253 events for that notification recipient.
254
255 3.3 When specifying a notification recipient, the Job Submitting
256 End User must be able to specify a notification delivery
257 method and any associated quality of service parameters for
258 that notification recipient. The method may be explicit, or
259 implied by characteristics of the method, such as queued,
260 immediate, reliable, etc.
261
262 3.4 When specifying a notification event, a Job Submitting End
263 User must be able to specify that zero or more notification
264 attributes be sent along with the notification, when that
265 event occurs.
266
267 3.5 Common delivery methods should be utilized where they are
268 appropriate and meet the requirements expressed in this
269 document.
270
271 3.6 There is no requirement for the IPP Printer receiving the
272 print request to validate the identity of an event recipient,
273 nor the ability of the system to deliver an event to that
274 recipient as requested (for example, if the event recipient
275 is not at work today).
276
277 3.7 However, an IPP Printer must validate its ability to deliver
278 an event using the specified delivery scheme. If it does not
279 support the specified scheme, or the specified scheme is
280 invalid for some reason, then it should respond to the print
281 request with an error condition.
Expires September 11, 1998
[Page 6]
INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-01.txt> IBM Corporation
March 11, 1998
282
283 3.8 There must be a class of IPP event notifications which can
284 flow through corporate firewalls. However, an IPP printer
285 need not test to guarantee delivery of the notification
286 through a firewall before accepting a print job.
287
288 3.9 A mechanism must be provided for delivering a notification
289 to the submitting client when the delivery of an event
290 notification to a specified Notification Recipient fails.
291
292 3.10 There must be a mechanism for localizing human consumable
293 notifications.
294
295 4.0 Scenarios
296
297 4.1 I am sitting in my office and submit a print job to the
298 printer down the hall. I am in the same security domain as
299 the printer and of course, geographically near. I want to
300 know immediately when my print job will be completed (or if
301 there is a problem) because the document I am working on is
302 urgent. I submit the print job with the following attributes:
303
304 - Notification Recipient - me
305 - Notification Events - all
306 - Notification Attributes - job-state-reason
307 - Notification Type - immediate
308
309 4.2 I am working from home and submit a print job to the same
310 printer as in the previous example. However, since I am not
311 at work, I cannot physically get the print file or do
312 anything with it. It can wait until I get to work this
313 afternoon. However, I'd like my secretary to pick up the
314 output and put it on my desk so it doesn't get lost or mis-
315 filed. I'd also like a queued notification sent to my email
316 so that when I get to work I can tell if there was a problem
317 with the print job. I submit a print job with the following
318 attributes:
319
320 - Notification Recipient - my secretary
321 - Notification Events - print complete
322 - Notification Type - immediate
323
324 - Notification Recipient - me
325 - Notification Events - print complete
326 - Notification Attributes - impressions completed
327 - Notification Type - queued
328
Expires September 11, 1998
[Page 7]
INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-01.txt> IBM Corporation
March 11, 1998
329 4.3 I am sitting in my office and submit a print job to a client
330 at an engineering firm we work with on a daily basis. The
331 engineering form is in Belgium. I would like my client to
332 know when the print job is complete, so that she can pick it
333 up from the printer in her building. It is important that
334 she review it right away and get her comments back to me. I
335 submit the print job with the following attributes:
336
337 - Notification Recipient - client at engineering firm
338 - Notification Events - print complete
339 - Notification Type - immediate
340 - Notification Language - French
341
342 4.4 I am in a hotel room and send a print job to a Kinko's store
343 in the town I am working in, in order to get a printed report
344 for the meeting I am attending in the morning. Since I'm
345 going out to dinner after I get this job submitted, an
346 immediate notification won't do me much good. However, I'd
347 like to check in the morning before I drive to the Kinko's
348 store to see if the file has been printed. An email
349 notification is sufficient for this purpose. I submit the
350 print job with the following attributes:
351
352 - Notification Recipient - me
353 - Notification Events - print complete
354 - Notification Type - email
355
356 4.5 I am printing a large, complex print file. I want to have
357 some immediate feedback on the progress of the print job as
358 it prints. I submit the print job with the following
359 attributes:
360
361 - Notification Recipient - me
362 - Notification Type - immediate
363 - Notification Events - all state transitions
364 - Notification Attributes - impression completed
365
Expires September 11, 1998
[Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 18:15:56 |