INTERNET DRAFT Roger K deBry
<draft-ietf-ipp-not-00.txt><draft-ietf-ipp-not-01.txt> Utah Valley State College Harry Lewis IBM Corporation February 19, 1998 1Tom Hastings Xerox Corporation June 24, 1999 Internet Printing Protocol/1.1: Requirements for IPP Notifications 2 3 4 5Copyright (C) The Internet Society (1999). All Rights Reserved. STATUS OF THIS MEMO 6 7This document is an Internet-Draft.Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working 8documents of the Internet Engineering Task Force (IETF), its areas, 9and its working groups. Note that other groups may also distribute 10working documents as Internet-Drafts. 11 12Internet-Drafts are draft documents alidvalid for a maximum of six months 13and may be updated, replaced, or obsoleted by other documents at any 14time. It is inappropriate to use Internet-Drafts as reference 15material or to cite them other than as "work''work in progress." 16 17 To learn theprogress.'' The list of current statusInternet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of any Internet-Draft, please check the 18 ''1id-abstracts.txt'' listing contained in the Internet- Drafts 19Internet-Draft 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 23can be accessed as http://www.ietf.org/shadow.html. ABSTRACT 24 25This document is one of a set of documents which together describe 26all aspects of a new Internet Printing Protocol (IPP). IPP is an 27application leellevel protocol that can be used for distributed printing 28on the Internet. There are multiple parts to IPP, but the primary 29architectural components are the Model, the Protocol and an interface 30to Directory Serices.Services. This document proidesprovides a statement of the 31requirements for notifications as part of an IPP Serice.Service. Some ISSUES are indicated in the text. The full 32set of IPP documents include: 33 34 RequirementsDesign Goals for an Internet Printing Protocol 35[RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568] Internet Printing Protocol/1.0: Model and Semantics 36[RFC2566] Internet Printing Protocol/1.0: Protocol Specification 37 RationaleEncoding and Transport [RFC2565] Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569] The 'Design Goals for an Internet Printing Protocol' document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the Structurefeatures that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0. The 'Rationale for the Structure and Model and Protocol 38for the Internet Printing Protocol 39 Expires August 19, 1998 [Page 1] INTERNET DRAFT Roger K deBry <draft-ietf-ipp-not-00.txt> IBM Corporation February 19, 1998 40 1.0 Scope 41 42 The scopeProtocol' document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of this requirements statement isIPP specifications, and gives background and rationale for end users. This 43the IETF working group's major decisions. The 'Internet Printing Protocol/1.0: Encoding and Transport' document does not address requirements specific to print 44 administrators or operators. Howeer, we fully expectis a formal mapping of the 45 notification mechanismsabstract operations and attributes defined in support ofthe requirements set 46 forth in thismodel document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called 'application/ipp'. The 'Internet Printing Protocol/1.0: Implementer's Guide' document gives insight and advice to be extendibleimplementers of IPP clients and IPP objects. It is intended to print administratorshelp them understand IPP/1.0 and 47 operators as well. This document describessome of the requirementsconsiderations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for 48 notificationssome of the specification decisions is also included. The 'Mapping between LPD and IPP Protocols' document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations. Table of Contents 1 Scope..............................................................3 2 Terminology........................................................3 3 Requirements.......................................................7 4 Scenarios..........................................................8 1 Scope The scope of this requirements statement is for client-serer, serer-printer,end users, print administrators and client-printer 49 connections 50 51 2.0operators. 2 Terminology 52 53It is necessary to define a set of terms in order to be able to 54clearly express the requirements for notification sericesservices in an IPP 55System. 56 572.1 Job Submitting End User 58 59A human end user who submits a print job to an IPP Printer. This 60person may or may not be within the same security domain as the 61Printer. This person may or may not be geographically near the 62printer. 63 642.2 Administrator A human user who established policy for and configures the print system 2.3 Operator A human user who carries out the policy established by the Administrator and controls the day to day running of the print system. 2.4 Job Submitting Application 65 66An application (for example a batch application), acting on behalf of 67an end user, which submits a print job to an IPP Printer. The 68application may or may not be within the same security domain as the 69Printer. This application may or may not be geographically near the 70printer. 71 72 2.32.5 Security Domain 73 74For the purposes of this discussion, the set of network components 75which can communicate without going through a proxy or firewall. A 76security domain may be geographically eryvery large, for example - 77anyplace within IBM.COM. 78 79 2.42.6 IPP Client 80 81The software component on the client system which implements the IPP 82protocol. 83 84 2.52.7 Job Recipient 85 86A human who is the ultimate consumer of the print job. In many cases 87this will be the same person as the Job Submitting End User, but this 88need not always be the case. For example, if I use IPP to print a 89document on a printer in a business partner's office, I am the Job 90Submitting End User, while the person I intend the document for in my Expires August 19, 1998 Page  INTERNET DRAFT Roger K deBry <draft-ietf-ipp-not-00.txt> IBM Corporation February 19, 1998 91business partner's office is the Job Recipient. Since one of the 92goals of IPP is to be able to print near the ultimate recipient of 93the printed output, we would normally expect the Job Recipient to be 94in the same security domain as, and geographically near the Printer. 95 Howeer,However, this may not always be the case. For example, I submit a 96print job across the Internet to a KinkoísKinko's print shop. I am both the 97Submitting end User and the Job Recipient, but I am neither near nor 98in the same security domain as the Printer. 99 100 2.62.8 Job Recipient Proxy 101 102A person acting on behalf of the Job Recipient. In particular, the 103Job Recipient Proxy physically picks up the printed document from the 104Printer, if the Job Recipient cannot perform that function. The Proxy 105is by definition geographically near and in the same security domain 106as the printer. For example, I submit a print job from home to be 107printed on a printer at work. IídI'd like my secretary to pick up the 108print job and put it on my desk. In this case, I am acting as both 109Job Submitting End User and Job Recipient. My secretary is acting as 110a Job Recipient Proxy. An issue2.9 Notification Subscriber A client that needsrequests the IPP Printer to send event reports to one or more Notification Recipients. A Notification Subscriber may be considered in the 111 notification architecturea Job Submitting End User or an End User, an Operator, or an Administrator that is the impact ofnot submitting a third party receiing 112 many unwanted notifications. 113 114 2.7job. 2.10 Notification Source The entity that sends notification events 2.11 Notification Recipient 115 116Any of: Job Submitting End User, Job Submitting Application, Job 117Recipient, or Job Recipient Proxy. 118 119 2.8Proxy or admin etc folks and their representatives or log file or accounting/audit application or other active or passive entities or President Clinton. Or Monica. 2.12 Notification Recipient Agent 120 121A program which receies eentsreceives events on behalf of the notification 122recipient. The agent may take some action on behalf of the recipient, 123forward the notification to the recipient iavia some alternatiealternative means 124(for example, page the recipient), or queue the notification for 125later retriealretrieval by the recipient. 126 127 2.9 Notification Eents 128 129 Any of the following constitute eents 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,2.13 Event A event is some occurrence (either expected or for eents that affectunexpected) within the 132 processingprinting system. Any of the following constitute events that end user's job. 133 134 -a Job Submitting End User can specify notifications be sent for: @ Any standard Printer MIB alert (i.e. deice eents that impact the 135 end user's job) 136 -device alerts) (critical and warning?) (state change notifications)? @ Job ReceiedReceived (transition from Unknown to Pending or Pending-held) 137 -Pending) @ 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 141Completed) Expires August 19, 1998 [Page 3] INTERNET DRAFT Roger K deBry <draft-ietf-ipp-not-00.txt> IBM Corporation February 19, 1998 142 -@ Job aborted (transition from Pending, Pending-held, Processing, 143or Processing-stopped to Aborted) 144 -@ Job canceled (transition from Pending, Pending-held, Processing, 145or Processing-held to Canceled) 146 147 2.10@ Other job state changes like 'paused', purged? @ Device problems on which the job is destine for @ Job (interpreter) issues 2.14 Event report When an event occurs, an event report is generated that fully describes the event (what the event was, where it occurred, when it occurred, etc.). Event reports are delivered to all the notification recipients that are subscribed to that event, if any. The event report is delivered to the address of the notification recipient using the notification delivery method defined in the subscription. However, an Event Report is sent ONLY if there is a corresponding subscription. 2.15 Notification Registration 148 149Subscription It should be possible for end users and operators to Register'subscribe' for notifications 150of certain types of eents. These include anyevents, independent of Job Submission. An end user or operator may subscribe for @ All Job Traps @ All Traps (Job and Printer) @ None (Reserves a slot in some limited stable of those described'notification hosts') ISSUE: Need to discuss granularity and categorization in 151the preceding section. 152 153 2.11context of anticipated event frequency 2.16 Notification Attributes 154 155IPP Objects (for example, a print job) from which notification are 156being sent may haehave attributes associated with them. A user may want 157to haehave one or more of these associated attributes returned along 158with a particular notification. In general, these may include any 159attribute associated with the object emitting the notification. 160Examples include: 161 162 number-of-intereningnumber-of-intervening jobs 163job-k-octets 164job-k-octets processed 165job impressions 166job-impressions-interpreted 167job-impressions-completed 168impressionsCompletedCurrentCopy (job MIB) 169sheetCompletedCopyNumber (job MIB) 170sheetsCompletedDocumentNumber (job MIB) 171Copies-requested 172Copy-type 173Output-destination 174Job-state-reasons 175 176 177 2.12Job ID Printer URI Subscription ID (for job independent subscription) 2.17 Notification Delivery Method (or Delivery Method for short) Event reports are delivered using a method, such as email, TCP/IP, etc. 2.18 Immediate Notification 178 179Notifications sent to the notification recipient or the notification 180 recipientísrecipient's agent in such a way that the notification arries 181arrives immediately , within the limits of common addressing, routing, 182network congestion and quality of serice. 183 184 2.13service. 2.19 Queued Notification 185 186Notifications which are not necessarily sent immediately, but are 187queued for delierydelivery by some intermediate network application, or for 188later retrieal.retrieval. Email with store and forward is an example of queued 189notification. 190 191 2.142.20 Notification withover Reliable Deliery 192 Expires August 19, 1998 [Page 4] INTERNET DRAFT Roger K deBry <draft-ietf-ipp-not-00.txt> IBM Corporation February 19, 1998 193Transport Notifications which are deliereddelivered by a reliable, sequenced deliery 194delivery of packets or character stream, with acknowledgment and retry, such 195that delierydelivery of the notification is guaranteed within some 196reasonable time limits. For example, if the notification recipient 197has logged off and gone home for the day, an immediate notification 198cannot be guaranteed to be deliered, eendelivered, even when sent over a reliable 199transport, because there is nothing there to catch it. Guaranteed 200 delierydelivery requires both queued notification and a reliable transport. 201If delierydelivery of the notification requires process to process 202communications, each session is managed in a reliable manner, 203assuring fully ordered, end-to-end deliery. 204 205 2.15delivery. 2.21 Notification withover Unreliable Deliery 206 207Transport Notifications are deliered iadelivered via the fundamental transport address and 208routing framework, but no acknowledgment or retry is required. 209Process to process communications, if inoled,involved, are unconstrained. 210 211 2.162.22 Human Consumable Notification 212 213Notifications which are intended to be consumed by human end users 214only. They contain no machine readable encodingsencoding of the eent.event. Email 215would be an example of a Human consumable notification. 216 217 2.17ISSUE: Do we need both human and machine or is machine sufficient? There is no intent to attempt to standardize human readable strings. Human readable is intended for certain protocols, like e-mail, though email can also convey machine readable MIME types as well using multipart/report. ISSUE: Is e-mail the only, or most likely, means of conveying the notification through the firewall (which would drive a requirement for mixed text, binary content). 2.23 Machine Consumable Notification 218 219Notifications which are intended for consumption by a program only, 220such as an IPP Client. Machine Consumable notifications may not 221contain human readable information. 222 223 2.18Do we need both human and machine? Machine readable is intended for application to application only. The Notification Recipient could process the machine readable report into human readable format. 2.24 Mixed Notification 224 225A mixed notification may contain both human readable and human 226readable information. 227 228 3.0ISSUE: Do we need mixed? Mail Services, DNS, Instant Messaging, Distributions lists etc.? 3 Requirements 229 230 3.1 AThe following requirements are intended to be met by the IPP Notification specification. 1.The specification must indicate which of these requirements are MANDATORY and which are OPTIONAL for a conforming implementation. 2.It must be possible to support the IPP Notification interface using third party notification services that exist today or that may be standardized in the future. 3.A Job Submitting End User must be able to specify zero or more 231notification recipients when submitting a print job. 232 233 3.2 WhenBut don't expect a submitter to be able to circumvent out of band subscriptions. 4.When specifying a notification recipient, a Job Submitting End 234 userNotification Subscriber must be able to specify one or more notification eentsevents for 235that notification recipient. 236 237 3.3 When5.When specifying a notification recipient, the Job Submitting End 238 UserNotification Subscriber must be able to specify either immediate or queued 239notification for that notification recipient. This may be 240explicit, or implied by the method of delierydelivery chosen by the Job 241Submitting End User. 242 Expires August 19, 1998 [Page 5] INTERNET DRAFT Roger K deBry <draft-ietf-ipp-not-00.txt> IBM Corporation February 19, 1998 243 3.4 When6.When specifying a notification eent,event, a Job Submitting End User 244Notification Subscriber must be able to specify that zero or more notification attributes 245(or attribute categories) be sent along with the notification, when that eentevent occurs. 246 247 3.5 Common deliery methods should7.Common delivery methods, e.g. email, must be utilized where they are 248 appropriate and meet the requirements expressed in this document. 249 250 3.6 Theresupported. 8.There is no requirement for the IPP Printer receiingreceiving the print 251request to alidatevalidate the identity of an eentevent recipient, nor the 252ability of the system to delierdeliver an eentevent to that recipient as 253requested (for example, if the eentevent recipient is not at work 254today). 255 256 3.7 Howeer,9.However, an IPP Printer must alidatevalidate its ability to deliver an 257 eentevent using the specified delierydelivery scheme. If it does not support 258the specified scheme, or the specified scheme is inalidinvalid for some 259reason, then it should respond to the print request with an error 260condition. 261 262 3.810. There must be a class of IPP eent notificationsevent notification schemes or methods which can flow 263through corporate firewalls. Howeer,However, an IPP printer need not test 264to guarantee delierydelivery of the notification through a firewall 265before accepting a print job. 266 267 3.911. A mechanism must be proidedprovided for delieringdelivering a notification to the 268submitting client when the delierydelivery of an eentevent notification to a 269specified Notification Recipient fails. 270 271 3.10(Optional? Or not necessary?) Fall back means of subscribers determining if notifications have failed. I.e. polling? 12. There must be a mechanism for localizing human consumable 272 notifications. 273 274 4.0notifications by the Notification Source. 13. There must be a way to specify whether or not event delivery requires acknowledgement back to the Event Source. 14. There must be a mechanism to indicate the quality of service for delivery of event reports. The policy must include stopping the Printer and allowing the Printer to continue, when delivery of the event report is not acknowledged. ISSUE: Should that policy be specified by the Notification Subscriber (and authorized by the Printer) or by the administrator in configuring the Printer? 15. There must be a mechanism so that job independent subscriptions do not become stale and do not require human intervention to remove stale subscriptions. However, stale must not be the inability to deliver a notification report, since temporary event delivery problems must be tolerated. 4 Scenarios 275 276 4.1 I1.I am sitting in my office and submit a print job to the printer 277down the hall. I am in the same security domain as the printer and 278of course, geographically near. I want to know immediately when 279my print job will be completed (or if there is a problem) because 280the document I am working on is urgent. I submit the print job 281with the following attributes: 282 283 -@ Notification Recipient - me 284 -@ Notification EentsEvents - all 285 -@ Notification Attributes - job-state-reason 286 -@ Notification Type - immediate 287 288 4.2 I2.I am working from home and submit a print job to the same printer 289as in the preiousprevious example. Howeer,However, since I am not at work, I 290cannot physically get the print file or do anything with it. It 291can wait until I get to work this afternoon. Howeer,However, I'd like my 292secretary to pick up the output and put it on my desk so it 293doesn't get lost or mis-filed.miss-filed. I'd also like a queued notification Expires August 19, 1998 [Page 6] INTERNET DRAFT Roger K deBry <draft-ietf-ipp-not-00.txt> IBM Corporation February 19, 1998 294sent to my email so that when I get to work I can tell if there 295was a problem with the print job. I submit a print job with the 296following attributes: 297 298 -@ Notification Recipient - my secretary 299 -@ Notification EentsEvents - print complete 300 -@ Notification Type - immediate 301 302 -@ Notification Recipient - me 303 -@ Notification EentsEvents - print complete 304 -@ Notification Attributes - impressions completed 305 -@ Notification Type - queued 306 307 4.3 I3.I am sitting in my office and submit a print job to a client at 308an engineering firm we work with on a daily basis. The engineering 309form is in Belgium. I would like my client to know when the print 310job is complete, so that she can pick it up from the printer in 311her building. It is important that she reiewreview it right away and 312get her comments back to me. I submit the print job with the 313following attributes: 314 315 -@ Notification Recipient - client at engineering firm 316 -@ Notification EentsEvents - print complete 317 -@ Notification Type - immediate 318 -@ Notification Language - French 319 320 4.4 I4.I am in a hotel room and send a print job to a KinkoísKinko's store in 321the town I am working in, in order to get a printed report for the 322meeting I am attending in the morning. Since I'm going out to 323dinner after I get this job submitted, an immediate notification 324 wonítwon't do me much good. Howeer, IídHowever, I'd like to check in the morning 325before I driedrive to the KinkoísKinko's store to see if the file has been 326printed. An email notification is sufficient for this purpose. I 327submit the print job with the following attributes: 328 329 -@ Notification Recipient - me 330 -@ Notification EentsEvents - print complete 331 -@ Notification Type - email 332 333 4.5 I5.I am printing a large, complex print file. I want to haehave some 334immediate feedback on the progress of the print job as it prints. 335I submit the print job with the following attributes: 336 337 -@ Notification Recipient - me 338 -@ Notification Type - immediate 339@ Notification Events - all state transitions @ Notification Attributes - impression completed 6.I am an operator and my duties is to keep the printer running. I subscribe independently from a job submission so that my subscription outlasts any particular job. I subscribe with the following attributes: @ Notification Recipient - me @ Notification Type - immediate @ Notification EentsEvents - all Printer state transitions 340@ Notification Attributes - Printer state, printer state reasons, device powering up, device powering down. 7.I am an accounting or audit application. I subscribe independently from a job submission so that my subscription outlasts any particular job. My subscription may persists across power cycles. I subscribe with the following attributes: @ Notification Recipient - me @ Notification Type - immediate @ Notification Events - job completion @ Notification Attributes - impression completed 341 Expires August 19, 1998 [Page 7] INTERNET DRAFT Roger K deBry <draft-ietf-ipp-not-00.txt> 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 firstname.lastname@example.org Expires August 19, 1998 [Page 8]completed, sheets completed, time submitted, time started, time completed, job owner, job size in octets, etc.