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