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