idnits 2.17.1 draft-ietf-ipp-not-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 434: '...e these IPP Printers MAY also be being...' RFC 2119 keyword, line 454: '...se requirements are REQUIRED and which...' RFC 2119 keyword, line 455: '... are OPTIONAL for a conforming imp...' RFC 2119 keyword, line 697: '... are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 459 has weird spacing: '...arently suppo...' == Unrecognized Status in '[Target Category: Informational]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 21, 2004) is 7246 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 19, but not defined == Missing Reference: 'IPP-IIG' is mentioned on line 688, but not defined == Missing Reference: 'RFC2616' is mentioned on line 713, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Unused Reference: 'RFC2639' is defined on line 649, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) -- Obsolete informational reference (is this intentional?): RFC 2565 (Obsoleted by RFC 2910) -- Obsolete informational reference (is this intentional?): RFC 2566 (Obsoleted by RFC 2911) -- Obsolete informational reference (is this intentional?): RFC 2639 (Obsoleted by RFC 3196) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Printing Protocol WG Tom Hastings (editor) 2 INTERNET DRAFT Xerox Corporation 3 Roger K deBry 4 [Target Category: Informational] Utah Valley State College 5 Expires: December 21, 2004 Harry Lewis 6 IBM Corporation 7 June 21, 2004 9 Internet Printing Protocol (IPP): Requirements for IPP Notifications 10 Copyright (C) The Internet Society (2001). All Rights Reserved. 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ''work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed as 29 http://www.ietf.org/shadow.html. 31 ABSTRACT 33 This document is one of a set of documents which together describe 34 all aspects of a new Internet Printing Protocol (IPP). IPP is an 35 application level protocol that can be used for distributed printing 36 on the Internet. There are multiple parts to IPP, but the primary 37 architectural components are the Model, the Protocol and an interface 38 to Directory Services. This document provides a statement of the 39 requirements for notifications as an optional part of an IPP Service. 41 Table of Contents 43 1 Scope............................................................3 45 2 Terminology......................................................3 47 3 Scenarios........................................................7 49 4 Requirements....................................................10 51 5 Security considerations for IPP Notifications requirements......13 53 6 Internationalization Considerations.............................14 55 7 IANA Considerations.............................................14 57 8 References......................................................14 59 9 Author's Address................................................15 61 10 Appendix A: Description of the Base IPP Documents..............15 63 11 Appendix B: Full Copyright Statement...........................16 65 1 Scope 67 This document is one of a set of documents which together describe 68 all aspects of a new Internet Printing Protocol (IPP). IPP is an 69 application level protocol that can be used for distributed printing 70 on the Internet. There are multiple parts to IPP, but the primary 71 architectural components are the Model, the Protocol and an interface 72 to Directory Services. This document provides a statement of the 73 requirements for notifications as an optional part of an IPP Service. 74 See section 10 for a description of the base IPP documents. 76 The scope of this requirements document covers functionality used by 77 the following kinds of IPP Users: End Users, Print Administrators and 78 Operators. See [ipp-ntfy] for the extensions to the Internet 79 Printing Protocol/1.0 (IPP) [RFC2565, RFC2566], IPP/1.1 [RFC2911, 80 RFC2910], and future versions. 82 2 Terminology 84 It is necessary to define a set of terms in order to be able to 85 clearly express the requirements for notification services in an IPP 86 System. 88 2.1 Job Submitting End User 90 A human end user who submits a print job to an IPP Printer. This 91 person may or may not be within the same security domain as the 92 Printer. This person may or may not be geographically near the 93 printer. 95 2.2 Administrator 97 A human user who established policy for and configures the print 98 system. 100 2.3 Operator 102 A human user who carries out the policy established by the 103 Administrator and controls the day to day running of the print 104 system. 106 2.4 Job Submitting Application 108 An application (for example, a batch application), acting on behalf 109 of a Job Submitting End User, which submits a print job to an IPP 110 Printer. The application may or may not be within the same security 111 domain as the Printer. This application may or may not be 112 geographically near the printer. 114 2.5 Security Domain 116 For the purposes of this discussion, the set of network components 117 which can communicate without going through a proxy or firewall. A 118 security domain may be geographically very large, for example - 119 anyplace within example.com. 121 2.6 IPP Client 123 The software component that sends IPP requests to an IPP Printer 124 object and accepts IPP responses from an IPP Printer. 126 2.7 Job Recipient 128 A human who is the ultimate consumer of the print job. In many cases 129 this will be the same person as the Job Submitting End User, but this 130 need not always be the case. For example, if I use IPP to print a 131 document on a printer in a business partner's office, I am the Job 132 Submitting End User, while the person I intend the document for in my 133 business partner's office is the Job Recipient. Since one of the 134 goals of IPP is to be able to print near the Job Recipient of the 135 printed output, we would normally expect that person to be in the 136 same security domain as, and geographically near, the Printer. 137 However, this may not always be the case. For example, I submit a 138 print job across the Internet to a XYZ's print shop. I am both the 139 Submitting end User and the Job Recipient, but I am neither near nor 140 in the same security domain as the Printer. 142 2.8 Job Recipient Proxy 144 A person acting on behalf of the Job Recipient. In particular, the 145 Job Recipient Proxy physically picks up the printed document from the 146 Printer, if the Job Recipient cannot perform that function. The Proxy 147 is by definition geographically near and in the same security domain 148 as the printer. For example, I submit a print job from home to be 149 printed on a printer at work. I'd like my secretary to pick up the 150 print job and put it on my desk. In this case, I am acting as both 151 Job Submitting End User and Job Recipient. My secretary is acting as 152 a Job Recipient Proxy. 154 2.9 Notification Subscriber 156 A client that requests the IPP Printer to send Event Notifications to 157 one or more Notification Recipients. A Notification Subscriber may 158 be a Job Submitting End User or an End User, an Operator, or an 159 Administrator that is not submitting a job. 161 2.10 Notification Source 162 The entity that sends Event Notifications. 164 2.11 Notification Recipient 166 The entity that receives IPP Notifications about Job and/or Printer 167 events. A Notification Recipient may be a: Job Submitting End User, 168 Job Submitting Application, Job Recipient, Job Recipient Proxy, 169 Operator, or Administrator, etc., and their representatives or log 170 file or usage statistics gathering application or other active or 171 passive entities. 173 2.12 Notification Recipient Agent 175 A program which receives Event Notifications on behalf of the 176 Notification Recipient. The agent may take some action on behalf of 177 the recipient, forward the notification to the recipient via some 178 alternative means (for example, page the recipient), or queue the 179 notification for later retrieval by the recipient. 181 2.13 Event 183 A Event is some occurrence (either expected or unexpected) within the 184 printing system of a change of state, condition, or configuration of 185 a Job or Printer object. 187 2.14 Event Notification 189 When an event occurs, an Event Notification is generated that fully 190 describes the event (what the event was, where it occurred, when it 191 occurred, etc.). Event Notifications are delivered to all the 192 Notification Recipients that are subscribed to that Event, if any. 193 The Event Notification is delivered to the address of the 194 Notification Recipient using the notification delivery method defined 195 in the subscription. However, an Event Notification is sent ONLY if 196 there is a corresponding subscription. 198 2.15 Notification Subscription 200 A Notification Subscription is a request by a Notification Subscriber 201 to the IPP Printer to send Event Notifications to specified 202 Notification Recipient(s) when the event occur. 204 2.16 Notification Attributes 206 IPP Objects (for example, a print job) from which notification are 207 being sent may have attributes associated with them. A user may want 208 to have one or more of these associated attributes returned along 209 with a particular notification. In general, these may include any 210 attribute associated with the object emitting the notification. 211 Examples include: 213 number-of-intervening jobs 214 job-k-octets 215 job-k-octets processed 216 job impressions 217 job-impressions-interpreted 218 job-impressions-completed 219 impressionsCompletedCurrentCopy (job MIB) 220 sheetCompletedCopyNumber (job MIB) 221 sheetsCompletedDocumentNumber (job MIB) 222 Copies-requested 223 Copy-type 224 Output-destination 225 Job-state-reasons 226 Job ID 227 Printer URI 228 Subscription ID (for job independent subscription) 230 2.17 Notification Delivery Method (or Delivery Method for short) 232 Event Notifications are delivered using a method, such as email, 233 TCP/IP, etc. 235 2.18 Immediate Notification 237 Notifications sent to the Notification Recipient or the Notification 238 Recipient's agent in such a way that the notification arrives 239 immediately , within the limits of common addressing, routing, 240 network congestion and quality of service. 242 2.19 Store and Forward Notification 244 Notifications which are not necessarily delivered to Notification 245 Recipients immediately, but are queued for delivery by some 246 intermediate network application, for later retrieval. Email is an 247 example of a store and forward notification delivery method. 249 2.20 Reliable Delivery of Notifications 251 Notifications which are delivered by a reliable delivery of packets 252 or character stream, with acknowledgment and retry, such that 253 delivery of the notification is guaranteed within some determinate 254 time limits. For example, if the Notification Recipient has logged 255 off and gone home for the day, an immediate notification cannot be 256 guaranteed to be delivered, even when sent over a reliable transport, 257 because there is nothing there to catch it. Guaranteed delivery 258 requires both store and forward notification and a reliable 259 transport. 261 2.21 Notification over Unreliable Transport 263 Notifications are delivered via the fundamental transport address and 264 routing framework, but no acknowledgment or retry is required. 265 Process to process communications, if involved, are unconstrained. 267 2.22 Human Consumable Notification 269 Notifications which are intended to be consumed by human end users 270 only. Email would be an example of a Human consumable notification, 271 though it could also contain Machine Consumable Notification. 273 2.23 Machine Consumable Notification 275 Notifications which are intended for consumption by a program only, 276 such as an IPP Client. Machine Consumable notifications may not 277 contain human readable information. Do we need both human and 278 machine? Machine readable is intended for application to application 279 only. The Notification Recipient could process the machine readable 280 Event Notification into human readable format. 282 2.24 Mixed Notification 284 A mixed notification contains both Human Consumable and Machine 285 Consumable information. 287 3 Scenarios 289 1. I am sitting in my office and submit a print job to the printer 290 down the hall. I am in the same security domain as the printer and 291 of course, geographically near. I want to know immediately when 292 my print job will be completed (or if there is a problem) because 293 the document I am working on is urgent. I submit the print job 294 with the following attributes: 296 . Notification Recipient - me 297 . Notification Events - all 298 . Notification Attributes - job-state-reason 299 . Notification Type - immediate 301 2. I am working from home and submit a print job to the same printer 302 as in the previous example. However, since I am not at work, I 303 cannot physically get the print file or do anything with it. It 304 can wait until I get to work this afternoon. However, I'd like my 305 secretary to pick up the output and put it on my desk so it 306 doesn't get lost or miss-filed. I'd also like a store and forward 307 notification sent to my email so that when I get to work I can 308 tell if there was a problem with the print job. I submit a print 309 job with the following attributes: 311 . Notification Recipient - my secretary 312 . Notification Events - print complete 313 . Notification Type - immediate 315 . Notification Recipient - me 316 . Notification Events - print complete 317 . Notification Attributes - impressions completed 318 . Notification Type - store and forward 320 3. I am sitting in my office and submit a print job to a client at an 321 engineering firm we work with on a daily basis. The engineering 322 firm is in Belgium. I would like my client to know when the print 323 job is complete, so that she can pick it up from the printer in 324 her building. It is important that she review it right away and 325 get her comments back to me. I submit the print job with the 326 following attributes: 328 . Notification Recipient - client at engineering firm 329 . Notification Events - print complete 330 . Notification Type - immediate 331 . Notification Language - French 333 4. I am in a hotel room and send a print job to a Kinko's store in 334 the town I am working in, in order to get a printed report for the 335 meeting I am attending in the morning. Since I'm going out to 336 dinner after I get this job submitted, an immediate notification 337 won't do me much good. However, I'd like to check in the morning 338 before I drive to the Kinko's store to see if the file has been 339 printed. An email notification is sufficient for this purpose. I 340 submit the print job with the following attributes: 342 . Notification Recipient - me 343 . Notification Events - print complete 344 . Notification Type - store and forward 346 5. I am printing a large, complex print file. I want to have some 347 immediate feedback on the progress of the print job as it prints. 348 I submit the print job with the following attributes: 350 . Notification Recipient - me 351 . Notification Type - immediate 352 . Notification Events - all state transitions 353 . Notification Attributes - impression completed 355 6. I am an operator and my duties is to keep the printer running. I 356 subscribe independently from a job submission so that my 357 subscription outlasts any particular job. I subscribe with the 358 following attributes: 360 . Notification Recipient - me 361 . Notification Type - immediate 362 . Notification Events - all Printer state transitions 363 . Notification Attributes - Printer state, printer state reasons, 364 device powering up, device powering down. 366 7. I am a usage statistics gathering application. I subscribe 367 independently from a job submission so that my subscription 368 outlasts any particular job. My subscription may persists across 369 power cycles. I subscribe with the following attributes: 371 . Notification Recipient - me 372 . Notification Type - immediate 373 . Notification Events - job completion 374 . Notification Attributes - impression completed, sheets 375 completed, time submitted, time started, time completed, job 376 owner, job size in octets, etc. 378 8. I am a client application program that displays a list of jobs 379 currently queued for printing on a printer. I display the "job- 380 name", "job-state", "job-state-reasons", "page-count", and 381 "intervening-jobs" either for the user's jobs or for all jobs. 382 The window displaying the job list remains open for an independent 383 amount of time, and it is desired that it represent the current 384 state of the queue. It is desired that the application only need 385 to perform a slow poll in order to recover from any missed 386 notifications. So the event delivery mechanism provides the means 387 to update the screen on all needed changes, including querying for 388 some attributes that may not be delivered in the Notification. 390 9. I am a client application program that displays a list of 391 printers. For each Printer I display the current state and 392 configuration. The window displaying the printer list remains 393 open for an independent amount of time, and it is desired that it 394 represent the current state of each printer. It is desired that 395 the application only need to perform a slow poll in order to 396 recover from any missed notifications. So the event delivery 397 mechanism provides the means to update the screen on all needed 398 changes, including querying for some attributes that may not be 399 delivered in the Notification. 401 10. I am an IPP Server that controls one or more devices and 402 implements an IPP Printer object to represent each device. I want 403 to support IPP Notification for each of the IPP Printer objects 404 that I implement. Many of these devices do not support 405 notification (or IPP). So I need to support the IPP Notification 406 semantics specified for each IPP Printer object myself on behalf 407 of each of the devices that each of the IPP Printer objects 408 represent. When I accept IPP job creation requests, I convert the 409 request to what the device will accept. In some cases, I must 410 poll the devices in order to be informed of their job and device 411 state and state changes in order to be able to send IPP 412 Notifications to subscribed Notification Recipients. 414 11. I am an IPP Server that controls one or more devices and 415 implements an IPP Printer object to represent each device. I want 416 to support IPP Notification for each of the IPP Printer objects 417 that I implement. These devices all support IPP, including IPP 418 Notification. I would like the design choice for supporting IPP 419 Notification for these IPP Printer objects that I implement either 420 (1) by forwarding the notification to the IPP Printers that I 421 alone control and have them send the notifications to the intended 422 Notification Recipients without my involvement or (2) replace the 423 notification submitted with the Job to indicate me as the 424 Notification Recipient and I will in turn forward Notifications to 425 the Notification Recipients requested by my clients. Most of the 426 rest of the contents of the IPP Job that I send to the IPP 427 Printers that I control will be the same as the IPP Job that I 428 receive from my IPP clients. 430 12. I am an IPP Server that controls one or more devices and 431 implements an IPP Printer object to represent each device. I want 432 to support IPP Notification for each of the IPP Printer objects 433 that I implement. These devices all support IPP, including IPP 434 Notification. Because these IPP Printers MAY also be being 435 controlled by other servers (using IPP or other protocols), I only 436 want job events for the jobs that I send, but do want Printer 437 events all the time, so that I can show proper Printer state to my 438 clients. So I subscribe to these IPP Printers for Printer events 439 with a long standing subscription with myself to as the 440 Notification Recipient. When I get a Job Creation request, I 441 decide to which IPP Printer to send the job. When I do so, I also 442 add a job subscription for Job events with me as the Notification 443 Recipient to the job's job subscriptions supplied by my clients 444 (this usage is called "piggy-backing"). These IPP Printers 445 automatically remove their job subscriptions when the job 446 completes as for all job subscriptions so that I no longer get Job 447 events when my jobs are completed. 449 4 Requirements 450 The following requirements are intended to be met by the IPP 451 Notification specification (not the implementation). The resulting 452 IPP Notification Specification document: 454 1. must indicate which of these requirements are REQUIRED and which 455 are OPTIONAL for a conforming implementation to support. See 456 [RFC2911] section 12.1 for the definition of these important 457 conformance terms. 459 2. must be designed to that an IPP Printer can transparently support 460 the IPP Notification semantics using third party notification 461 services that exist today or that may be standardized in the 462 future. 464 3. must define means for a Job Submitting End User to specify zero or 465 more Notification Recipients when submitting a print job. A 466 Submitter will not be able to prevent out of band subscriptions 467 from authorized persons, such as Operators. 469 4. must define means when specifying a Notification Recipient, for a 470 Notification Subscriber to be able to specify one or more 471 notification events for that Notification Recipient, subject to 472 administrative and security policy restrictions. Any of the 473 following constitute Job or Printer Events that a Job Submitting 474 End User can specify notifications be sent for: 475 . Any standard Printer MIB alert (i.e. device alerts) (critical 476 and warning?) (state change notifications)? 477 . Job Received (transition from Unknown to Pending) 478 . Job Started (Transition from Pending to Processing) 479 . Page Complete (Page is stacked) 480 . Collated Copy Complete (last sheet of collated copy is 481 stacked) 482 . Job Complete (transition from Processing or Processing- 483 stopped to Completed) 484 . Job aborted (transition from Pending, Pending-held, 485 Processing, or Processing-stopped to Aborted) 486 . Job canceled (transition from Pending, Pending-held, 487 Processing, or Processing-held to Canceled) 488 . Other job state changes like 'paused', purged? 489 . Device problems for which the job is destined 490 . Job (interpreter) issues 492 5. must define how an End User or Operator subscribes for: 493 . Any set of Job Events for a specific job. 494 . Any set of Printer Events while a specific job is not 495 complete. 497 6. must define how an End User or Operator subscribes for the 498 following without having to submit a Job: 499 . Any set of Printer Events for a defined period. 500 . Any set of Job Events for all jobs with no control over which 501 jobs. 503 7. must define how the Notification Subscriber is able to specify 504 either immediate or store and forward notification independently 505 for each Notification Recipient. The means may be explicit, or 506 implied by the method of delivery chosen by the Job Submitting End 507 User. 509 8. must define common delivery methods, e.g. email, must be defined. 511 9. must define how an IPP Printer validates its ability to deliver an 512 Event using the specified delivery scheme. If it does not support 513 the specified scheme, or the specified scheme is invalid for some 514 reason, then the IPP Printer accepts and performs the request 515 anyway and responds indicating the unsupported attribute values. 516 There is no requirement for the IPP Printer receiving the print 517 request to validate the identity of an Notification Recipient, nor 518 the ability of the system to deliver an event to that recipient as 519 requested (for example, if the Notification Recipient is not at 520 work today). 522 10. must define a class of IPP event notification delivery methods 523 which can flow through corporate firewalls. However, an IPP 524 printer need not test to guarantee delivery of the notification 525 through a firewall before accepting a print job. 526 11. may define means for delivering a notification to the 527 submitting client when the delivery of an event notification to a 528 specified Notification Recipient fails. Fall back means of 529 subscribers determining if notifications have failed, i.e. 530 polling, may be provided. 532 12. must define a mechanism for localizing Human Consumable 533 notifications by the Notification Source. 535 13. may define a way to specify whether or not event delivery 536 requires acknowledgement back to the Notification Source. 538 14. There must be a mechanism defined so that job independent 539 subscriptions do not become stale and do not require human 540 intervention to remove stale subscriptions. However, stale must 541 not be the inability to deliver an Event Notification , since 542 temporary Notification delivery problems must be tolerated. 544 15. A mechanism must be defined so that an Event Subscriber is 545 able to add an Event Subscription to a Job after the Job has been 546 submitted. 548 16. A mechanism must be defined so that a client is able to cancel 549 an Event Subscription on a job or printer after the job has been 550 submitted. 552 17. A mechanism must be defined so that a client can obtain the 553 set of current Subscriptions. 555 5 Security considerations for IPP Notifications requirements 557 By far the biggest security concern is the abuse of notification: 558 sending unwanted notifications to third parties (i.e., spam). The 559 problem is made worse by notification addresses that may be 560 redistributed to multiple parties (e.g. mailing lists). There exist 561 scenarios where third party notification is required (see Scenario #2 562 and #3). The fully secure solution would require active agreement of 563 all recipients before sending out anything. However, requirement #9 564 ("There is no requirement for IPP Printer receiving the print request 565 to validate the identity of an event recipient") argues against this. 566 Certain systems may decide to disallow third party notifications (a 567 traditional fax model). 569 Clients submitting notification requests to the IPP Printer has the 570 same security issues as submitting an IPP/1.1 print job request. The 571 same mechanisms used by IPP/1.1 can therefore be used by the client 572 notification submission. Operations that require authentication can 573 use the HTTP authentication. Operations that require privacy can use 574 the HTTP/TLS privacy. 576 The notification access control model should be similar to the IPP 577 access control model. Creating a notification subscription is 578 associated with a user. Only the creator or an operator can cancel 579 the subscription. The system may limit the listing of items to only 580 those items owned by the user. Some subscriptions (e.g. those that 581 have a lifetime longer than a job) can be done only by privileged 582 users (operators and/or administrators), if that is the authorization 583 policy. 585 The standard security concerns (delivery to the right user, privacy 586 of content, tamper proof content) apply to the notification delivery. 587 IPP should use the security mechanism of the delivery method used. 588 Some delivery mechanisms are more secure than others. Therefore, 589 sensitive notifications should use the delivery method that has the 590 strongest security. 592 6 Internationalization Considerations 594 The Human Consumable notification must be localized to the natural 595 language and charset that Notification Subscriber specifies within 596 the choice of natural languages and charsets that the IPP Printer 597 supports. 599 The Machine Consumable notification data uses the 'application/ipp' 600 MIME media type. It contains some attributes whose text values are 601 required to be in the natural language and charset that the 602 Notification Subscriber specifies within the choice of natural 603 languages and charsets that the IPP Printer supports. See [RFC2566]. 605 7 IANA Considerations 607 There will be some notification delivery methods registered with IANA 608 for use in URLs. These will be defined in other documents. 610 8 References 612 8.1 Normative References 613 [RFC2910] 614 Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing 615 Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 617 [RFC2911] 618 deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P., 619 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 620 September 2000. 622 [ipp-ntfy] 623 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 624 Bergman, R., " IPP Event Notification Specification", , work in progress, July 17, 2001. 627 8.2 Informative References 628 [RFC2565] 629 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 630 Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. 632 [RFC2566] 633 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 634 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 635 April 1999. 637 [RFC2567] 638 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 639 2567, April 1999. 641 [RFC2568] 642 Zilles, S., "Rationale for the Structure and Model and Protocol for 643 the Internet Printing Protocol", RFC 2568, April 1999. 645 [RFC2569] 646 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 647 LPD and IPP Protocols", RFC 2569, April 1999. 649 [RFC2639] 650 T. Hastings, C. Manros. "Internet Printing Protocol/1.0: 651 Implementer's Guide", RFC 2639, July 1999. 653 9 Author's Address 655 Tom Hastings (editor) 656 Xerox Corporation 657 737 Hawaii St. ESAE 231 658 El Segundo, CA 90245 660 Phone: 310-333-6413 661 Fax: 310-333-5514 662 e-mail: hastings@cp10.es.xerox.com 664 Roger deBry 665 Utah Valley State College 666 Orem, UT 84058 668 Phone: (801) 222-8000 669 e-mail: debryro@uvsc.edu 671 Harry Lewis 672 HUC/003G 673 IBM Corporation 674 P.O. Box 1900 675 Boulder, CO 80301-9191 677 Phone: (303) 924-5337 678 Fax: (303) 924-9889 679 e-mail: harryl@us.ibm.com 681 10 Appendix A: Description of the Base IPP Documents 682 The base set of IPP documents includes: 683 Design Goals for an Internet Printing Protocol [RFC2567] 684 Rationale for the Structure and Model and Protocol for the Internet 685 Printing Protocol [RFC2568] 686 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 687 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 688 Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG] 689 Mapping between LPD and IPP Protocols [RFC2569] 691 The "Design Goals for an Internet Printing Protocol" document takes a 692 broad look at distributed printing functionality, and it enumerates 693 real-life scenarios that help to clarify the features that need to be 694 included in a printing protocol for the Internet. It identifies 695 requirements for three types of users: end users, operators, and 696 administrators. It calls out a subset of end user requirements that 697 are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator 698 operations have been added to IPP/1.1 [RFC2911, RFC2910]. 700 The "Rationale for the Structure and Model and Protocol for the 701 Internet Printing Protocol" document describes IPP from a high level 702 view, defines a roadmap for the various documents that form the suite 703 of IPP specification documents, and gives background and rationale 704 for the IETF IPP working group's major decisions. 705 The "Internet Printing Protocol/1.1: Model and Semantics" document 706 describes a simplified model with abstract objects, their attributes, 707 and their operations. The model introduces a Printer and a Job. The 708 Job supports multiple documents per Job. The model document also 709 addresses how security, internationalization, and directory issues 710 are addressed. 711 The "Internet Printing Protocol/1.1: Encoding and Transport" document 712 is a formal mapping of the abstract operations and attributes defined 713 in the model document onto HTTP/1.1 [RFC2616]. It also defines the 714 encoding rules for a new Internet MIME media type called 715 "application/ipp". This document also defines the rules for 716 transporting over HTTP a message body whose Content-Type is 717 "application/ipp". This document defines the 'ipp' scheme for 718 identifying IPP printers and jobs. 720 The "Internet Printing Protocol/1.1: Implementer's Guide" document 721 gives insight and advice to implementers of IPP clients and IPP 722 objects. It is intended to help them understand IPP/1.1 and some of 723 the considerations that may assist them in the design of their client 724 and/or IPP object implementations. For example, a typical order of 725 processing requests is given, including error checking. Motivation 726 for some of the specification decisions is also included. 727 The "Mapping between LPD and IPP Protocols" document gives some 728 advice to implementers of gateways between IPP and LPD (Line Printer 729 Daemon) implementations. 731 11 Appendix B: Full Copyright Statement 732 Copyright (C) The Internet Society (1998,1999,2000,2001). All Rights 733 Reserved 734 This document and translations of it may be copied and furnished to 735 others, and derivative works that comment on or otherwise explain it 736 or assist in its implementation may be prepared, copied, published 737 and distributed, in whole or in part, without restriction of any 738 kind, provided that the above copyright notice and this paragraph are 739 included on all such copies and derivative works. However, this 740 document itself may not be modified in any way, such as by removing 741 the copyright notice or references to the Internet Society or other 742 Internet organizations, except as needed for the purpose of 743 developing Internet standards in which case the procedures for 744 copyrights defined in the Internet Standards process must be 745 followed, or as required to translate it into languages other than 746 English. 748 The limited permissions granted above are perpetual and will not be 749 revoked by the Internet Society or its successors or assigns. 751 This document and the information contained herein is provided on an 752 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 753 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 754 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 755 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 756 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Acknowledgement 759 Funding for the RFC Editor function is currently provided by the 760 Internet Society.