idnits 2.17.1 draft-ietf-ipp-not-02.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 10 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-18) 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 9 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([RFC2568], [RFC2569], [RFC2565], [RFC2566], [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 331: '...RY and which are OPTIONAL for a confor...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 93 has weird spacing: '...ors and opera...' -- 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 (June 24, 1999) is 9065 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 section? 'RFC2026' on line 19 looks like a reference -- Missing reference section? 'RFC2567' on line 44 looks like a reference -- Missing reference section? 'RFC2568' on line 46 looks like a reference -- Missing reference section? 'RFC2566' on line 47 looks like a reference -- Missing reference section? 'RFC2565' on line 48 looks like a reference -- Missing reference section? 'RFC2569' on line 50 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Roger K deBry 2 Utah Valley State College 3 Harry Lewis 4 IBM Corporation 5 Tom Hastings 6 Xerox Corporation 7 June 24, 1999 9 Internet Printing Protocol/1.1: Requirements for IPP Notifications 10 Copyright (C) The Internet Society (1999). All Rights Reserved. 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as ''work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed as 29 http://www.ietf.org/shadow.html. 31 ABSTRACT 33 This document is one of a set of documents which together describe all 34 aspects of a new Internet Printing Protocol (IPP). IPP is an application 35 level protocol that can be used for distributed printing on the 36 Internet. There are multiple parts to IPP, but the primary architectural 37 components are the Model, the Protocol and an interface to Directory 38 Services. This document provides a statement of the requirements for 39 notifications as part of an IPP Service. Some ISSUES are indicated in 40 the text. 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.0: Model and Semantics [RFC2566] 48 Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] 49 Internet Printing Protocol/1.0: 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.0. Operator and administrator requirements are out 59 of scope for version 1.0. 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.0: 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.0: 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..............................................................3 87 2 Terminology........................................................3 88 3 Requirements.......................................................7 89 4 Scenarios..........................................................8 90 1 Scope 92 The scope of this requirements statement is for end users, print 93 administrators and operators. 95 2 Terminology 97 It is necessary to define a set of terms in order to be able to clearly 98 express the requirements for notification services in an IPP System. 100 2.1 Job Submitting End User 102 A human end user who submits a print job to an IPP Printer. This person 103 may or may not be within the same security domain as the Printer. This 104 person may or may not be geographically near the printer. 106 2.2 Administrator 108 A human user who established policy for and configures the print system 110 2.3 Operator 112 A human user who carries out the policy established by the Administrator 113 and controls the day to day running of the print system. 115 2.4 Job Submitting Application 117 An application (for example a batch application), acting on behalf of an 118 end user, which submits a print job to an IPP Printer. The application 119 may or may not be within the same security domain as the Printer. This 120 application may or may not be geographically near the printer. 122 2.5 Security Domain 124 For the purposes of this discussion, the set of network components which 125 can communicate without going through a proxy or firewall. A security 126 domain may be geographically very large, for example - anyplace within 127 IBM.COM. 129 2.6 IPP Client 131 The software component on the client system which implements the IPP 132 protocol. 134 2.7 Job Recipient 136 A human who is the ultimate consumer of the print job. In many cases 137 this will be the same person as the Job Submitting End User, but this 138 need not always be the case. For example, if I use IPP to print a 139 document on a printer in a business partner's office, I am the Job 140 Submitting End User, while the person I intend the document for in my 141 business partner's office is the Job Recipient. Since one of the goals 142 of IPP is to be able to print near the ultimate recipient of the printed 143 output, we would normally expect the Job Recipient to be in the same 144 security domain as, and geographically near the Printer. However, this 145 may not always be the case. For example, I submit a print job across the 146 Internet to a Kinko's print shop. I am both the Submitting end User and 147 the Job Recipient, but I am neither near nor in the same security domain 148 as the Printer. 150 2.8 Job Recipient Proxy 152 A person acting on behalf of the Job Recipient. In particular, the Job 153 Recipient Proxy physically picks up the printed document from the 154 Printer, if the Job Recipient cannot perform that function. The Proxy is 155 by definition geographically near and in the same security domain as the 156 printer. For example, I submit a print job from home to be printed on a 157 printer at work. I'd like my secretary to pick up the print job and put 158 it on my desk. In this case, I am acting as both Job Submitting End 159 User and Job Recipient. My secretary is acting as a Job Recipient Proxy. 161 2.9 Notification Subscriber 163 A client that requests the IPP Printer to send event reports to one or 164 more Notification Recipients. A Notification Subscriber may be a Job 165 Submitting End User or an End User, an Operator, or an Administrator 166 that is not submitting a job. 168 2.10 Notification Source 170 The entity that sends notification events 172 2.11 Notification Recipient 174 Any of: Job Submitting End User, Job Submitting Application, Job 175 Recipient, or Job Recipient Proxy or admin etc folks and their 176 representatives or log file or accounting/audit application or other 177 active or passive entities or President Clinton. Or Monica. 179 2.12 Notification Recipient Agent 181 A program which receives events on behalf of the notification recipient. 182 The agent may take some action on behalf of the recipient, forward the 183 notification to the recipient via some alternative means (for example, 184 page the recipient), or queue the notification for later retrieval by 185 the recipient. 187 2.13 Event 189 A event is some occurrence (either expected or unexpected) within the 190 printing system. Any of the following constitute events that a Job 191 Submitting End User can specify notifications be sent for: 193 @ Any standard Printer MIB alert (i.e. device alerts) (critical and 194 warning?) (state change notifications)? 195 @ Job Received (transition from Unknown to Pending) 196 @ Job Started (Transition from Pending to Processing) 197 @ Page Complete (Page is stacked) 198 @ Collated Copy Complete (last sheet of collated copy is stacked) 199 @ Job Complete (transition from Processing or Processing-stopped to 200 Completed) 201 @ Job aborted (transition from Pending, Pending-held, Processing, or 202 Processing-stopped to Aborted) 203 @ Job canceled (transition from Pending, Pending-held, Processing, or 204 Processing-held to Canceled) 205 @ Other job state changes like 'paused', purged? 206 @ Device problems on which the job is destine for 207 @ Job (interpreter) issues 209 2.14 Event report 211 When an event occurs, an event report is generated that fully describes 212 the event (what the event was, where it occurred, when it occurred, 213 etc.). Event reports are delivered to all the notification recipients 214 that are subscribed to that event, if any. The event report is 215 delivered to the address of the notification recipient using the 216 notification delivery method defined in the subscription. However, an 217 Event Report is sent ONLY if there is a corresponding subscription. 219 2.15 Notification Subscription 221 It should be possible for end users and operators to 'subscribe' for 222 notifications of certain types of events, independent of Job Submission. 223 An end user or operator may subscribe for 225 @ All Job Traps 226 @ All Traps (Job and Printer) 227 @ None (Reserves a slot in some limited stable of 'notification hosts') 228 ISSUE: Need to discuss granularity and categorization in the context of 229 anticipated event frequency 231 2.16 Notification Attributes 233 IPP Objects (for example, a print job) from which notification are being 234 sent may have attributes associated with them. A user may want to have 235 one or more of these associated attributes returned along with a 236 particular notification. In general, these may include any attribute 237 associated with the object emitting the notification. Examples include: 239 number-of-intervening jobs 240 job-k-octets 241 job-k-octets processed 242 job impressions 243 job-impressions-interpreted 244 job-impressions-completed 245 impressionsCompletedCurrentCopy (job MIB) 246 sheetCompletedCopyNumber (job MIB) 247 sheetsCompletedDocumentNumber (job MIB) 248 Copies-requested 249 Copy-type 250 Output-destination 251 Job-state-reasons 252 Job ID 253 Printer URI 254 Subscription ID (for job independent subscription) 256 2.17 Notification Delivery Method (or Delivery Method for short) 258 Event reports are delivered using a method, such as email, TCP/IP, etc. 260 2.18 Immediate Notification 262 Notifications sent to the notification recipient or the notification 263 recipient's agent in such a way that the notification arrives 264 immediately , within the limits of common addressing, routing, network 265 congestion and quality of service. 267 2.19 Queued Notification 269 Notifications which are not necessarily sent immediately, but are queued 270 for delivery by some intermediate network application, or for later 271 retrieval. Email with store and forward is an example of queued 272 notification. 274 2.20 Notification over Reliable Transport 276 Notifications which are delivered by a reliable, sequenced delivery of 277 packets or character stream, with acknowledgment and retry, such that 278 delivery of the notification is guaranteed within some reasonable time 279 limits. For example, if the notification recipient has logged off and 280 gone home for the day, an immediate notification cannot be guaranteed to 281 be delivered, even when sent over a reliable transport, because there is 282 nothing there to catch it. Guaranteed delivery requires both queued 283 notification and a reliable transport. If delivery of the notification 284 requires process to process communications, each session is managed in a 285 reliable manner, assuring fully ordered, end-to-end delivery. 287 2.21 Notification over Unreliable Transport 289 Notifications are delivered via the fundamental transport address and 290 routing framework, but no acknowledgment or retry is required. Process 291 to process communications, if involved, are unconstrained. 293 2.22 Human Consumable Notification 295 Notifications which are intended to be consumed by human end users only. 296 They contain no machine readable encoding of the event. Email would be 297 an example of a Human consumable notification. 298 ISSUE: Do we need both human and machine or is machine sufficient? 299 There is no intent to attempt to standardize human readable strings. 300 Human readable is intended for certain protocols, like e-mail, though 301 email can also convey machine readable MIME types as well using 302 multipart/report. 304 ISSUE: Is e-mail the only, or most likely, means of conveying the 305 notification through the firewall (which would drive a requirement for 306 mixed text, binary content). 308 2.23 Machine Consumable Notification 310 Notifications which are intended for consumption by a program only, such 311 as an IPP Client. Machine Consumable notifications may not contain human 312 readable information. Do we need both human and machine? Machine 313 readable is intended for application to application only. The 314 Notification Recipient could process the machine readable report into 315 human readable format. 317 2.24 Mixed Notification 319 A mixed notification may contain both human readable and human readable 320 information. 321 ISSUE: Do we need mixed? 323 Mail Services, DNS, Instant Messaging, Distributions lists etc.? 325 3 Requirements 327 The following requirements are intended to be met by the IPP 328 Notification specification. 330 1.The specification must indicate which of these requirements are 331 MANDATORY and which are OPTIONAL for a conforming implementation. 333 2.It must be possible to support the IPP Notification interface using 334 third party notification services that exist today or that may be 335 standardized in the future. 337 3.A Job Submitting End User must be able to specify zero or more 338 notification recipients when submitting a print job. But don't expect 339 a submitter to be able to circumvent out of band subscriptions. 341 4.When specifying a notification recipient, a Notification Subscriber 342 must be able to specify one or more notification events for that 343 notification recipient. 345 5.When specifying a notification recipient, the Notification Subscriber 346 must be able to specify either immediate or queued notification for 347 that notification recipient. This may be explicit, or implied by the 348 method of delivery chosen by the Job Submitting End User. 350 6.When specifying a notification event, a Notification Subscriber must 351 be able to specify that zero or more notification attributes (or 352 attribute categories) be sent along with the notification, when that 353 event occurs. 355 7.Common delivery methods, e.g. email, must be supported. 357 8.There is no requirement for the IPP Printer receiving the print 358 request to validate the identity of an event recipient, nor the 359 ability of the system to deliver an event to that recipient as 360 requested (for example, if the event recipient is not at work today). 362 9.However, an IPP Printer must validate its ability to deliver an event 363 using the specified delivery scheme. If it does not support the 364 specified scheme, or the specified scheme is invalid for some reason, 365 then it should respond to the print request with an error condition. 367 10. There must be a class of IPP event notification schemes or methods 368 which can flow through corporate firewalls. However, an IPP printer 369 need not test to guarantee delivery of the notification through a 370 firewall before accepting a print job. 372 11. A mechanism must be provided for delivering a notification to the 373 submitting client when the delivery of an event notification to a 374 specified Notification Recipient fails. (Optional? Or not necessary?) 375 Fall back means of subscribers determining if notifications have 376 failed. I.e. polling? 378 12. There must be a mechanism for localizing human consumable 379 notifications by the Notification Source. 381 13. There must be a way to specify whether or not event delivery 382 requires acknowledgement back to the Event Source. 384 14. There must be a mechanism to indicate the quality of service for 385 delivery of event reports. The policy must include stopping the 386 Printer and allowing the Printer to continue, when delivery of the 387 event report is not acknowledged. ISSUE: Should that policy be 388 specified by the Notification Subscriber (and authorized by the 389 Printer) or by the administrator in configuring the Printer? 391 15. There must be a mechanism so that job independent subscriptions do 392 not become stale and do not require human intervention to remove 393 stale subscriptions. However, stale must not be the inability to 394 deliver a notification report, since temporary event delivery 395 problems must be tolerated. 397 4 Scenarios 399 1.I am sitting in my office and submit a print job to the printer down 400 the hall. I am in the same security domain as the printer and of 401 course, geographically near. I want to know immediately when my 402 print job will be completed (or if there is a problem) because the 403 document I am working on is urgent. I submit the print job with the 404 following attributes: 406 @ Notification Recipient - me 407 @ Notification Events - all 408 @ Notification Attributes - job-state-reason 409 @ Notification Type - immediate 411 2.I am working from home and submit a print job to the same printer as 412 in the previous example. However, since I am not at work, I cannot 413 physically get the print file or do anything with it. It can wait 414 until I get to work this afternoon. However, I'd like my secretary to 415 pick up the output and put it on my desk so it doesn't get lost or 416 miss-filed. I'd also like a queued notification sent to my email so 417 that when I get to work I can tell if there was a problem with the 418 print job. I submit a print job with the following attributes: 420 @ Notification Recipient - my secretary 421 @ Notification Events - print complete 422 @ Notification Type - immediate 424 @ Notification Recipient - me 425 @ Notification Events - print complete 426 @ Notification Attributes - impressions completed 427 @ Notification Type - queued 429 3.I am sitting in my office and submit a print job to a client at an 430 engineering firm we work with on a daily basis. The engineering form 431 is in Belgium. I would like my client to know when the print job is 432 complete, so that she can pick it up from the printer in her 433 building. It is important that she review it right away and get her 434 comments back to me. I submit the print job with the following 435 attributes: 437 @ Notification Recipient - client at engineering firm 438 @ Notification Events - print complete 439 @ Notification Type - immediate 440 @ Notification Language - French 442 4.I am in a hotel room and send a print job to a Kinko's store in the 443 town I am working in, in order to get a printed report for the 444 meeting I am attending in the morning. Since I'm going out to dinner 445 after I get this job submitted, an immediate notification won't do me 446 much good. However, I'd like to check in the morning before I drive 447 to the Kinko's store to see if the file has been printed. An email 448 notification is sufficient for this purpose. I submit the print job 449 with the following attributes: 451 @ Notification Recipient - me 452 @ Notification Events - print complete 453 @ Notification Type - email 455 5.I am printing a large, complex print file. I want to have some 456 immediate feedback on the progress of the print job as it prints. I 457 submit the print job with the following attributes: 459 @ Notification Recipient - me 460 @ Notification Type - immediate 461 @ Notification Events - all state transitions 462 @ Notification Attributes - impression completed 464 6.I am an operator and my duties is to keep the printer running. I 465 subscribe independently from a job submission so that my subscription 466 outlasts any particular job. I subscribe with the following 467 attributes: 469 @ Notification Recipient - me 470 @ Notification Type - immediate 471 @ Notification Events - all Printer state transitions 472 @ Notification Attributes - Printer state, printer state reasons, 473 device powering up, device powering down. 475 7.I am an accounting or audit application. I subscribe independently 476 from a job submission so that my subscription outlasts any particular 477 job. My subscription may persists across power cycles. I subscribe 478 with the following attributes: 480 @ Notification Recipient - me 481 @ Notification Type - immediate 482 @ Notification Events - job completion 483 @ Notification Attributes - impression completed, sheets completed, 484 time submitted, time started, time completed, job owner, job size 485 in octets, etc.