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