idnits 2.17.1 draft-ietf-ipp-not-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 11 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 15) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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], [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 443: '...e these IPP Printers MAY also be being...' RFC 2119 keyword, line 463: '...requirements are REQUIRED and which ar...' RFC 2119 keyword, line 464: '... OPTIONAL for a conforming implementa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 466 has weird spacing: '...arently suppo...' -- 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 (July 6, 2000) is 8666 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: 'RFC2566' is mentioned on line 603, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) ** Downref: Normative reference to an Experimental RFC: RFC 2567 ** Downref: Normative reference to an Experimental RFC: RFC 2568 ** Downref: Normative reference to an Experimental RFC: RFC 2569 Summary: 12 errors (**), 0 flaws (~~), 7 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 Harry Lewis 5 IBM Corporation 6 Tom Hastings (editor) 7 Xerox Corporation 8 July 6, 2000 10 Internet Printing Protocol: Requirements for IPP Notifications 11 Copyright (C) The Internet Society (2000). All Rights Reserved. 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 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 material 24 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 all 35 aspects of a new Internet Printing Protocol (IPP). IPP is an application 36 level protocol that can be used for distributed printing on the 37 Internet. There are multiple parts to IPP, but the primary architectural 38 components are the Model and Semantics, and the Encoding and Transport 39 documents. This document provides a statement of the requirements for 40 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.1: Model and Semantics [ipp-mod] 48 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 49 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 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 are 58 satisfied in IPP/1.1. Operator and administrator requirements are out 59 of scope for the basic documents of version 1.1. 61 The 'Rationale for the Structure and Model and Protocol for the Internet 62 Printing Protocol' document describes IPP from a high level view, 63 defines a roadmap for the various documents that form the suite of IPP 64 specifications, and gives background and rationale for the IETF working 65 group's major decisions. 67 The 'Internet Printing Protocol/1.1: Encoding and Transport' document is 68 a formal mapping of the abstract operations and attributes defined in 69 the model document onto HTTP/1.1. It defines the encoding rules for a 70 new Internet media type called 'application/ipp'. 72 The 'Internet Printing Protocol/1.1: Implementer's Guide' document gives 73 insight and advice to implementers of IPP clients and IPP objects. It 74 is intended to help them understand IPP/1.0 and some of the 75 considerations that may assist them in the design of their client and/or 76 IPP object implementations. For example, a typical order of processing 77 requests is given, including error checking. Motivation for some of the 78 specification decisions is also included. 80 The 'Mapping between LPD and IPP Protocols' document gives some advice 81 to implementers of gateways between IPP and LPD (Line Printer Daemon) 82 implementations. 84 Table of Contents 86 1 Scope..............................................................4 87 2 Terminology........................................................4 88 3 Scenarios..........................................................7 89 4 Requirements......................................................10 90 5 Security considerations for IPP Notifications requirements........12 91 6 Internationalization Considerations...............................13 92 7 IANA Considerations...............................................13 93 8 References........................................................13 94 9 Author's Address..................................................15 95 1 Scope 97 The scope of this requirements document covers functionality used by the 98 following kinds of IPP Users: End Users, Print Administrators and 99 Operators. 101 2 Terminology 103 It is necessary to define a set of terms in order to be able to clearly 104 express the requirements for notification services in an IPP System. 106 2.1 Job Submitting End User 108 A human end user who submits a print job to an IPP Printer. This person 109 may or may not be within the same security domain as the Printer. This 110 person may or may not be geographically near the printer. 112 2.2 Administrator 114 A human user who established policy for and configures the print system. 116 2.3 Operator 118 A human user who carries out the policy established by the Administrator 119 and controls the day to day running of the print system. 121 2.4 Job Submitting Application 123 An application (for example, a batch application), acting on behalf of a 124 Job Submitting End User, which submits a print job to an IPP Printer. 125 The application may or may not be within the same security domain as the 126 Printer. This application may or may not be geographically near the 127 printer. 129 2.5 Security Domain 131 For the purposes of this discussion, the set of network components which 132 can communicate without going through a proxy or firewall. A security 133 domain may be geographically very large, for example - anyplace within 134 IBM.COM. 136 2.6 IPP Client 138 The software component that sends IPP requests to an IPP Printer object 139 and accepts IPP responses from an IPP Printer. 141 2.7 Job Recipient 143 A human who is the ultimate consumer of the print job. In many cases 144 this will be the same person as the Job Submitting End User, but this 145 need not always be the case. For example, if I use IPP to print a 146 document on a printer in a business partner's office, I am the Job 147 Submitting End User, while the person I intend the document for in my 148 business partner's office is the Job Recipient. Since one of the goals 149 of IPP is to be able to print near the Job Recipient of the printed 150 output, we would normally expect that person to be in the same security 151 domain as, and geographically near, the Printer. However, this may not 152 always be the case. For example, I submit a print job across the 153 Internet to a Kinko's print shop. I am both the Submitting end User and 154 the Job Recipient, but I am neither near nor in the same security domain 155 as the Printer. 157 2.8 Job Recipient Proxy 159 A person acting on behalf of the Job Recipient. In particular, the Job 160 Recipient Proxy physically picks up the printed document from the 161 Printer, if the Job Recipient cannot perform that function. The Proxy is 162 by definition geographically near and in the same security domain as the 163 printer. For example, I submit a print job from home to be printed on a 164 printer at work. I'd like my secretary to pick up the print job and put 165 it on my desk. In this case, I am acting as both Job Submitting End 166 User and Job Recipient. My secretary is acting as a Job Recipient Proxy. 168 2.9 Notification Subscriber 170 A client that requests the IPP Printer to send Event Notifications to 171 one or more Notification Recipients. A Notification Subscriber may be a 172 Job Submitting End User or an End User, an Operator, or an Administrator 173 that is not submitting a job. 175 2.10 Notification Source 177 The entity that sends Event Notifications. 179 2.11 Notification Recipient 181 The entity that receives IPP Notifications about Job and/or Printer 182 events. A Notification Recipient may be a: Job Submitting End User, Job 183 Submitting Application, Job Recipient, Job Recipient Proxy, Operator, or 184 Administrator, etc., and their representatives or log file or usage 185 statistics gathering application or other active or passive entities. 187 2.12 Notification Recipient Agent 189 A program which receives Event Notifications on behalf of the 190 Notification Recipient. The agent may take some action on behalf of the 191 recipient, forward the notification to the recipient via some 192 alternative means (for example, page the recipient), or queue the 193 notification for later retrieval by the recipient. 195 2.13 Event 197 A Event is some occurrence (either expected or unexpected) within the 198 printing system of a change of state, condition, or configuration of a 199 Job or Printer object. 201 2.14 Event Notification 202 When an event occurs, an Event Notification is generated that fully 203 describes the event (what the event was, where it occurred, when it 204 occurred, etc.). Event Notifications are delivered to all the 205 Notification Recipients that are subscribed to that Event, if any. The 206 Event Notification is delivered to the address of the Notification 207 Recipient using the notification delivery method defined in the 208 subscription. However, an Event Notification is sent ONLY if there is a 209 corresponding subscription. 211 2.15 Notification Subscription 213 A Notification Subscription is a request by a Notification Subscriber to 214 the IPP Printer to send Event Notifications to specified Notification 215 Recipient(s) when the event occur. 217 2.16 Notification Attributes 219 IPP Objects (for example, a print job) from which notification are being 220 sent may have attributes associated with them. A user may want to have 221 one or more of these associated attributes returned along with a 222 particular notification. In general, these may include any attribute 223 associated with the object emitting the notification. Examples include: 225 number-of-intervening jobs 226 job-k-octets 227 job-k-octets processed 228 job impressions 229 job-impressions-interpreted 230 job-impressions-completed 231 impressionsCompletedCurrentCopy (job MIB) 232 sheetCompletedCopyNumber (job MIB) 233 sheetsCompletedDocumentNumber (job MIB) 234 Copies-requested 235 Copy-type 236 Output-destination 237 Job-state-reasons 238 Job ID 239 Printer URI 240 Subscription ID (for job independent subscription) 242 2.17 Notification Delivery Method (or Delivery Method for short) 244 Event Notifications are delivered using a method, such as email, TCP/IP, 245 etc. 247 2.18 Immediate Notification 249 Notifications sent to the Notification Recipient or the Notification 250 Recipient's agent in such a way that the notification arrives 251 immediately , within the limits of common addressing, routing, network 252 congestion and quality of service. 254 2.19 Store and Forward Notification 255 Notifications which are not necessarily delivered to Notification 256 Recipients immediately, but are queued for delivery by some intermediate 257 network application, for later retrieval. Email is an example of a store 258 and forward notification delivery method. 260 2.20 Reliable Delivery of Notifications 262 Notifications which are delivered by a reliable delivery of packets or 263 character stream, with acknowledgment and retry, such that delivery of 264 the notification is guaranteed within some determinate time limits. For 265 example, if the Notification Recipient has logged off and gone home for 266 the day, an immediate notification cannot be guaranteed to be delivered, 267 even when sent over a reliable transport, because there is nothing there 268 to catch it. Guaranteed delivery requires both store and forward 269 notification and a reliable transport. 271 2.21 Notification over Unreliable Transport 273 Notifications are delivered via the fundamental transport address and 274 routing framework, but no acknowledgment or retry is required. Process 275 to process communications, if involved, are unconstrained. 277 2.22 Human Consumable Notification 279 Notifications which are intended to be consumed by human end users only. 280 Email would be an example of a Human consumable notification, though it 281 could also contain Machine Consumable Notification. 283 2.23 Machine Consumable Notification 285 Notifications which are intended for consumption by a program only, such 286 as an IPP Client. Machine Consumable notifications may not contain human 287 readable information. Do we need both human and machine? Machine 288 readable is intended for application to application only. The 289 Notification Recipient could process the machine readable Event 290 Notification into human readable format. 292 2.24 Mixed Notification 294 A mixed notification contains both Human Consumable and Machine 295 Consumable information. 297 3 Scenarios 299 1.I am sitting in my office and submit a print job to the printer down 300 the hall. I am in the same security domain as the printer and of 301 course, geographically near. I want to know immediately when my 302 print job will be completed (or if there is a problem) because the 303 document I am working on is urgent. I submit the print job with the 304 following attributes: 306 - Notification Recipient - me 307 - Notification Events - all 308 - Notification Attributes - job-state-reason 309 - Notification Type - immediate 311 2.I am working from home and submit a print job to the same printer as 312 in the previous example. However, since I am not at work, I cannot 313 physically get the print file or do anything with it. It can wait 314 until I get to work this afternoon. However, I'd like my secretary to 315 pick up the output and put it on my desk so it doesn't get lost or 316 miss-filed. I'd also like a store and forward notification sent to my 317 email so that when I get to work I can tell if there was a problem 318 with the print job. I submit a print job with the following 319 attributes: 321 - Notification Recipient - my secretary 322 - Notification Events - print complete 323 - Notification Type - immediate 325 - Notification Recipient - me 326 - Notification Events - print complete 327 - Notification Attributes - impressions completed 328 - Notification Type - store and forward 330 3.I am sitting in my office and submit a print job to a client at an 331 engineering firm we work with on a daily basis. The engineering firm 332 is in Belgium. I would like my client to know when the print job is 333 complete, so that she can pick it up from the printer in her 334 building. It is important that she review it right away and get her 335 comments back to me. I submit the print job with the following 336 attributes: 338 - Notification Recipient - client at engineering firm 339 - Notification Events - print complete 340 - Notification Type - immediate 341 - Notification Language - French 343 4.I am in a hotel room and send a print job to a Kinko's store in the 344 town I am working in, in order to get a printed report for the 345 meeting I am attending in the morning. Since I'm going out to dinner 346 after I get this job submitted, an immediate notification won't do me 347 much good. However, I'd like to check in the morning before I drive 348 to the Kinko's store to see if the file has been printed. An email 349 notification is sufficient for this purpose. I submit the print job 350 with the following attributes: 352 - Notification Recipient - me 353 - Notification Events - print complete 354 - Notification Type - store and forward 356 5.I am printing a large, complex print file. I want to have some 357 immediate feedback on the progress of the print job as it prints. I 358 submit the print job with the following attributes: 360 - Notification Recipient - me 361 - Notification Type - immediate 362 - Notification Events - all state transitions 363 - Notification Attributes - impression completed 365 6.I am an operator and my duties is to keep the printer running. I 366 subscribe independently from a job submission so that my subscription 367 outlasts any particular job. I subscribe with the following 368 attributes: 370 - Notification Recipient - me 371 - Notification Type - immediate 372 - Notification Events - all Printer state transitions 373 - Notification Attributes - Printer state, printer state reasons, 374 device powering up, device powering down. 376 7.I am a usage statistics gathering application. I subscribe 377 independently from a job submission so that my subscription outlasts 378 any particular job. My subscription may persists across power 379 cycles. I subscribe with the following attributes: 381 - Notification Recipient - me 382 - Notification Type - immediate 383 - Notification Events - job completion 384 - Notification Attributes - impression completed, sheets completed, 385 time submitted, time started, time completed, job owner, job size 386 in octets, etc. 388 8.I am a client application program that displays a list of jobs 389 currently queued for printing on a printer. I display the "job- 390 name", "job-state", "job-state-reasons", "page-count", and 391 "intervening-jobs" either for the user's jobs or for all jobs. The 392 window displaying the job list remains open for an independent amount 393 of time, and it is desired that it represent the current state of the 394 queue. It is desired that the application only need to perform a 395 slow poll in order to recover from any missed notifications. So the 396 event delivery mechanism provides the means to update the screen on 397 all needed changes, including querying for some attributes that may 398 not be delivered in the Notification. 400 9.I am a client application program that displays a list of printers. 401 For each Printer I display the current state and configuration. The 402 window displaying the printer list remains open for an independent 403 amount of time, and it is desired that it represent the current state 404 of each printer. It is desired that the application only need to 405 perform a slow poll in order to recover from any missed 406 notifications. So the event delivery mechanism provides the means to 407 update the screen on all needed changes, including querying for some 408 attributes that may not be delivered in the Notification. 410 10. I am an IPP Server that controls one or more devices and implements 411 an IPP Printer object to represent each device. I want to support 412 IPP Notification for each of the IPP Printer objects that I 413 implement. Many of these devices do not support notification (or 414 IPP). So I need to support the IPP Notification semantics specified 415 for each IPP Printer object myself on behalf of each of the devices 416 that each of the IPP Printer objects represent. When I accept IPP 417 job creation requests, I convert the request to what the device will 418 accept. In some cases, I must poll the devices in order to be 419 informed of their job and device state and state changes in order to 420 be able to send IPP Notifications to subscribed Notification 421 Recipients. 423 11. I am an IPP Server that controls one or more devices and implements 424 an IPP Printer object to represent each device. I want to support 425 IPP Notification for each of the IPP Printer objects that I 426 implement. These devices all support IPP, including IPP 427 Notification. I would like the design choice for supporting IPP 428 Notification for these IPP Printer objects that I implement either 429 (1) by forwarding the notification to the IPP Printers that I alone 430 control and have them send the notifications to the intended 431 Notification Recipients without my involvement or (2) replace the 432 notification submitted with the Job to indicate me as the 433 Notification Recipient and I will in turn forward Notifications to 434 the Notification Recipients requested by my clients. Most of the 435 rest of the contents of the IPP Job that I send to the IPP Printers 436 that I control will be the same as the IPP Job that I receive from my 437 IPP clients. 439 12. I am an IPP Server that controls one or more devices and implements 440 an IPP Printer object to represent each device. I want to support 441 IPP Notification for each of the IPP Printer objects that I 442 implement. These devices all support IPP, including IPP 443 Notification. Because these IPP Printers MAY also be being 444 controlled by other servers (using IPP or other protocols), I only 445 want job events for the jobs that I send, but do want Printer events 446 all the time, so that I can show proper Printer state to my clients. 447 So I subscribe to these IPP Printers for Printer events with a long 448 standing subscription with myself to as the Notification Recipient. 449 When I get a Job Creation request, I decide to which IPP Printer to 450 send the job. When I do so, I also add a job subscription for Job 451 events with me as the Notification Recipient to the job's job 452 subscriptions supplied by my clients (this usage is called "piggy- 453 backing"). These IPP Printers automatically remove their job 454 subscriptions when the job completes as for all job subscriptions so 455 that I no longer get Job events when my jobs are completed. 457 4 Requirements 459 The following requirements are intended to be met by the IPP 460 Notification specification (not the implementation). The resulting IPP 461 Notification Specification document: 463 1.must indicate which of these requirements are REQUIRED and which are 464 OPTIONAL for a conforming implementation to support. 466 2.must be designed to that an IPP Printer can transparently support 467 the IPP Notification semantics using third party notification 468 services that exist today or that may be standardized in the future. 470 3.must define means for a Job Submitting End User to specify zero or 471 more Notification Recipients when submitting a print job. A Submitter 472 will not be able to prevent out of band subscriptions from authorized 473 persons, such as Operators. 475 4.must define means when specifying a Notification Recipient, for a 476 Notification Subscriber to be able to specify one or more 477 notification events for that Notification Recipient, subject to 478 administrative and security policy restrictions. Any of the 479 following constitute Job or Printer Events that a Job Submitting End 480 User can specify notifications be sent for: 481 - Any standard Printer MIB alert (i.e. device alerts) (critical 482 and warning?) (state change notifications)? 483 - Job Received (transition from Unknown to Pending) 484 - Job Started (Transition from Pending to Processing) 485 - Page Complete (Page is stacked) 486 - Collated Copy Complete (last sheet of collated copy is stacked) 487 - Job Complete (transition from Processing or Processing-stopped 488 to Completed) 489 - Job aborted (transition from Pending, Pending-held, Processing, 490 or Processing-stopped to Aborted) 491 - Job canceled (transition from Pending, Pending-held, Processing, 492 or Processing-held to Canceled) 493 - Other job state changes like 'paused', purged? 494 - Device problems for which the job is destined 495 - Job (interpreter) issues 497 5.must define how an End User or Operator subscribes for: 498 - Any set of Job Events for a specific job. 499 - Any set of Printer Events while a specific job is not complete. 501 6.must define how an End User or Operator subscribes for the following 502 without having to submit a Job: 503 - Any set of Printer Events for a defined period. 504 - Any set of Job Events for all jobs with no control over which 505 jobs. 507 7.must define how the Notification Subscriber is able to specify either 508 immediate or store and forward notification independently for each 509 Notification Recipient. The means may be explicit, or implied by the 510 method of delivery chosen by the Job Submitting End User. 512 8.must define common delivery methods, e.g. email, must be defined. 514 9.must define how an IPP Printer validates its ability to deliver an 515 Event using the specified delivery scheme. If it does not support 516 the specified scheme, or the specified scheme is invalid for some 517 reason, then the IPP Printer accepts and performs the request anyway 518 and responds indicating the unsupported attribute values. There is 519 no requirement for the IPP Printer receiving the print request to 520 validate the identity of an Notification Recipient, nor the ability 521 of the system to deliver an event to that recipient as requested (for 522 example, if the Notification Recipient is not at work today). 524 10. must define a class of IPP event notification delivery methods 525 which can flow through corporate firewalls. However, an IPP printer 526 need not test to guarantee delivery of the notification through a 527 firewall before accepting a print job. 529 11. may define means for delivering a notification to the submitting 530 client when the delivery of an event notification to a specified 531 Notification Recipient fails. Fall back means of subscribers 532 determining if notifications have failed, i.e. polling, may be 533 provided. 535 12. must define a mechanism for localizing Human Consumable 536 notifications by the Notification Source. 538 13. may define a way to specify whether or not event delivery requires 539 acknowledgement back to the Notification Source. 541 14. There must be a mechanism defined so that job independent 542 subscriptions do not become stale and do not require human 543 intervention to remove stale subscriptions. However, stale must not 544 be the inability to deliver an Event Notification , since temporary 545 Notification delivery problems must be tolerated. 547 15. A mechanism must be defined so that an Event Subscriber is able to 548 add an Event Subscription to a Job after the Job has been submitted. 550 16. A mechanism must be defined so that a client is able to cancel an 551 Event Subscription on a job or printer after the job has been 552 submitted. 554 17. A mechanism must be defined so that a client can obtain the set of 555 current Subscriptions. 557 5 Security considerations for IPP Notifications requirements 559 By far the biggest security concern is the abuse of notification: 560 sending unwanted notifications to third parties (i.e., spam). The 561 problem is made worse by notification addresses that may be 562 redistributed to multiple parties (e.g. mailing lists). There exist 563 scenarios where third party notification is required (see Scenario #2 564 and #3). The fully secure solution would require active agreement of 565 all recipients before sending out anything. However, requirement #9 566 (There is no requirement for IPP Printer receiving the print request to 567 validate the identity of an event recipient) argues against this. 568 Certain systems may decide to disallow third party notifications (a 569 traditional fax model). 571 Clients submitting notification requests to the IPP Printer has the same 572 security issues as submitting an IPP/1.1 print job request. 573 The same mechanisms used by IPP/1.1 can therefore be used by the client 574 notification submission. Operations that require authentication can use 575 the HTTP authentication. Operations that require privacy can use the 576 HTTP/TLS privacy. 578 The notification access control model should be similar to the IPP 579 access control model. Creating a notification subscription is 580 associated with a user. Only the creator or an operator can cancel the 581 subscription. The system may limit the listing of items to only those 582 items owned by the user. Some subscriptions (e.g. those that have a 583 lifetime longer than a job) can be done only by privileged users 584 (operators and/or administrators), if that is the authorization policy. 586 The standard security concerns (delivery to the right user, privacy of 587 content, tamper proof content) apply to the notification delivery. IPP 588 should use the security mechanism of the delivery method used. Some 589 delivery mechanisms are more secure than others. Therefore, sensitive 590 notifications should use the delivery method that has the strongest 591 security. 593 6 Internationalization Considerations 595 The Human Consumable notification must be localized to the natural 596 language and charset that Notification Subscriber specifies within the 597 choice of natural languages and charsets that the IPP Printer supports. 599 The Machine Consumable notification data uses the 'application/ipp' MIME 600 media type. It contains some attributes whose text values are required 601 to be in the natural language and charset that the Notification 602 Subscriber specifies within the choice of natural languages and charsets 603 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. 610 8 References 612 [ipp-mod] 613 deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P., 614 "Internet Printing Protocol/1.1: Model and Semantics", < draft- 615 ietf-ipp-model-v11-07.txt>, work in progress, May 2000. 617 [ipp-pro] 618 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 619 Protocol/1.1: Encoding and Transport", 620 , May 2000. 622 [RFC2567] 623 Wright, D., "Design Goals for an Internet Printing Protocol", 624 RFC 2567, April 1999. 626 [RFC2568] 627 Zilles, S., "Rationale for the Structure and Model and Protocol for 628 the Internet Printing Protocol", RFC 2568, April 1999. 630 [RFC2569] 631 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 632 LPD and IPP Protocols", RFC 2569, April 1999. 634 [ipp-iig] 635 T. Hastings, C. Manros. "Internet Printing Protocol/1.1: 636 Implementer's Guide", 638 May 2000. 640 9 Author's Addresses 642 Harry Lewis 643 HUC/003G 644 IBM Corporation 645 P.O. Box 1900 646 Boulder, CO 80301-9191 648 Phone: (303) 924-5337 649 Fax: (303) 924-9889 650 e-mail: harryl@us.ibm.com 652 Roger deBry 653 Utah Valley State College 654 Orem, UT 84058 656 Phone: (801) 222-8000 657 e-mail: debryro@uvsc.edu 659 Tom Hastings (editor) 660 Xerox Corporation 661 737 Hawaii St. ESAE 231 662 El Segundo, CA 90245 664 Phone: 310-333-6413 665 Fax: 310-333-5514 666 e-mail: hastings@cp10.es.xerox.com 668 IPP Mailing List: ipp@pwg.org 669 IPP Mailing List Subscription: ipp-request@pwg.org 670 IPP Web Page: http://www.pwg.org/ipp/