idnits 2.17.1 draft-ietf-ipp-not-05.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2568], [RFC2569], [RFC2639], [RFC2565], [RFC2566], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 462: '...e these IPP Printers MAY also be being...' RFC 2119 keyword, line 483: '...se requirements are REQUIRED and which...' RFC 2119 keyword, line 484: '... are OPTIONAL for a conforming imp...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 488 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 (January 23, 2001) is 8493 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 20, but not defined == Missing Reference: 'RFC 2639' is mentioned on line 49, but not defined ** Obsolete undefined reference: RFC 2639 (Obsoleted by RFC 3196) == Unused Reference: 'RFC2639' is defined on line 664, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2565 (Obsoleted by RFC 2910) ** Obsolete normative reference: RFC 2566 (Obsoleted by RFC 2911) ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-req (ref. 'RFC2567') ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-rat (ref. 'RFC2568') ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-lpd-ipp-map (ref. 'RFC2569') ** Obsolete normative reference: RFC 2639 (Obsoleted by RFC 3196) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Roger K deBry 3 Utah Valley State College 4 [Target Category: Informational] Harry Lewis 5 IBM Corporation 6 Tom Hastings (editor) 7 Xerox Corporation 8 January 23, 2001 10 Internet Printing Protocol (IPP): Requirements for IPP Notifications 11 Copyright (C) The Internet Society (2001). All Rights Reserved. 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ''work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed as 30 http://www.ietf.org/shadow.html. 32 ABSTRACT 34 This document is one of a set of documents which together describe 35 all aspects of a new Internet Printing Protocol (IPP). IPP is an 36 application level protocol that can be used for distributed printing 37 on the Internet. There are multiple parts to IPP, but the primary 38 architectural components are the Model, the Protocol and an interface 39 to Directory Services. This document provides a statement of the 40 requirements for notifications as part of an IPP Service. 42 The full set of IPP documents include: 44 Design Goals for an Internet Printing Protocol [RFC2567] 45 Rationale for the Structure and Model and Protocol for the Internet 46 Printing Protocol [RFC2568] 47 Internet Printing Protocol/1.0: Model and Semantics [RFC2566] 48 Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] 49 Internet Printing Protocol/1.0: Implementer's Guide [RFC 2639] 50 Mapping between LPD and IPP Protocols [RFC2569] 52 The 'Design Goals for an Internet Printing Protocol' document takes a 53 broad look at distributed printing functionality, and it enumerates 54 real-life scenarios that help to clarify the features that need to be 55 included in a printing protocol for the Internet. It identifies 56 requirements for three types of users: end users, operators, and 57 administrators. It calls out a subset of end user requirements that 58 are satisfied in IPP/1.0. Operator and administrator requirements 59 are out of scope for version 1.0. 61 The 'Rationale for the Structure and Model and Protocol for the 62 Internet Printing Protocol' document describes IPP from a high level 63 view, defines a roadmap for the various documents that form the suite 64 of IPP specifications, and gives background and rationale for the 65 IETF working group's major decisions. 67 The 'Internet Printing Protocol/1.0: Encoding and Transport' document 68 is a formal mapping of the abstract operations and attributes defined 69 in the model document onto HTTP/1.1. It defines the encoding rules 70 for a new Internet media type called 'application/ipp'. 72 The 'Internet Printing Protocol/1.0: Implementer's Guide' document 73 gives insight and advice to implementers of IPP clients and IPP 74 objects. It is intended to help them understand IPP/1.0 and some of 75 the considerations that may assist them in the design of their client 76 and/or IPP object implementations. For example, a typical order of 77 processing requests is given, including error checking. Motivation 78 for some of the specification decisions is also included. 80 The 'Mapping between LPD and IPP Protocols' document gives some 81 advice to implementers of gateways between IPP and LPD (Line Printer 82 Daemon) implementations. 84 Table of Contents 86 1 Scope ...........................................................4 88 2 Terminology .....................................................4 90 3 Scenarios .......................................................8 91 4 Requirements ...................................................11 93 5 Security considerations for IPP Notifications requirements .....13 95 6 Internationalization Considerations ............................14 97 7 IANA Considerations ............................................14 99 8 References .....................................................14 101 9 Author's Address ...............................................15 103 10 Appendix A: Full Copyright Statement...........................16 105 1 Scope 107 The scope of this requirements document covers functionality used by 108 the following kinds of IPP Users: End Users, Print Administrators and 109 Operators. 111 2 Terminology 113 It is necessary to define a set of terms in order to be able to 114 clearly express the requirements for notification services in an IPP 115 System. 117 2.1 Job Submitting End User 119 A human end user who submits a print job to an IPP Printer. This 120 person may or may not be within the same security domain as the 121 Printer. This person may or may not be geographically near the 122 printer. 124 2.2 Administrator 126 A human user who established policy for and configures the print 127 system. 129 2.3 Operator 131 A human user who carries out the policy established by the 132 Administrator and controls the day to day running of the print 133 system. 135 2.4 Job Submitting Application 137 An application (for example, a batch application), acting on behalf 138 of a Job Submitting End User, which submits a print job to an IPP 139 Printer. The application may or may not be within the same security 140 domain as the Printer. This application may or may not be 141 geographically near the printer. 143 2.5 Security Domain 145 For the purposes of this discussion, the set of network components 146 which can communicate without going through a proxy or firewall. A 147 security domain may be geographically very large, for example - 148 anyplace within IBM.COM. 150 2.6 IPP Client 152 The software component that sends IPP requests to an IPP Printer 153 object and accepts IPP responses from an IPP Printer. 155 2.7 Job Recipient 157 A human who is the ultimate consumer of the print job. In many cases 158 this will be the same person as the Job Submitting End User, but this 159 need not always be the case. For example, if I use IPP to print a 160 document on a printer in a business partner's office, I am the Job 161 Submitting End User, while the person I intend the document for in my 162 business partner's office is the Job Recipient. Since one of the 163 goals of IPP is to be able to print near the Job Recipient of the 164 printed output, we would normally expect that person to be in the 165 same security domain as, and geographically near, the Printer. 166 However, this may not always be the case. For example, I submit a 167 print job across the Internet to a Kinko's print shop. I am both the 168 Submitting end User and the Job Recipient, but I am neither near nor 169 in the same security domain as the Printer. 171 2.8 Job Recipient Proxy 173 A person acting on behalf of the Job Recipient. In particular, the 174 Job Recipient Proxy physically picks up the printed document from the 175 Printer, if the Job Recipient cannot perform that function. The Proxy 176 is by definition geographically near and in the same security domain 177 as the printer. For example, I submit a print job from home to be 178 printed on a printer at work. I'd like my secretary to pick up the 179 print job and put it on my desk. In this case, I am acting as both 180 Job Submitting End User and Job Recipient. My secretary is acting as 181 a Job Recipient Proxy. 183 2.9 Notification Subscriber 185 A client that requests the IPP Printer to send Event Notifications to 186 one or more Notification Recipients. A Notification Subscriber may 187 be a Job Submitting End User or an End User, an Operator, or an 188 Administrator that is not submitting a job. 190 2.10 Notification Source 192 The entity that sends Event Notifications. 194 2.11 Notification Recipient 196 The entity that receives IPP Notifications about Job and/or Printer 197 events. A Notification Recipient may be a: Job Submitting End User, 198 Job Submitting Application, Job Recipient, Job Recipient Proxy, 199 Operator, or Administrator, etc., and their representatives or log 200 file or usage statistics gathering application or other active or 201 passive entities. 203 2.12 Notification Recipient Agent 204 A program which receives Event Notifications on behalf of the 205 Notification Recipient. The agent may take some action on behalf of 206 the recipient, forward the notification to the recipient via some 207 alternative means (for example, page the recipient), or queue the 208 notification for later retrieval by the recipient. 210 2.13 Event 212 A Event is some occurrence (either expected or unexpected) within the 213 printing system of a change of state, condition, or configuration of 214 a Job or Printer object. 216 2.14 Event Notification 218 When an event occurs, an Event Notification is generated that fully 219 describes the event (what the event was, where it occurred, when it 220 occurred, etc.). Event Notifications are delivered to all the 221 Notification Recipients that are subscribed to that Event, if any. 222 The Event Notification is delivered to the address of the 223 Notification Recipient using the notification delivery method defined 224 in the subscription. However, an Event Notification is sent ONLY if 225 there is a corresponding subscription. 227 2.15 Notification Subscription 229 A Notification Subscription is a request by a Notification Subscriber 230 to the IPP Printer to send Event Notifications to specified 231 Notification Recipient(s) when the event occur. 233 2.16 Notification Attributes 235 IPP Objects (for example, a print job) from which notification are 236 being sent may have attributes associated with them. A user may want 237 to have one or more of these associated attributes returned along 238 with a particular notification. In general, these may include any 239 attribute associated with the object emitting the notification. 240 Examples include: 242 number-of-intervening jobs 243 job-k-octets 244 job-k-octets processed 245 job impressions 246 job-impressions-interpreted 247 job-impressions-completed 248 impressionsCompletedCurrentCopy (job MIB) 249 sheetCompletedCopyNumber (job MIB) 250 sheetsCompletedDocumentNumber (job MIB) 251 Copies-requested 252 Copy-type 253 Output-destination 254 Job-state-reasons 255 Job ID 256 Printer URI 257 Subscription ID (for job independent subscription) 259 2.17 Notification Delivery Method (or Delivery Method for short) 261 Event Notifications are delivered using a method, such as email, 262 TCP/IP, etc. 264 2.18 Immediate Notification 266 Notifications sent to the Notification Recipient or the Notification 267 Recipient's agent in such a way that the notification arrives 268 immediately , within the limits of common addressing, routing, 269 network congestion and quality of service. 271 2.19 Store and Forward Notification 273 Notifications which are not necessarily delivered to Notification 274 Recipients immediately, but are queued for delivery by some 275 intermediate network application, for later retrieval. Email is an 276 example of a store and forward notification delivery method. 278 2.20 Reliable Delivery of Notifications 280 Notifications which are delivered by a reliable delivery of packets 281 or character stream, with acknowledgment and retry, such that 282 delivery of the notification is guaranteed within some determinate 283 time limits. For example, if the Notification Recipient has logged 284 off and gone home for the day, an immediate notification cannot be 285 guaranteed to be delivered, even when sent over a reliable transport, 286 because there is nothing there to catch it. Guaranteed delivery 287 requires both store and forward notification and a reliable 288 transport. 290 2.21 Notification over Unreliable Transport 292 Notifications are delivered via the fundamental transport address and 293 routing framework, but no acknowledgment or retry is required. 294 Process to process communications, if involved, are unconstrained. 296 2.22 Human Consumable Notification 298 Notifications which are intended to be consumed by human end users 299 only. Email would be an example of a Human consumable notification, 300 though it could also contain Machine Consumable Notification. 302 2.23 Machine Consumable Notification 303 Notifications which are intended for consumption by a program only, 304 such as an IPP Client. Machine Consumable notifications may not 305 contain human readable information. Do we need both human and 306 machine? Machine readable is intended for application to application 307 only. The Notification Recipient could process the machine readable 308 Event Notification into human readable format. 310 2.24 Mixed Notification 312 A mixed notification contains both Human Consumable and Machine 313 Consumable information. 315 3 Scenarios 317 1.I am sitting in my office and submit a print job to the printer 318 down the hall. I am in the same security domain as the printer and 319 of course, geographically near. I want to know immediately when 320 my print job will be completed (or if there is a problem) because 321 the document I am working on is urgent. I submit the print job 322 with the following attributes: 324 . Notification Recipient - me 325 . Notification Events - all 326 . Notification Attributes - job-state-reason 327 . Notification Type - immediate 329 2.I am working from home and submit a print job to the same printer 330 as in the previous example. However, since I am not at work, I 331 cannot physically get the print file or do anything with it. It 332 can wait until I get to work this afternoon. However, I'd like my 333 secretary to pick up the output and put it on my desk so it 334 doesn't get lost or miss-filed. I'd also like a store and forward 335 notification sent to my email so that when I get to work I can 336 tell if there was a problem with the print job. I submit a print 337 job with the following attributes: 339 . Notification Recipient - my secretary 340 . Notification Events - print complete 341 . Notification Type - immediate 343 . Notification Recipient - me 344 . Notification Events - print complete 345 . Notification Attributes - impressions completed 346 . Notification Type - store and forward 348 3.I am sitting in my office and submit a print job to a client at an 349 engineering firm we work with on a daily basis. The engineering 350 firm is in Belgium. I would like my client to know when the print 351 job is complete, so that she can pick it up from the printer in 352 her building. It is important that she review it right away and 353 get her comments back to me. I submit the print job with the 354 following attributes: 356 . Notification Recipient - client at engineering firm 357 . Notification Events - print complete 358 . Notification Type - immediate 359 . Notification Language - French 361 4.I am in a hotel room and send a print job to a Kinko's store in 362 the town I am working in, in order to get a printed report for the 363 meeting I am attending in the morning. Since I'm going out to 364 dinner after I get this job submitted, an immediate notification 365 won't do me much good. However, I'd like to check in the morning 366 before I drive to the Kinko's store to see if the file has been 367 printed. An email notification is sufficient for this purpose. I 368 submit the print job with the following attributes: 370 . Notification Recipient - me 371 . Notification Events - print complete 372 . Notification Type - store and forward 374 5.I am printing a large, complex print file. I want to have some 375 immediate feedback on the progress of the print job as it prints. 376 I submit the print job with the following attributes: 378 . Notification Recipient - me 379 . Notification Type - immediate 380 . Notification Events - all state transitions 381 . Notification Attributes - impression completed 383 6.I am an operator and my duties is to keep the printer running. I 384 subscribe independently from a job submission so that my 385 subscription outlasts any particular job. I subscribe with the 386 following attributes: 388 . Notification Recipient - me 389 . Notification Type - immediate 390 . Notification Events - all Printer state transitions 391 . Notification Attributes - Printer state, printer state reasons, 392 device powering up, device powering down. 394 7.I am a usage statistics gathering application. I subscribe 395 independently from a job submission so that my subscription 396 outlasts any particular job. My subscription may persists across 397 power cycles. I subscribe with the following attributes: 399 . Notification Recipient - me 400 . Notification Type - immediate 401 . Notification Events - job completion 402 . Notification Attributes - impression completed, sheets 403 completed, time submitted, time started, time completed, job 404 owner, job size in octets, etc. 406 8.I am a client application program that displays a list of jobs 407 currently queued for printing on a printer. I display the "job- 408 name", "job-state", "job-state-reasons", "page-count", and 409 "intervening-jobs" either for the user's jobs or for all jobs. 410 The window displaying the job list remains open for an independent 411 amount of time, and it is desired that it represent the current 412 state of the queue. It is desired that the application only need 413 to perform a slow poll in order to recover from any missed 414 notifications. So the event delivery mechanism provides the means 415 to update the screen on all needed changes, including querying for 416 some attributes that may not be delivered in the Notification. 418 9.I am a client application program that displays a list of 419 printers. For each Printer I display the current state and 420 configuration. The window displaying the printer list remains 421 open for an independent amount of time, and it is desired that it 422 represent the current state of each printer. It is desired that 423 the application only need to perform a slow poll in order to 424 recover from any missed notifications. So the event delivery 425 mechanism provides the means to update the screen on all needed 426 changes, including querying for some attributes that may not be 427 delivered in the Notification. 429 10. I am an IPP Server that controls one or more devices and 430 implements an IPP Printer object to represent each device. I want 431 to support IPP Notification for each of the IPP Printer objects 432 that I implement. Many of these devices do not support 433 notification (or IPP). So I need to support the IPP Notification 434 semantics specified for each IPP Printer object myself on behalf 435 of each of the devices that each of the IPP Printer objects 436 represent. When I accept IPP job creation requests, I convert the 437 request to what the device will accept. In some cases, I must 438 poll the devices in order to be informed of their job and device 439 state and state changes in order to be able to send IPP 440 Notifications to subscribed Notification Recipients. 442 11. I am an IPP Server that controls one or more devices and 443 implements an IPP Printer object to represent each device. I want 444 to support IPP Notification for each of the IPP Printer objects 445 that I implement. These devices all support IPP, including IPP 446 Notification. I would like the design choice for supporting IPP 447 Notification for these IPP Printer objects that I implement either 448 (1) by forwarding the notification to the IPP Printers that I 449 alone control and have them send the notifications to the intended 450 Notification Recipients without my involvement or (2) replace the 451 notification submitted with the Job to indicate me as the 452 Notification Recipient and I will in turn forward Notifications to 453 the Notification Recipients requested by my clients. Most of the 454 rest of the contents of the IPP Job that I send to the IPP 455 Printers that I control will be the same as the IPP Job that I 456 receive from my IPP clients. 458 12. I am an IPP Server that controls one or more devices and 459 implements an IPP Printer object to represent each device. I want 460 to support IPP Notification for each of the IPP Printer objects 461 that I implement. These devices all support IPP, including IPP 462 Notification. Because these IPP Printers MAY also be being 463 controlled by other servers (using IPP or other protocols), I only 464 want job events for the jobs that I send, but do want Printer 465 events all the time, so that I can show proper Printer state to my 466 clients. So I subscribe to these IPP Printers for Printer events 467 with a long standing subscription with myself to as the 468 Notification Recipient. When I get a Job Creation request, I 469 decide to which IPP Printer to send the job. When I do so, I also 470 add a job subscription for Job events with me as the Notification 471 Recipient to the job's job subscriptions supplied by my clients 472 (this usage is called "piggy-backing"). These IPP Printers 473 automatically remove their job subscriptions when the job 474 completes as for all job subscriptions so that I no longer get Job 475 events when my jobs are completed. 477 4 Requirements 479 The following requirements are intended to be met by the IPP 480 Notification specification (not the implementation). The resulting 481 IPP Notification Specification document: 483 1.must indicate which of these requirements are REQUIRED and which 484 are OPTIONAL for a conforming implementation to support. See 485 [RFC2911] section 12.1 for the definition of these important 486 conformance terms. 488 2.must be designed to that an IPP Printer can transparently support 489 the IPP Notification semantics using third party notification 490 services that exist today or that may be standardized in the 491 future. 493 3.must define means for a Job Submitting End User to specify zero or 494 more Notification Recipients when submitting a print job. A 495 Submitter will not be able to prevent out of band subscriptions 496 from authorized persons, such as Operators. 498 4.must define means when specifying a Notification Recipient, for a 499 Notification Subscriber to be able to specify one or more 500 notification events for that Notification Recipient, subject to 501 administrative and security policy restrictions. Any of the 502 following constitute Job or Printer Events that a Job Submitting 503 End User can specify notifications be sent for: 504 . Any standard Printer MIB alert (i.e. device alerts) (critical 505 and warning?) (state change notifications)? 506 . Job Received (transition from Unknown to Pending) 507 . Job Started (Transition from Pending to Processing) 508 . Page Complete (Page is stacked) 509 . Collated Copy Complete (last sheet of collated copy is 510 stacked) 511 . Job Complete (transition from Processing or Processing- 512 stopped to Completed) 513 . Job aborted (transition from Pending, Pending-held, 514 Processing, or Processing-stopped to Aborted) 515 . Job canceled (transition from Pending, Pending-held, 516 Processing, or Processing-held to Canceled) 517 . Other job state changes like 'paused', purged? 518 . Device problems for which the job is destined 519 . Job (interpreter) issues 521 5.must define how an End User or Operator subscribes for: 522 . Any set of Job Events for a specific job. 523 . Any set of Printer Events while a specific job is not 524 complete. 526 6.must define how an End User or Operator subscribes for the 527 following without having to submit a Job: 528 . Any set of Printer Events for a defined period. 529 . Any set of Job Events for all jobs with no control over which 530 jobs. 532 7.must define how the Notification Subscriber is able to specify 533 either immediate or store and forward notification independently 534 for each Notification Recipient. The means may be explicit, or 535 implied by the method of delivery chosen by the Job Submitting End 536 User. 538 8.must define common delivery methods, e.g. email, must be defined. 540 9.must define how an IPP Printer validates its ability to deliver an 541 Event using the specified delivery scheme. If it does not support 542 the specified scheme, or the specified scheme is invalid for some 543 reason, then the IPP Printer accepts and performs the request 544 anyway and responds indicating the unsupported attribute values. 545 There is no requirement for the IPP Printer receiving the print 546 request to validate the identity of an Notification Recipient, nor 547 the ability of the system to deliver an event to that recipient as 548 requested (for example, if the Notification Recipient is not at 549 work today). 551 10. must define a class of IPP event notification delivery methods 552 which can flow through corporate firewalls. However, an IPP 553 printer need not test to guarantee delivery of the notification 554 through a firewall before accepting a print job. 555 11. may define means for delivering a notification to the 556 submitting client when the delivery of an event notification to a 557 specified Notification Recipient fails. Fall back means of 558 subscribers determining if notifications have failed, i.e. 559 polling, may be provided. 561 12. must define a mechanism for localizing Human Consumable 562 notifications by the Notification Source. 564 13. may define a way to specify whether or not event delivery 565 requires acknowledgement back to the Notification Source. 567 14. There must be a mechanism defined so that job independent 568 subscriptions do not become stale and do not require human 569 intervention to remove stale subscriptions. However, stale must 570 not be the inability to deliver an Event Notification , since 571 temporary Notification delivery problems must be tolerated. 573 15. A mechanism must be defined so that an Event Subscriber is 574 able to add an Event Subscription to a Job after the Job has been 575 submitted. 577 16. A mechanism must be defined so that a client is able to cancel 578 an Event Subscription on a job or printer after the job has been 579 submitted. 581 17. A mechanism must be defined so that a client can obtain the 582 set of current Subscriptions. 584 5 Security considerations for IPP Notifications requirements 586 By far the biggest security concern is the abuse of notification: 587 sending unwanted notifications to third parties (i.e., spam). The 588 problem is made worse by notification addresses that may be 589 redistributed to multiple parties (e.g. mailing lists). There exist 590 scenarios where third party notification is required (see Scenario #2 591 and #3). The fully secure solution would require active agreement of 592 all recipients before sending out anything. However, requirement #9 593 ("There is no requirement for IPP Printer receiving the print request 594 to validate the identity of an event recipient") argues against this. 595 Certain systems may decide to disallow third party notifications (a 596 traditional fax model). 598 Clients submitting notification requests to the IPP Printer has the 599 same security issues as submitting an IPP/1.1 print job request. The 600 same mechanisms used by IPP/1.1 can therefore be used by the client 601 notification submission. Operations that require authentication can 602 use the HTTP authentication. Operations that require privacy can use 603 the HTTP/TLS privacy. 605 The notification access control model should be similar to the IPP 606 access control model. Creating a notification subscription is 607 associated with a user. Only the creator or an operator can cancel 608 the subscription. The system may limit the listing of items to only 609 those items owned by the user. Some subscriptions (e.g. those that 610 have a lifetime longer than a job) can be done only by privileged 611 users (operators and/or administrators), if that is the authorization 612 policy. 614 The standard security concerns (delivery to the right user, privacy 615 of content, tamper proof content) apply to the notification delivery. 616 IPP should use the security mechanism of the delivery method used. 617 Some delivery mechanisms are more secure than others. Therefore, 618 sensitive notifications should use the delivery method that has the 619 strongest security. 621 6 Internationalization Considerations 623 The Human Consumable notification must be localized to the natural 624 language and charset that Notification Subscriber specifies within 625 the choice of natural languages and charsets that the IPP Printer 626 supports. 628 The Machine Consumable notification data uses the 'application/ipp' 629 MIME media type. It contains some attributes whose text values are 630 required to be in the natural language and charset that the 631 Notification Subscriber specifies within the choice of natural 632 languages and charsets that the IPP Printer supports. See [RFC2566]. 634 7 IANA Considerations 636 There will be some notification delivery methods registered with IANA 637 for use in URLs. These will be defined in other documents. 639 8 References 641 [RFC2565] 642 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 643 Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. 645 [RFC2566] 646 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 647 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 648 April 1999. 650 [RFC2567] 651 Wright, D., "Design Goals for an Internet Printing Protocol", 652 draft-ietf-ipp-req-03.txt, November, 1998. 654 [RFC2568] 655 Zilles, S., "Rationale for the Structure and Model and Protocol for 656 the Internet Printing Protocol", draft-ietf-ipp-rat-04.txt, 657 November, 1998. 659 [RFC2569] 660 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 661 LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-05.txt, November 662 1998. 664 [RFC2639] 665 T. Hastings, C. Manros. "Internet Printing Protocol/1.0: 666 Implementer's Guide", RFC 2639, July 1999. 668 [RFC2911] 669 deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P., 670 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 671 September 2000. 673 9 Author's Address 675 Harry Lewis 676 HUC/003G 677 IBM Corporation 678 P.O. Box 1900 679 Boulder, CO 80301-9191 681 Phone: (303) 924-5337 682 Fax: (303) 924-9889 683 e-mail: harryl@us.ibm.com 685 Roger deBry 686 Utah Valley State College 687 Orem, UT 84058 689 Phone: (801) 222-8000 690 e-mail: debryro@uvsc.edu 692 Tom Hastings (editor) 693 Xerox Corporation 694 737 Hawaii St. ESAE 231 695 El Segundo, CA 90245 697 Phone: 310-333-6413 698 Fax: 310-333-5514 699 e-mail: hastings@cp10.es.xerox.com 700 IPP Mailing List: ipp@pwg.org 701 IPP Mailing List Subscription: ipp-request@pwg.org 702 IPP Web Page: http://www.pwg.org/ipp/ 704 10 Appendix A: Full Copyright Statement 706 Copyright (C) The Internet Society (1998,1999,2000,2001). All Rights 707 Reserved 709 This document and translations of it may be copied and furnished to 710 others, and derivative works that comment on or otherwise explain it 711 or assist in its implementation may be prepared, copied, published 712 and distributed, in whole or in part, without restriction of any 713 kind, provided that the above copyright notice and this paragraph are 714 included on all such copies and derivative works. However, this 715 document itself may not be modified in any way, such as by removing 716 the copyright notice or references to the Internet Society or other 717 Internet organizations, except as needed for the purpose of 718 developing Internet standards in which case the procedures for 719 copyrights defined in the Internet Standards process must be 720 followed, or as required to translate it into languages other than 721 English. 723 The limited permissions granted above are perpetual and will not be 724 revoked by the Internet Society or its successors or assigns. 726 This document and the information contained herein is provided on an 727 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 728 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 729 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 730 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 731 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.