]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group T. Hastings, Ed. | |
8 | Request for Comments: 3997 Xerox Corporation | |
9 | Category: Informational R. K. deBry | |
10 | Utah Valley State College | |
11 | H. Lewis | |
12 | IBM Corporation | |
13 | March 2005 | |
14 | ||
15 | ||
16 | Internet Printing Protocol (IPP): | |
17 | Requirements for IPP Notifications | |
18 | ||
19 | Status of This Memo | |
20 | ||
21 | This memo provides information for the Internet community. It does | |
22 | not specify an Internet standard of any kind. Distribution of this | |
23 | memo is unlimited. | |
24 | ||
25 | Copyright Notice | |
26 | ||
27 | Copyright (C) The Internet Society (2005). | |
28 | ||
29 | Abstract | |
30 | ||
31 | This document is one of a set of documents that together describe all | |
32 | aspects of the Internet Printing Protocol (IPP). IPP is an | |
33 | application-level protocol that can be used for distributed printing | |
34 | on the Internet. There are multiple parts to IPP, but the primary | |
35 | architectural components are the Model, the Protocol, and an | |
36 | interface to Directory Services. This document provides a statement | |
37 | of the requirements for notifications as an optional part of an IPP | |
38 | Service. | |
39 | ||
40 | Table of Contents | |
41 | ||
42 | 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 | |
43 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |
44 | 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |
45 | 4. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10 | |
46 | 5. Security Considerations for IPP Notifications Requirements. . 12 | |
47 | 6. Internationalization Considerations . . . . . . . . . . . . . 13 | |
48 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |
49 | 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |
50 | 8.1. Normative References. . . . . . . . . . . . . . . . . . 14 | |
51 | 8.2. Informative References. . . . . . . . . . . . . . . . . 14 | |
52 | 9. Appendix A: Description of the Base IPP Documents . . . . . . 15 | |
53 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 | |
54 | Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17 | |
55 | ||
56 | ||
57 | ||
58 | Hastings, et al. Informational [Page 1] | |
59 | \f | |
60 | RFC 3997 IPP: Notification Requirements March 2005 | |
61 | ||
62 | ||
63 | 1. Introduction | |
64 | ||
65 | This document is one of a set of documents that together describe all | |
66 | aspects of the Internet Printing Protocol (IPP). IPP is an | |
67 | application level protocol that can be used for distributed printing | |
68 | on the Internet. There are multiple parts to IPP, but the primary | |
69 | architectural components are the Model, the Protocol, and an | |
70 | interface to Directory Services. This document provides a statement | |
71 | of the requirements for notifications as an optional part of an IPP | |
72 | Service. See section 10 for a description of the base IPP documents. | |
73 | ||
74 | The scope of this requirements document covers functionality used by | |
75 | the following kinds of IPP Users: End Users, Print Administrators, | |
76 | and Operators. See [RFC3995] for the extensions to the Internet | |
77 | Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911], | |
78 | [RFC2910], and future versions. | |
79 | ||
80 | 2. Terminology | |
81 | ||
82 | It is necessary to define a set of terms to be able to clearly | |
83 | express the requirements for notification services in an IPP System. | |
84 | ||
85 | 2.1. Job-Submitting End User | |
86 | ||
87 | A human end user who submits a print job to an IPP Printer. This | |
88 | person may or may not be within the same security domain as the | |
89 | Printer. This person may or may not be geographically near the | |
90 | printer. | |
91 | ||
92 | 2.2. Administrator | |
93 | ||
94 | A human user who established policy for and configures the print | |
95 | system. | |
96 | ||
97 | 2.3. Operator | |
98 | ||
99 | A human user who carries out the policy established by the | |
100 | Administrator and controls the day-to-day running of the print | |
101 | system. | |
102 | ||
103 | 2.4. Job-Submitting Application | |
104 | ||
105 | An application (for example, a batch application), acting on behalf | |
106 | of a Job Submitting End User, that submits a print job to an IPP | |
107 | Printer. The application may or may not be within the same security | |
108 | domain as the Printer. This application may or may not be | |
109 | geographically near the printer. | |
110 | ||
111 | ||
112 | ||
113 | ||
114 | Hastings, et al. Informational [Page 2] | |
115 | \f | |
116 | RFC 3997 IPP: Notification Requirements March 2005 | |
117 | ||
118 | ||
119 | 2.5. Security Domain | |
120 | ||
121 | For the purposes of this discussion, the set of network components | |
122 | that can communicate without going through a proxy or firewall. A | |
123 | security domain may be geographically very large; for example, | |
124 | anywhere within example.com. | |
125 | ||
126 | 2.6. IPP Client | |
127 | ||
128 | The software component that sends IPP requests to an IPP Printer | |
129 | object and accepts IPP responses from an IPP Printer. | |
130 | ||
131 | 2.7. Job Recipient | |
132 | ||
133 | A human who is the ultimate consumer of the print job. In many cases | |
134 | this will be the same person as the Job-Submitting End User, but this | |
135 | need not always be the case. For example, if I use IPP to print a | |
136 | document on a printer in a business partner's office, I am the Job- | |
137 | Submitting End User, and the person whom I intend the document for in | |
138 | my business partner's office is the Job Recipient. Since one of the | |
139 | goals of IPP is to be able to print near the Job Recipient, we would | |
140 | normally expect that person to be in the same security domain as, and | |
141 | geographically near, the Printer. However, this may not always be | |
142 | the case. For example, I submit a print job across the Internet to a | |
143 | XYZ's print shop. I am both the Submitting End User and the Job | |
144 | Recipient, but I am neither near nor in the same security domain as | |
145 | the Printer. | |
146 | ||
147 | 2.8. Job Recipient Proxy | |
148 | ||
149 | A person acting on behalf of the Job Recipient. The Job Recipient | |
150 | Proxy physically picks up the printed document from the Printer if | |
151 | the Job Recipient cannot do so. The Proxy is by definition | |
152 | geographically near and in the same security domain as the printer. | |
153 | For example, I submit a print job from home to be printed on a | |
154 | printer at work. I'd like my secretary to pick up the print job and | |
155 | put it on my desk. In this case, I am acting as both a Job- | |
156 | Submitting End User and a Job Recipient. My secretary is acting as a | |
157 | Job Recipient Proxy. | |
158 | ||
159 | 2.9. Notification Subscriber | |
160 | ||
161 | A client that requests the IPP Printer to send Event Notifications to | |
162 | one or more Notification Recipients. A Notification Subscriber may | |
163 | be a Job-Submitting End User or an End User, an Operator, or an | |
164 | Administrator that is not submitting a job. | |
165 | ||
166 | ||
167 | ||
168 | ||
169 | ||
170 | Hastings, et al. Informational [Page 3] | |
171 | \f | |
172 | RFC 3997 IPP: Notification Requirements March 2005 | |
173 | ||
174 | ||
175 | 2.10. Notification Source | |
176 | ||
177 | The entity that sends Event Notifications. | |
178 | ||
179 | 2.11. Notification Recipient | |
180 | ||
181 | The entity that receives IPP Notifications about Job and/or Printer | |
182 | events. A Notification Recipient may be a Job Submitting End User, a | |
183 | Job-Submitting Application, a Job Recipient, a Job Recipient Proxy, | |
184 | an Operator, an Administrator, etc., and his or her representative, | |
185 | log file, usage statistics-gathering application, or other active or | |
186 | passive entities. | |
187 | ||
188 | 2.12. Notification Recipient Agent | |
189 | ||
190 | A program that receives Event Notifications on behalf of the | |
191 | Notification Recipient. The agent may take some action on behalf of | |
192 | the recipient, forward the notification to the recipient via some | |
193 | alternative means (for example, page the recipient), or queue the | |
194 | notification for later retrieval by the recipient. | |
195 | ||
196 | 2.13. Event | |
197 | ||
198 | An Event is an occurrence (either expected or unexpected) within the | |
199 | printing system of a change of state, condition, or configuration of | |
200 | a Job or Printer object. | |
201 | ||
202 | 2.14. Event Notification | |
203 | ||
204 | When an event occurs, an Event Notification is generated that fully | |
205 | describes the event (what the event was, where it occurred, when it | |
206 | occurred, etc.). Event Notifications are delivered to all the | |
207 | Notification Recipients that are subscribed to that Event, if any. | |
208 | The Event Notification is delivered to the address of the | |
209 | Notification Recipient by using the notification delivery method | |
210 | defined in the subscription. However, an Event Notification is sent | |
211 | ONLY if there is a corresponding subscription. | |
212 | ||
213 | 2.15. Notification Subscription | |
214 | ||
215 | A Notification Subscription is a request by a Notification Subscriber | |
216 | to the IPP Printer to send Event Notifications to specified | |
217 | Notification Recipient(s) when an event occurs. | |
218 | ||
219 | ||
220 | ||
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Hastings, et al. Informational [Page 4] | |
227 | \f | |
228 | RFC 3997 IPP: Notification Requirements March 2005 | |
229 | ||
230 | ||
231 | 2.16. Notification Attributes | |
232 | ||
233 | IPP Objects (for example, a print job) from which notification are | |
234 | being sent may have associated attributes. A user may want to have | |
235 | one or more of these returned along with a particular notification. | |
236 | In general, these may include any attribute associated with the | |
237 | object emitting the notification. Examples include the following: | |
238 | ||
239 | number-of-intervening jobs | |
240 | job-k-octets | |
241 | job-k-octets processed | |
242 | job impressions | |
243 | job-impressions-interpreted | |
244 | job-impressions-completed | |
245 | impressionsCompletedCurrentCopy (job MIB) | |
246 | sheetCompletedCopyNumber (job MIB) | |
247 | sheetsCompletedDocumentNumber (job MIB) | |
248 | Copies-requested | |
249 | Copy-type | |
250 | Output-destination | |
251 | Job-state-reasons | |
252 | Job ID | |
253 | Printer URI | |
254 | Subscription ID (for job independent subscription) | |
255 | ||
256 | 2.17. Notification Delivery Method (or Delivery Method for Short) | |
257 | ||
258 | Event Notifications are delivered by using a Delivery Method. An | |
259 | example of a Delivery Method is email. | |
260 | ||
261 | 2.18. Immediate Notification | |
262 | ||
263 | Notifications sent to the Notification Recipient or the Notification | |
264 | Recipient's agent in such a way that the notification arrives | |
265 | immediately, within the limits of common addressing, routing, network | |
266 | congestion, and quality of service. | |
267 | ||
268 | 2.19. Store-and-Forward Notification | |
269 | ||
270 | Notifications that are not necessarily delivered to Notification | |
271 | Recipients immediately but are queued for delivery by an intermediate | |
272 | network application, for later retrieval. Email is an example of a | |
273 | store-and-forward notification delivery method. | |
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Hastings, et al. Informational [Page 5] | |
283 | \f | |
284 | RFC 3997 IPP: Notification Requirements March 2005 | |
285 | ||
286 | ||
287 | 2.20. Reliable Delivery of Notifications | |
288 | ||
289 | Notifications that are delivered by a reliable delivery of packets or | |
290 | character stream, with acknowledgement and retry, so that delivery of | |
291 | the notification is guaranteed within determinate time limits. For | |
292 | example, if the Notification Recipient has logged off and gone home | |
293 | for the day, an immediate notification cannot be guaranteed, even | |
294 | when sent over a reliable transport, because there is nothing there | |
295 | to catch it. Guaranteed delivery requires both store-and-forward | |
296 | notification and a reliable transport. | |
297 | ||
298 | 2.21. Notification over Unreliable Transport | |
299 | ||
300 | Notifications are delivered via the fundamental transport address and | |
301 | routing framework, but no acknowledgement or retry is required. | |
302 | Process-to-process communications, if involved, are unconstrained. | |
303 | ||
304 | 2.22. Human-Consumable Notification | |
305 | ||
306 | Notifications intended to be consumed by human end users only. Email | |
307 | would be an example of a Human-Consumable Notification, though it | |
308 | could also contain Machine-Consumable Notification. | |
309 | ||
310 | 2.23. Machine-Consumable Notification | |
311 | ||
312 | Notifications that are intended for consumption by a program only, | |
313 | such as an IPP Client. Machine-Consumable Notifications may not | |
314 | contain human-readable information. Do we need both human and | |
315 | machine? Machine readable is intended for application-to-application | |
316 | only. The Notification Recipient could process the machine-readable | |
317 | Event Notification into human-readable format. | |
318 | ||
319 | 2.24. Mixed Notification | |
320 | ||
321 | A mixed notification contains both Human-Consumable and Machine- | |
322 | Consumable information. | |
323 | ||
324 | 3. Scenarios | |
325 | ||
326 | 1. Sitting in my office, I submit a print job to the printer down | |
327 | the hall. I am in the same security domain as the printer and, | |
328 | of course, geographically near. I want to know immediately when | |
329 | my print job will be completed (or if there is a problem) | |
330 | because the document I am working on is urgent. I submit the | |
331 | print job with the following attributes: | |
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Hastings, et al. Informational [Page 6] | |
339 | \f | |
340 | RFC 3997 IPP: Notification Requirements March 2005 | |
341 | ||
342 | ||
343 | - Notification Recipient: Me | |
344 | - Notification Events: All | |
345 | - Notification Attributes: Job-state-reason | |
346 | - Notification Type: Immediate | |
347 | ||
348 | 2. Working from home, I submit a print job to the same printer as | |
349 | in the previous example. However, I am not at work, I cannot | |
350 | physically get the print file or do anything with it. It can | |
351 | wait until I get to work this afternoon. However, I'd like my | |
352 | secretary to pick up the output and put it on my desk so that it | |
353 | doesn't get lost or misfiled. I'd also like a store-and-forward | |
354 | notification sent to my email so that when I get to work I can | |
355 | tell whether there was a problem with the print job. I submit a | |
356 | print job with the following attributes: | |
357 | ||
358 | - Notification Recipient: My secretary | |
359 | - Notification Events: Print complete | |
360 | - Notification Type: Immediate | |
361 | ||
362 | - Notification Recipient: Me | |
363 | - Notification Events: Print complete | |
364 | - Notification Attributes: Impressions completed | |
365 | - Notification Type: Store and forward | |
366 | ||
367 | 3. Sitting in my office, I submit a print job to a client at an | |
368 | engineering firm my company works with on a daily basis. The | |
369 | engineering firm is in Belgium. I would like my client to know | |
370 | when the print job is complete so that she can pick it up from | |
371 | the printer in her building. It is important that she review it | |
372 | right away and send her comments back to me. I submit the print | |
373 | job with the following attributes: | |
374 | ||
375 | - Notification Recipient: Client at engineering firm | |
376 | - Notification Events: Print complete | |
377 | - Notification Type: Immediate | |
378 | - Notification Language: French | |
379 | ||
380 | 4. From a hotel room, I send a print job to a Kinko's store in the | |
381 | town I am working in, in order to get a printed report for the | |
382 | meeting I am attending in the morning. As I'm going out to | |
383 | dinner after I get this job submitted, an immediate notification | |
384 | won't do me much good. However, I'd like to check in the | |
385 | morning before I drive to the Kinko's store to see whether the | |
386 | file has been printed. An email notification is sufficient for | |
387 | this purpose. I submit the print job with the following | |
388 | attributes: | |
389 | ||
390 | ||
391 | ||
392 | ||
393 | ||
394 | Hastings, et al. Informational [Page 7] | |
395 | \f | |
396 | RFC 3997 IPP: Notification Requirements March 2005 | |
397 | ||
398 | ||
399 | - Notification Recipient: Me | |
400 | - Notification Events: Print complete | |
401 | - Notification Type: Store and forward | |
402 | ||
403 | 5. I am printing a large, complex print file. I want to have some | |
404 | immediate feedback on the progress of the print job as it | |
405 | prints. I submit the print job with the following attributes: | |
406 | ||
407 | - Notification Recipient: Me | |
408 | - Notification Type: Immediate | |
409 | - Notification Events: All state transitions | |
410 | - Notification Attributes: Impression completed | |
411 | ||
412 | 6. I am an operator and one of my duties is to keep the printer | |
413 | running. I subscribe independently from a job submission so | |
414 | that my subscription outlasts any particular job. I subscribe | |
415 | with the following attributes: | |
416 | ||
417 | - Notification Recipient: Me | |
418 | - Notification Type: Immediate | |
419 | - Notification Events: All Printer state transitions | |
420 | - Notification Attributes: Printer state, printer state | |
421 | reasons, device powering up, device powering down | |
422 | ||
423 | 7. I am a usage statistics gathering application. I subscribe | |
424 | independently from a job submission so that my subscription | |
425 | outlasts any particular job. My subscription may persist across | |
426 | power cycles. I subscribe with the following attributes: | |
427 | ||
428 | - Notification Recipient: Me | |
429 | - Notification Type: Immediate | |
430 | - Notification Events: Job completion | |
431 | - Notification Attributes: Impression completed, sheets | |
432 | completed, time submitted, time started, time completed, job | |
433 | owner, job size in octets, etc. | |
434 | ||
435 | 8. I am a client application program that displays a list of jobs | |
436 | currently queued for printing on a printer. I display the | |
437 | "job-name", "job-state", "job-state-reasons", "page-count", and | |
438 | "intervening-jobs", either for the user's jobs or for all jobs. | |
439 | The window displaying the job list remains open for an | |
440 | independent amount of time, and it is desired that it represent | |
441 | the current state of the queue. It is desired that the | |
442 | application only perform a slow poll in order to recover from | |
443 | any missed notifications. So the event delivery mechanism | |
444 | provides the means to update the screen on all needed changes, | |
445 | including querying for some attributes that may not be delivered | |
446 | in the Notification. | |
447 | ||
448 | ||
449 | ||
450 | Hastings, et al. Informational [Page 8] | |
451 | \f | |
452 | RFC 3997 IPP: Notification Requirements March 2005 | |
453 | ||
454 | ||
455 | 9. I am a client application program that displays a list of | |
456 | printers. For each Printer, I display the current state and | |
457 | configuration. The window displaying the printer list remains | |
458 | open for an independent amount of time, and it is desired that | |
459 | it represent the current state of each printer. It is desired | |
460 | that the application only need to perform a slow poll in order | |
461 | to recover from any missed notifications. So the event delivery | |
462 | mechanism provides the means to update the screen on all needed | |
463 | changes, including querying for some attributes that may not be | |
464 | delivered in the Notification. | |
465 | ||
466 | 10. I am an IPP Server that controls one or more devices and that | |
467 | implements an IPP Printer object to represent each device. I | |
468 | want to support IPP Notification for each of the IPP Printer | |
469 | objects that I implement. Many of these devices do not support | |
470 | notification (or IPP). So I need to support the IPP | |
471 | Notification semantics specified for each IPP Printer object | |
472 | myself on behalf of each of the devices that each of the IPP | |
473 | Printer objects represents. When I accept an IPP job creation | |
474 | requests, I convert it to what the device will accept. In some | |
475 | cases, I must poll the devices in order to be informed of their | |
476 | job and device state and state changes to be able to send IPP | |
477 | Notifications to subscribed Notification Recipients. | |
478 | ||
479 | 11. I am an IPP Server that controls one or more devices and that | |
480 | implements an IPP Printer object to represent each device. I | |
481 | want to support IPP Notification for each of the IPP Printer | |
482 | objects that I implement. These devices all support IPP, | |
483 | including IPP Notification. I would like the design choice for | |
484 | supporting IPP Notification for these objects either (1) by | |
485 | forwarding the notification to the IPP Printers that I, alone, | |
486 | control and have them send the notifications to the intended | |
487 | Notification Recipients without my involvement, or (2) by | |
488 | replacing the notification submitted with the Job to indicate me | |
489 | as the Notification Recipient; in turn I will forward | |
490 | Notifications to the Notification Recipients requested by my | |
491 | clients. Most of the rest of the contents of the IPP Job I send | |
492 | to the IPP Printers I control will be the same as those that I | |
493 | receive from my IPP clients. | |
494 | ||
495 | 12. I am an IPP Server that controls one or more devices and that | |
496 | implements an IPP Printer object to represent each device. I | |
497 | want to support IPP Notification for each of the IPP Printer | |
498 | objects that I implement. These devices all support IPP, | |
499 | including IPP Notification. Because these IPP Printers MAY also | |
500 | be controlled by other servers (using IPP or other protocols), I | |
501 | only want job events for the jobs that I send, but I do want | |
502 | Printer events all the time, so that I can show proper Printer | |
503 | ||
504 | ||
505 | ||
506 | Hastings, et al. Informational [Page 9] | |
507 | \f | |
508 | RFC 3997 IPP: Notification Requirements March 2005 | |
509 | ||
510 | ||
511 | state to my clients. So I subscribe to these IPP Printers for | |
512 | Printer events with a long-standing subscription, with myself as | |
513 | the Notification Recipient. When I get a Job Creation request, | |
514 | I decide to which IPP Printer to send the job. When I do so, I | |
515 | also add a job subscription for Job events, with me as the | |
516 | Notification Recipient to the job's job subscriptions supplied | |
517 | by my clients (this usage is called "piggybacking"). These IPP | |
518 | Printers automatically remove their job subscriptions when the | |
519 | job finishes, as for all job subscriptions, so that I no longer | |
520 | get Job events when my jobs are completed. | |
521 | ||
522 | 4. Requirements | |
523 | ||
524 | The following requirements are intended to be met by the IPP | |
525 | Notification specification (not the implementation). The following | |
526 | are true for the resulting IPP Notification Specification document: | |
527 | ||
528 | 1. It must indicate which of these requirements are REQUIRED and | |
529 | which are OPTIONAL for a conforming implementation to support. | |
530 | See [RFC2911], section 12.1, for the definition of these | |
531 | important conformance terms. | |
532 | ||
533 | 2. It must be designed so that an IPP Printer can transparently | |
534 | support the IPP Notification semantics by using third-party | |
535 | notification services that exist today or that may be | |
536 | standardized in the future. | |
537 | ||
538 | 3. It must define a means for a Job-Submitting End User to specify | |
539 | zero or more Notification Recipients when submitting a print job. | |
540 | A Submitter will not be able to prevent out-of-band subscriptions | |
541 | from authorized persons, such as Operators. | |
542 | ||
543 | 4. It must define a means, when specifying a Notification Recipient, | |
544 | for a Notification Subscriber to specify one or more notification | |
545 | events for that Notification Recipient, subject to administrative | |
546 | and security policy restrictions. Any of the following | |
547 | constitute Job or Printer Events for which a Job Submitting End | |
548 | User can specify that notifications be sent: | |
549 | ||
550 | - Any standard Printer MIB alert | |
551 | - Job Received (transition from Unknown to Pending) | |
552 | - Job Started (transition from Pending to Processing) | |
553 | - Page Complete (page is stacked) | |
554 | - Collated Copy Complete (last sheet of collated copy is | |
555 | stacked) | |
556 | ||
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Hastings, et al. Informational [Page 10] | |
563 | \f | |
564 | RFC 3997 IPP: Notification Requirements March 2005 | |
565 | ||
566 | ||
567 | - Job Complete (transition from Processing or Processing-stopped | |
568 | to Completed) | |
569 | - Job Aborted (transition from Pending, Pending-held, | |
570 | - Processing, or Processing-stopped to Aborted) | |
571 | - Job Canceled (transition from Pending, Pending-held, | |
572 | - Processing, or Processing-held to Canceled) | |
573 | - Other job state changes, such as paused, purged | |
574 | - Device problems for which the job is destined | |
575 | - Job (interpreter) issues | |
576 | ||
577 | 5. It must define how an End User or Operator subscribes for | |
578 | ||
579 | - any set of Job Events for a specific job, or | |
580 | - any set of Printer Events while a specific job is not | |
581 | complete. | |
582 | ||
583 | 6. It must define how an End User or Operator subscribes for the | |
584 | following without having to submit a Job: | |
585 | ||
586 | - Any set of Printer Events for a defined period. | |
587 | - Any set of Job Events for all jobs, with no control over | |
588 | which jobs. | |
589 | ||
590 | 7. It must define how the Notification Subscriber is able to | |
591 | specify either immediate or store-and-forward notification | |
592 | independently for each Notification Recipient. The means may be | |
593 | explicit, or implied by the method of delivery chosen by the Job | |
594 | Submitting End User. | |
595 | ||
596 | 8. It must define common delivery methods: e.g., email. | |
597 | ||
598 | 9. It must define how an IPP Printer validates its ability to | |
599 | deliver an Event by using the specified delivery scheme. If it | |
600 | does not support the specified scheme, or if the specified | |
601 | scheme is invalid for some reason, then the IPP Printer accepts | |
602 | and performs the request anyway and indicates the unsupported | |
603 | attribute values. There is no requirement for the IPP Printer | |
604 | receiving the print request to validate the identity of a | |
605 | Notification Recipient, or the ability of the system to deliver | |
606 | an event to that recipient as requested (for example, if the | |
607 | Notification Recipient is not at work today). | |
608 | ||
609 | 10. It must define a class of IPP event notification delivery | |
610 | methods that can flow through corporate firewalls. However, an | |
611 | IPP printer need not test to guarantee delivery of the | |
612 | notification through a firewall before accepting a print job. | |
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | Hastings, et al. Informational [Page 11] | |
619 | \f | |
620 | RFC 3997 IPP: Notification Requirements March 2005 | |
621 | ||
622 | ||
623 | 11. It may define a means to deliver a notification to the | |
624 | submitting client when the delivery of an event notification to | |
625 | a specified Notification Recipient fails. A fallback means of | |
626 | subscribers to determine whether notifications have failed | |
627 | (i.e., polling) may be provided. | |
628 | ||
629 | 12. It must define a mechanism for localizing Human-Consumable | |
630 | Notifications by the Notification Source. | |
631 | ||
632 | 13. It may define a way to specify whether event delivery requires | |
633 | acknowledgement back to the Notification Source. | |
634 | ||
635 | 14. There must be a mechanism defined so that job-independent | |
636 | subscriptions do not become stale and do not require human | |
637 | intervention to be removed. However, a subscription must not be | |
638 | deemed stale only if it is unable to deliver an Event | |
639 | Notification, as temporary Notification delivery problems must | |
640 | be tolerated. | |
641 | ||
642 | 15. A mechanism must be defined so that an Event Subscriber is able | |
643 | to add an Event Subscription to a Job after the Job has been | |
644 | submitted. | |
645 | ||
646 | 16. A mechanism must be defined so that a client is able to cancel | |
647 | an Event Subscription on a job or printer after the job has been | |
648 | submitted. | |
649 | ||
650 | 17. A mechanism must be defined so that a client can obtain the set | |
651 | of current Subscriptions. | |
652 | ||
653 | 5. Security Considerations for IPP Notifications Requirements | |
654 | ||
655 | By far the biggest security concern is the abuse of notification: | |
656 | sending unwanted notifications sent to third parties (i.e., spam). | |
657 | The problem is made worse by notification addresses that may be | |
658 | redistributed to multiple parties (e.g., mailing lists). Scenarios | |
659 | exist in which third-party notification is required (see scenarios 2 | |
660 | and 3). The fully secure solution would require active agreement of | |
661 | all recipients before anything is sent out. However, requirement 9 | |
662 | ("There is no requirement for an IPP Printer receiving the print | |
663 | request to validate the identity of an event recipient") argues | |
664 | against this. Certain systems may decide to disallow third-party | |
665 | notifications (a traditional fax model). | |
666 | ||
667 | The same security issues are present when Clients submit notification | |
668 | requests to the IPP Printer as when they submit an IPP/1.1 print job | |
669 | request. The same mechanisms used by IPP/1.1 can therefore be used | |
670 | ||
671 | ||
672 | ||
673 | ||
674 | Hastings, et al. Informational [Page 12] | |
675 | \f | |
676 | RFC 3997 IPP: Notification Requirements March 2005 | |
677 | ||
678 | ||
679 | by the client notification submission. Operations that require | |
680 | authentication can use the HTTP authentication. Operations that | |
681 | require privacy can use the HTTP/TLS privacy. | |
682 | ||
683 | The notification access control model should be similar to the IPP | |
684 | access control model. Creating a notification subscription is | |
685 | associated with a user. Only the creator or an operator can cancel | |
686 | the subscription. The system may limit the listing of items to items | |
687 | owned by the user. Some subscriptions (e.g., those that have a | |
688 | lifetime longer than a job) can be done only by privileged users | |
689 | (operators and/or administrators), if that is the authorization | |
690 | policy. | |
691 | ||
692 | The standard security concerns (delivery to the right user, privacy | |
693 | of content, tamper-proof content) apply to the notification delivery. | |
694 | IPP should use the security mechanism of the delivery method used. | |
695 | Some delivery mechanisms are more secure than others. Therefore, | |
696 | sensitive notifications should use the delivery method that has the | |
697 | strongest security. | |
698 | ||
699 | 6. Internationalization Considerations | |
700 | ||
701 | The Human-Consumable Notification must be localized to the natural | |
702 | language and charset that Notification Subscriber specifies within | |
703 | the choice of natural languages and charsets that the IPP Printer | |
704 | supports. | |
705 | ||
706 | The Machine-Consumable Notification data uses the "application/ipp" | |
707 | MIME media type. It contains attributes whose text values are | |
708 | required to be in the natural language and charset that the | |
709 | Notification Subscriber specifies within the choice of natural | |
710 | languages and charsets that the IPP Printer supports. See [RFC2566]. | |
711 | ||
712 | 7. IANA Considerations | |
713 | ||
714 | Some notification delivery methods have been registered with IANA for | |
715 | use in URLs. These will be defined in other documents. | |
716 | ||
717 | ||
718 | ||
719 | ||
720 | ||
721 | ||
722 | ||
723 | ||
724 | ||
725 | ||
726 | ||
727 | ||
728 | ||
729 | ||
730 | Hastings, et al. Informational [Page 13] | |
731 | \f | |
732 | RFC 3997 IPP: Notification Requirements March 2005 | |
733 | ||
734 | ||
735 | 8. References | |
736 | ||
737 | 8.1. Normative References | |
738 | ||
739 | [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J. | |
740 | Wenn, "Internet Printing Protocol/1.1: Encoding and | |
741 | Transport", RFC 2910, September 2000. | |
742 | ||
743 | [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and | |
744 | P. Powell, "Internet Printing Protocol/1.1: Model and | |
745 | Semantics", RFC 2911, September 2000. | |
746 | ||
747 | [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol | |
748 | (IPP): Event Notifications and Subscriptions", RFC 3995, | |
749 | March 2005. | |
750 | ||
751 | 8.2. Informative References | |
752 | ||
753 | [RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner, | |
754 | "Internet Printing Protocol/1.0: Encoding and Transport", | |
755 | RFC 2565, April 1999. | |
756 | ||
757 | [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and | |
758 | P. Powell, "Internet Printing Protocol/1.0: Model and | |
759 | Semantics", RFC 2566, April 1999. | |
760 | ||
761 | [RFC2567] Wright, F., "Design Goals for an Internet Printing | |
762 | Protocol", RFC 2567, April 1999. | |
763 | ||
764 | [RFC2568] Zilles, S., "Rationale for the Structure of the Model and | |
765 | Protocol for the Internet Printing Protocol", RFC 2568, | |
766 | April 1999. | |
767 | ||
768 | [RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin, | |
769 | "Mapping between LPD and IPP Protocols", RFC 2569, April | |
770 | 1999. | |
771 | ||
772 | [RFC2639] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. | |
773 | Holst, "Internet Printing Protocol/1.1: Implementor's | |
774 | Guide", RFC 3196, November 2001. | |
775 | ||
776 | ||
777 | ||
778 | ||
779 | ||
780 | ||
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | Hastings, et al. Informational [Page 14] | |
787 | \f | |
788 | RFC 3997 IPP: Notification Requirements March 2005 | |
789 | ||
790 | ||
791 | 9. Appendix A: Description of the Base IPP Documents | |
792 | ||
793 | The base set of IPP documents includes the following: | |
794 | ||
795 | Design Goals for an Internet Printing Protocol [RFC2567] | |
796 | Rationale for the Structure and Model and Protocol for the | |
797 | Internet Printing Protocol [RFC2568] | |
798 | Internet Printing Protocol/1.1: Model and Semantics [RFC2911] | |
799 | Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] | |
800 | Internet Printing Protocol/1.1: Implementer's Guide [RFC3196] | |
801 | Mapping between LPD and IPP Protocols [RFC2569] | |
802 | ||
803 | "Design Goals for an Internet Printing Protocol" takes a broad look | |
804 | at distributed printing functionality, and it enumerates real-life | |
805 | scenarios that help clarify the features that need to be included in | |
806 | a printing protocol for the Internet. It identifies requirements for | |
807 | three types of users: end users, operators, and administrators. It | |
808 | calls out a subset of end-user requirements that are satisfied in | |
809 | IPP/1.0 [RFC2566], [RFC2565]. A few OPTIONAL operator operations | |
810 | have been added to IPP/1.1 [RFC2911], [RFC2910]. | |
811 | ||
812 | "Rationale for the Structure and Model and Protocol for the Internet | |
813 | Printing Protocol" describes IPP from a high-level view, defines a | |
814 | roadmap for the various documents that form the suite of IPP | |
815 | specification documents, and gives background and rationale for the | |
816 | IETF IPP working group's major decisions. | |
817 | ||
818 | "Internet Printing Protocol/1.1: Model and Semantics" describes a | |
819 | simplified model with abstract objects, their attributes, and their | |
820 | operations. The model introduces a Printer and a Job. The Job | |
821 | supports multiple documents per Job. The model document also | |
822 | addresses security, internationalization, and directory issues. | |
823 | ||
824 | "Internet Printing Protocol/1.1: Encoding and Transport" is a formal | |
825 | mapping of the abstract operations and attributes defined in the | |
826 | model document onto HTTP/1.1 [RFC2616]. It also defines the encoding | |
827 | rules for a new Internet MIME media type called "application/ipp". | |
828 | This document also defines the rules for transporting over HTTP a | |
829 | message body whose Content-Type is "application/ipp". This document | |
830 | defines the "ipp" scheme for identifying IPP printers and jobs. | |
831 | ||
832 | "Internet Printing Protocol/1.1: Implementer's Guide" gives insight | |
833 | and advice to implementers of IPP clients and IPP objects. It is | |
834 | intended to help them understand IPP/1.1 and some of the | |
835 | considerations that may assist them in the design of their client | |
836 | and/or IPP object implementations. For example, a typical order of | |
837 | processing requests is given, including error checking. Motivation | |
838 | for some of the specification decisions is also included. | |
839 | ||
840 | ||
841 | ||
842 | Hastings, et al. Informational [Page 15] | |
843 | \f | |
844 | RFC 3997 IPP: Notification Requirements March 2005 | |
845 | ||
846 | ||
847 | "Mapping between LPD and IPP Protocols" gives some advice to | |
848 | implementers of gateways between IPP and LPD (Line Printer Daemon ) | |
849 | implementations. | |
850 | ||
851 | Authors' Addresses | |
852 | ||
853 | Tom Hastings (editor) | |
854 | Xerox Corporation | |
855 | 701 S Aviation Blvd, ESAE 242 | |
856 | El Segundo, CA 90245 | |
857 | ||
858 | Phone: 310-333-6413 | |
859 | Fax: 310-333-6342 | |
860 | EMail: hastings@cp10.es.xerox.com | |
861 | ||
862 | ||
863 | Roger deBry | |
864 | Utah Valley State College | |
865 | ||
866 | Phone: (801) 863-8848 | |
867 | EMail: debryro@uvsc.edu | |
868 | ||
869 | ||
870 | Harry Lewis | |
871 | IBM Corporation | |
872 | 6300 Diagonal Hwy | |
873 | Boulder, CO 80301 | |
874 | ||
875 | Phone: (303) 924-5337 | |
876 | EMail: harryl@us.ibm.com | |
877 | ||
878 | ||
879 | ||
880 | ||
881 | ||
882 | ||
883 | ||
884 | ||
885 | ||
886 | ||
887 | ||
888 | ||
889 | ||
890 | ||
891 | ||
892 | ||
893 | ||
894 | ||
895 | ||
896 | ||
897 | ||
898 | Hastings, et al. Informational [Page 16] | |
899 | \f | |
900 | RFC 3997 IPP: Notification Requirements March 2005 | |
901 | ||
902 | ||
903 | Full Copyright Statement | |
904 | ||
905 | Copyright (C) The Internet Society (2005). | |
906 | ||
907 | This document is subject to the rights, licenses and restrictions | |
908 | contained in BCP 78, and except as set forth therein, the authors | |
909 | retain all their rights. | |
910 | ||
911 | This document and the information contained herein are provided on an | |
912 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |
913 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |
914 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |
915 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
916 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
917 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
918 | ||
919 | Intellectual Property | |
920 | ||
921 | The IETF takes no position regarding the validity or scope of any | |
922 | Intellectual Property Rights or other rights that might be claimed to | |
923 | pertain to the implementation or use of the technology described in | |
924 | this document or the extent to which any license under such rights | |
925 | might or might not be available; nor does it represent that it has | |
926 | made any independent effort to identify any such rights. Information | |
927 | on the procedures with respect to rights in RFC documents can be | |
928 | found in BCP 78 and BCP 79. | |
929 | ||
930 | Copies of IPR disclosures made to the IETF Secretariat and any | |
931 | assurances of licenses to be made available, or the result of an | |
932 | attempt made to obtain a general license or permission for the use of | |
933 | such proprietary rights by implementers or users of this | |
934 | specification can be obtained from the IETF on-line IPR repository at | |
935 | http://www.ietf.org/ipr. | |
936 | ||
937 | The IETF invites any interested party to bring to its attention any | |
938 | copyrights, patents or patent applications, or other proprietary | |
939 | rights that may cover technology that may be required to implement | |
940 | this standard. Please address the information to the IETF at ietf- | |
941 | ipr@ietf.org. | |
942 | ||
943 | Acknowledgement | |
944 | ||
945 | Funding for the RFC Editor function is currently provided by the | |
946 | Internet Society. | |
947 | ||
948 | ||
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | Hastings, et al. Informational [Page 17] | |
955 | \f |