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