idnits 2.17.1 draft-ietf-ipp-notify-poll-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 16 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [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 36: '...on [ipp-ntfy] is an OPTIONAL extension...' RFC 2119 keyword, line 95: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 132: '...ecification" document defines OPTIONAL...' RFC 2119 keyword, line 174: '...that support the OPTIONAL IPP notifica...' RFC 2119 keyword, line 229: '...his document, it MUST support a REQUIR...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 703 has weird spacing: '...for the purpo...' -- 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 (March 8, 2000) is 8814 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: 'RFC2567' is mentioned on line 79, but not defined == Missing Reference: 'RFC2568' is mentioned on line 81, but not defined == Missing Reference: 'RFC2569' is mentioned on line 85, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 Carl-Uno Manros 4 Tom Hastings 5 Robert Herriot 6 Xerox Corp. 7 Harry Lewis 8 IBM, Corp. 9 March 8, 2000 10 Internet Printing Protocol (IPP): 11 The 'ipp' Notification Polling Method 13 Copyright (C) The Internet Society (2000). All Rights Reserved. 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of [rfc2026]. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed as 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The IPP notification specification [ipp-ntfy] is an OPTIONAL extension 37 to IPP/1.0 and IPP/1.1 that requires the definition of one or more 38 delivery methods for dispatching Event Notification reports to 39 Notification Recipients. This document describes the semantics and 40 syntax of the 'ipp' event Notification delivery method. For this 41 delivery method, the client uses an explicit IPP Get-Notifications 42 Printer operation in order to request (pull) Event Notifications from 43 the IPP Printer. 45 When a Printer supports the 'ipp' delivery method, it holds each Event 46 Notification for a certain length of time. The amount of time is called 47 the "event-lease time".. A Printer may assign the same event-lease time 48 to each Event Notification or different times. If a Notification 49 Recipient does not want to miss Event Notifications, the time between 50 consecutive pollings of Subscription objects must be less than the 51 event-lease time of the events that occur between pollings. The Get- 52 Notifications request indicates whether the client wants to receive all 53 pending event Notifications for (1) any Subscription for which the 54 client is the owner, (2) any Subscription associated with a Job, (3) any 55 Subscription with a particular delivery-method URL, or (4) an identified 57 Expires: September 8, 2000 58 set of Subscription objects. With the Get-Notifications operation, the 59 Printer returns all existing Event Notifications along with two time 60 intervals. One specifies the minimum time at which event-leases of 61 future events of the type returned will begin to expire and the other 62 specifies the recommended interval for the client to wait before sending 63 the next Get-Notifications operation. The second time interval is less 64 than the first. 66 The Printer may keep the channel open if the recommended interval is 67 sufficiently short, but in any case the client performs a new Get- 68 Notifications operation each time it wants more Event Notifications. 69 Since the time interval between consecutive client requests is normally 70 less than the event-lease time, consecutive responses will normally 71 contain some Event Notifications that are identical. The youngest ones 72 in the previous response will become the oldest in the next response. 73 The client is expected to filter out these duplicates, which is easy to 74 do because of the sequence number in each Event Notification. 76 Expires: September 8, 2000 77 The full set of IPP documents includes: 79 Design Goals for an Internet Printing Protocol [RFC2567] 80 Rationale for the Structure and Model and Protocol for the Internet 81 Printing Protocol [RFC2568] 82 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 83 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 84 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 85 Mapping between LPD and IPP Protocols [RFC2569] 86 Internet Printing Protocol/1.0 & 1.1: Event Notification 87 Specification [ipp-ntfy] 89 The "Design Goals for an Internet Printing Protocol" document takes a 90 broad look at distributed printing functionality, and it enumerates 91 real-life scenarios that help to clarify the features that need to be 92 included in a printing protocol for the Internet. It identifies 93 requirements for three types of users: end users, operators, and 94 administrators. It calls out a subset of end user requirements that are 95 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 96 added to IPP/1.1. 98 The "Rationale for the Structure and Model and Protocol for the Internet 99 Printing Protocol" document describes IPP from a high level view, 100 defines a roadmap for the various documents that form the suite of IPP 101 specification documents, and gives background and rationale for the IETF 102 working group's major decisions. 104 The "Internet Printing Protocol/1.1: Model and Semantics" document 105 describes a simplified model with abstract objects, their attributes, 106 and their operations that are independent of encoding and transport. It 107 introduces a Printer and a Job object. The Job object optionally 108 supports multiple documents per Job. It also addresses security, 109 internationalization, and directory issues. 111 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 112 a formal mapping of the abstract operations and attributes defined in 113 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 114 rules for a new Internet MIME media type called "application/ipp". This 115 document also defines the rules for transporting over HTTP a message 116 body whose Content-Type is "application/ipp". This document defines a 117 new scheme named 'ipp' for identifying IPP printers and jobs. 119 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 120 insight and advice to implementers of IPP clients and IPP objects. It 121 is intended to help them understand IPP/1.1 and some of the 122 considerations that may assist them in the design of their client and/or 123 IPP object implementations. For example, a typical order of processing 124 requests is given, including error checking. Motivation for some of the 125 specification decisions is also included. 127 The "Mapping between LPD and IPP Protocols" document gives some advice 128 to implementers of gateways between IPP and LPD (Line Printer Daemon) 129 implementations. 131 Expires: September 8, 2000 132 The "Event Notification Specification" document defines OPTIONAL 133 operations that allow a client to subscribe to printing related events. 134 Subscriptions include "Per-Job subscriptions" and "Per-Printer 135 subscriptions". Subscriptions are modeled as Subscription objects. 136 Four other operations are defined for subscription objects: get 137 attributes, get subscriptions, renew a subscription, and cancel a 138 subscription. 140 Expires: September 8, 2000 141 Table of Contents 143 1 Introduction......................................................6 145 2 Terminology.......................................................7 147 3 Model and Operation...............................................7 149 4 Get-Notifications operation.......................................8 150 4.1GET-NOTIFICATIONS REQUEST........................................9 151 4.2GET-NOTIFICATIONS RESPONSE......................................11 153 5 Extension to Print-Job, Print-URI, Create-Job, Create-Printer- 154 Subscription and Create-Printer-Subscription.........................12 155 5.1RESPONSE........................................................12 157 6 Encoding.........................................................13 159 7 IANA Considerations..............................................13 161 8 Internationalization Considerations..............................14 163 9 Security Considerations..........................................14 165 10 References.......................................................14 167 11 Authors' Addresses...............................................15 169 12 Full Copyright Statement.........................................15 171 Expires: September 8, 2000 172 1 Introduction 174 IPP printers that support the OPTIONAL IPP notification extension [ipp- 175 ntfy] either a) accept, store, and use notification subscriptions to 176 generate Event Notification reports and implement one or more delivery 177 methods for notifying interested parties, or b) support a subset of 178 these tasks and farm out the remaining tasks to a Notification Delivery 179 Service. The 'ipp' Event Notification delivery method specified in this 180 document defines a Get-Notifications operation that may be used in a 181 variety of notification scenarios. Its primary intended use is for 182 clients that want to be Notification Recipients. However, the Get- 183 Notifications operation may also be used by Notification Delivery 184 Services for subsequent distribution to the Ultimate Notification 185 Recipients. 187 When a Printer supports the 'ipp' delivery method, it holds each Event 188 Notification for a certain length of time. The amount of time is called 189 the "event-lease time". A Printer may assign the same event-lease time 190 to each event or different times. If a Notification Recipient does not 191 want to miss Event Notifications, the time between consecutive pollings 192 of Subscription objects must be less than the event-lease time of the 193 Event Notifications that occur between pollings. The Get-Notifications 194 request indicates whether the client wants to receive all pending Event 195 Notifications for (1) any Subscription for which the client is the 196 owner, (2) any Subscription associated with a particular Job, (3) any 197 Subscription with a particular notification recipient URL, or (4) an 198 identified set of Subscription objects. With the Get-Notifications 199 operation, the Printer returns all existing Event Notifications along 200 with two time intervals. One specifies the minimum time at which event- 201 leases of future events of the type returned will begin to expire and 202 the other specifies the recommended interval for the client to wait 203 before sending the next Get-Notifications operation. The second time 204 interval is less than the first. 206 The Printer may keep the channel open if the recommended interval is 207 sufficiently short, but in any case the client performs a new Get- 208 Notifications operation each time it wants more Notifications. Since the 209 time interval between consecutive client requests is normally less than 210 the event-lease time, consecutive responses will normally contain some 211 events that are identical. The youngest ones in the previous response 212 will become the oldest in the next response. The client is expected to 213 filter out these duplicates, which is easy to do because of the sequence 214 number in each Notification. The reason for not removing the 215 Notifications from the Subscription object with every Get-Notifications 216 request, is so that multiple Notification Recipients can be polling the 217 same subscription object and so the Get-Notification operation satisfies 218 the rule of idempotency. The former is useful if someone is logged in 219 to several desktops at the same time and wants to see the same events at 220 both places. The latter is useful if the network loses the response. 222 Expires: September 8, 2000 223 2 Terminology 225 This section defines the following additional terms that are used 226 throughout this document: 228 REQUIRED: if an implementation supports the extensions described in 229 this document, it MUST support a REQUIRED feature. 230 OPTIONAL: if an implementation supports the extensions described in 231 this document, it MAY support an OPTIONAL feature. 232 Notification Recipient - See [ipp-ntfy] 233 Subscription object - See [ipp-ntfy] 234 Ultimate Notification Recipient - See [ipp-ntfy] 236 3 Model and Operation 238 In the IPP Notification Model [ipp-ntfy], one or more Per-Job 239 Subscriptions can be supplied in the Job Creation operation or 240 OPTIONALLY as subsequent Create-Job-Subscription operations; one Per- 241 Printer Subscription can be supplied in the Create-Printer operation. 242 The client that creates these Subscription objects becomes the owner of 243 the Subscription object. 245 When creating each Subscription object, the client supplies the "notify- 246 recipient" (uri) attribute. The "notify-recipient" attribute specifies 247 both a single Notification Recipient that is to receive the 248 Notifications when subsequent events occur and the method for 249 Notification delivery that the IPP Printer is to use. For the 250 Notification delivery method defined in this document, the scheme of the 251 URL is 'ipp' and the host SHOULD be the client host's URL. In addition, 252 the URL MAY contains a path to allow for applications to have a unique 253 URL. 255 ISSUE 1: The 'ipp' is a convenient reuse of 'ipp', but does it imply the 256 existence of a print service at each client that is not a reality? 258 For most Notification delivery methods, a Printer sends Event 259 Notifications to the delivery URL and the Printer does not perform any 260 authentication or authorization with the receivers of the Event 261 Notifications. For the Notification delivery method defined in this 262 document, the client requests Event Notifications from the Printer via a 263 Get-Notifications operation, and the Printer performs the same 264 authentication and authorization as it does for the Get-Job-Attributes 265 operation. That is, a Printer MAY allow a client to perform a Get- 266 Notifications operation on any Subscription object or it MAY restrict 267 access as follows. Any client that is authenticated (1) as an operator 268 or administrator or (2) as the owner of the Subscription object can 269 initiate a Get-Notifications operation for that Subscription object. 271 Because a Printer has to wait for a client to request Event 272 Notifications for the 'ipp' delivery method, any Printer that supports 273 the 'ipp' notification delivery method MUST hold each Event Notification 274 at least for the event-lease time that it advertises to clients. With 275 this rule, a single user can login at different places, say his/her 276 office, the lab, and/or several desktops in the same room, and receive 278 Expires: September 8, 2000 279 the same Event Notifications from a single Subscription object. In 280 addition, a client that gets no response, perhaps because of a network 281 failure, can perform the Get-Notifications operations two or more times 282 in quick succession and get the same results except for a few newly 283 arrived Event Notifications and a few old Event Notifications whose 284 event-leases have expired. 286 The event-lease time assigned to Event Notifications MAY be different 287 for each implementation. Furthermore, a particular implementation MAY 288 assign different event-lease times to each Event Notification. If a 289 Printer assigns different event-lease times to each Event Notification, 290 the event-lease time returned with Get-Notifications MUST be a value 291 that ensures a client will not miss future Event Notifications. 293 The client issues a Get-Notifications Printer operation in order to 294 initiate the delivery of the pending Notifications held by the Printer 295 for the Subscription objects requested. The client can indicate in the 296 Get-Notifications request whether it wants to receive all pending 297 Notifications for: 299 1) any existing Subscription objects for which the client is the 300 owner, 302 2) any existing Subscription objects whose notification-recipient is a 303 specified URL 305 3) any existing Subscription objects associated with a job-id or 307 4) particular Subscription object(s) (for which it MUST be the owner 308 or have read-access rights). 310 In any case, the Notifications are returned in a response to the Get- 311 Notifications request. 313 If the client requests a persistent channel, then the Printer MAY keep 314 the channel open. Either the client or the IPP Printer can disconnect 315 the HTTP connection. 317 4 Get-Notifications operation 319 This REQUIRED operation allows the client to request that pending Event 320 Notifications be delivered as a response to this request. The client 321 MUST be the owner or have read-access rights of the Subscription objects 322 that are involved and the delivery method specified when the 323 Subscription objects were created MUST be ipp'. When the Printer 324 creates a Subscription Object, either with a Job Creation operation or 325 with a Create-Printer-Subscription or Create-Job-Subscription operation 326 and a subscription object contains the 'ipp' value for the "notify- 327 recipient" operation attribute, the Printer returns the event-lease time 328 for Events and the recommended time interval before the client to 329 performs the next Get-Notifications operation. The client SHOULD 330 perform a Get-Notifications operation at about the recommended interval 332 Expires: September 8, 2000 333 and if the Printer receives the Get-Notifications before the event-lease 334 time has elapsed, it MUST have all of the Notifications since the 335 previous Get-Notification operation or the Subscription object creation, 336 whichever was most recent. 338 Issue 2: Now that the Get-Notification operation does not affect the 339 Event Notifications in the Printer, it should not require write access 340 to access them. 342 The IPP Printer MUST accept the request in any state (see [ipp-mod] 343 "printer-state" and "printer-state-reasons" attributes) and MUST remain 344 in the same state with the same "printer-state-reasons". 346 Access Rights: The authenticated user (see [ipp-mod] section 8.3) 347 performing this operation must either be the Subscription object owner 348 (as determined when the Subscription object was created by the Job 349 Creation operation, Create-Job-Subscription, or Create-Printer- 350 Subscription operations) or an operator or administrator of the Printer 351 object (see [ipp-mod] Sections 1 and 8.5). Otherwise, the IPP object 352 MUST reject the operation and return: 'client-error-forbidden', 'client- 353 error-not-authenticated', or 'client-error-not-authorized' as 354 appropriate. 356 Issue 3: Is it possible for this operation to have an option that causes 357 it to delay completing its response? It would initially returns all 358 existing Event Notifications. Then it would return additional 359 notifications as they occur for some period of time. The client would 360 receive these Event Notifications as they occur. The question is 361 whether http servers or proxies would behave in this manner so that the 362 client would get the Event Notifications without delay after they are 363 sent by the http server? It has been suggested that the Printer send 364 each burst of Event Notifications be in a separate message body where 365 each message body is part of a multipart MIME content-type. 367 4.1 Get-Notifications Request 369 The following groups of attributes are part of the Get-Notifications 370 Request: 372 Group 1: Operation Attributes 374 Natural Language and Character Set: 375 The "attributes-charset" and "attributes-natural-language" 376 attributes as described in [ipp-mod] section 3.1.4.1. 378 Target: 379 The "printer-uri" (uri) operation attribute which is the target for 380 this operation as described in [ipp-mod] section 3.1.5. 382 Requesting User Name: 383 The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied 384 by the client as described in [ipp-mod] section 8.3. 386 Expires: September 8, 2000 388 "notification-recipient" (url): 389 The client OPTIONALLY supplies this attribute. The Printer object 390 MUST support this attribute. It is a URL that identifies one or 391 more Subscription objects for which Event Notifications are being 392 requested. If the client supplies this attribute, but no 393 notification-recipients are found, the IPP Printer MUST return the 394 'client-error-not-found' status code. If some are found and others 395 are not, the ones that are not found are return in the Unsupported 396 Attributes. By definition, if a notification-recipient URL 397 exists, there must be at least one Subscription object. 399 Note: this attribute allows a subscribing client to pick URLs that 400 are unique, e.g. the client's own URL or a friend's URL, which in 401 both cases is likely the URL of the person's host. An application 402 could make a URL unique for each application if it wants. If a 403 client uses such a URL as the value of this attribute, the client 404 gets event Notifications for all Subscription objects whose 405 "notification-recipient" is the specified URL. This mechanism is 406 more general than getting all subscriptions owned by a client. It 407 allows clients who didn't subscribe to get Event Notifications 408 without knowing job-ids or subscription-ids. 410 ISSUE 4: The "notification-recipient" option allows a client to group 411 multiple Subscription-ids with a single URL. A client might decide to 412 use the same URL for all subscriptions for a user, or it might have a 413 separate URL for each client program. In addition a client might use an 414 URL belonging to some other known user and let that user access Event 415 Notifications using that URL. Is the above option useful? 417 "subscription-ids" (1setOf integer(1:MAX)): 418 The client OPTIONALLY supplies this attribute. The Printer object 419 MUST support this attribute. It is an integer value that identifies 420 one or more Subscription objects for which Event Notifications are 421 being requested. If the client supplies this attribute, but none 422 of the Subscription objects are found, the IPP Printer MUST return 423 the 'client-error-not-found' status code. If some are found and 424 others are not, the ones that are not found are return in the 425 Unsupported Attributes. 427 "job-ids" (1setOf integer(1:MAX)): 428 The client OPTIONALLY supplies this attribute. The Printer object 429 MUST support this attribute. It is an integer value that identifies 430 one or more job-ids. These job-ids identify the Subscription 431 objects for which Event Notifications are being requested. If the 432 client supplies this attribute, but no Jobs are found, the IPP 433 Printer MUST return the 'client-error-not-found' status code. If 434 some are found and others are not, the ones that are not found are 435 returned in the Unsupported Attributes. It is not an error if 436 there are no Subscription objects for a Job. 438 Expires: September 8, 2000 439 If the client supplies none of the last three attributes described 440 for this operation, then the IPP Printer returns Event 441 Notifications for all Subscription objects for which the client is 442 the owner and the "notify-recipients" attribute is 'ipp'. It is 443 not an error if there are currently no Subscription objects for 444 this client; the response then contains no Notifications. 446 ISSUE 5: Does the mechanism described in the above paragraph describe a 447 useful option that "notification-recipient" alone cannot do? Should this 448 case be an error instead? 450 If a client supplies more than one of the last three attributes 451 described for this operation, the Printer returns Event 452 Notifications for all Subscription objects specified by all 453 attributes. If these attributes describe duplicate Event 454 Notifications, the Printer MAY remove them. 456 ISSUE 6: Is it better if "notification-recipient" is the only way to 457 request Event Notification? If so, this behaves more like other 458 notification delivery methods where a recipient receives those and only 459 those events with its delivery URL. Furthermore, if there is a single 460 mechanism of "notification-recipient" for a client to specify Event 461 Notifications, a Printer can better optimize event-leases because it 462 knows which events will be accessed together. If client can specify 463 subscription-ids, each request can contain a different mix of 464 subscription-ids. 466 4.2 Get-Notifications Response 468 The Printer object returns either an immediate error response or a 469 successful response with status code: 'successful-ok' when the first 470 event occurs, i.e., when the Printer delivers the first Event 471 Notification. 473 Group 1: Operation Attributes 475 Status Message: 476 In addition to the REQUIRED status code returned in every response, 477 the response OPTIONALLY includes a "status-message" (text(255)) 478 and/or a "detailed-status-message" (text(MAX)) operation attribute 479 as described in [ipp-mod] sections 13 and 3.1.6. 481 Natural Language and Character Set: 482 The "attributes-charset" and "attributes-natural-language" 483 attributes as described in [ipp-mod] section 3.1.4.2. 485 "recommended-time-interval" (integer(0:MAX)): 486 The value of this attribute is the recommended number of seconds 487 that SHOULD elapse before the client performs this operation again 488 for these Subscription objects. A client MAY perform this operation 490 Expires: September 8, 2000 491 at any time, and a Printer MUST respond with all existing 492 Notifications. A client observes this value in order to be a "good 493 network citizen". The value that a Printer returns for this 494 attribute MUST NOT exceed 80% of the "event-lease-time-interval" in 495 order to give a client plenty of time to perform another Get- 496 Notifications operation before the event-lease of the oldest Event 497 Notifications expire. 499 "event-lease-time-interval" (integer(0:MAX)): 500 The value of this attribute is the minimum number of seconds until 501 the event-lease expiration time for all future Event Notifications 502 associated with the Subscription objects generating the requested 503 Event Notifications. Thus this number is the maximum number of 504 seconds that elapses before this client SHOULD issue this operation 505 again for these Subscription objects. A Printer MUST preserve all 506 Notifications that occur for the number of seconds specified by 507 this attribute starting at the time it is sent in a response. A 508 client MAY perform this operation at any time, and a Printer MUST 509 respond with all existing Event Notifications. If a Printer 510 receives this operation after this time interval, it MAY have 511 discarded some Notifications since the last response. 513 Group 2: Unsupported Attributes 515 See [ipp-mod] section 3.1.7 for details on returning Unsupported 516 Attributes. 518 If the "subscription-ids" attribute contained subscription-ids that 519 do not exist, the Printer returns them in this group as value of 520 the "subscription-ids" attribute. 522 Group 3 through N: Notification Attributes 524 The Printer object responds with one Event Notification per Group 525 for each Notification that meets the criteria specified by the 526 request.(see [ipp-ntfy]). 528 5 Extension to Print-Job, Print-URI, Create-Job, Create-Printer- 529 Subscription and Create-Printer-Subscription 531 5.1 Response 533 When Print-Job, Print-URI or Create-Job contains a "job-notify" 534 attribute and the "notify-recipient" is 'ipp', the response contains two 535 additional Operation Attributes that pertain to subscriptions. 537 When Create-Job-Subscription or Create-Printer-Subscription operation 538 contains a "notify-recipient" that is 'ipp', the response contains two 539 additional Operation Attributes that pertain to subscriptions. 541 Group 1: Operation Attributes 543 Expires: September 8, 2000 544 "recommended-time-interval" (integer(0:MAX)): 545 The value of this attribute is the recommended number of seconds 546 that SHOULD elapse before the client SHOULD perform the Get- 547 Notification operation for the first time with any Subscription 548 objects returned with this job. A client MAY perform the Get- 549 Notification operation at any time, and a Printer MUST respond with 550 all existing Notifications. A client observes this value in order 551 to be a "good network citizen". The value that a Printer returns 552 for this attribute MUST NOT exceed 80% of the "event-lease-time- 553 interval" in order to give a client plenty of time to perform 554 another Get-Notifications operation before the event-lease of the 555 oldest events expire. 557 "event-lease-time-interval" (integer(0:MAX)): 558 The value of this attribute is the minimum number of seconds until 559 the event-lease expiration time for all future Event Notifications 560 associated with the Subscription objects generating the requested 561 Event Notifications. Thus this number is the maximum number of 562 seconds that elapses before a client SHOULD perform the Get- 563 Notification operation for the first time with any Subscription 564 objects returned with this job. A Printer MUST preserve all 565 Notifications that occur for the number of seconds specified by 566 this attribute starting at the time it is sent in a response. A 567 client MAY perform the Get-Notification operation at any time, and 568 a Printer MUST respond with all existing Event Notifications. If a 569 Printer receives a Get-Notification operation after this time 570 interval, it may have discarded some Notifications since the last 571 response. 573 6 Encoding 575 The operation-id assigned for the Get-Notification operation is: 577 0x00?? 579 and should be added to the next version of [ipp-mod] section 4.4.15 580 "operations-supported". 582 This notification delivery method uses the IPP transport and encoding 583 [ipp-pro] for the Get-Notifications operation with one extension: 585 notification-attributes-tag = %x07 ; tag of 7 587 7 IANA Considerations 589 There is nothing to register. 591 Expires: September 8, 2000 592 8 Internationalization Considerations 594 With the 'ipp' method defined in this document, the client cannot 595 request the Human Consumable form by supplying the "notify-format" 596 operation attribute (see [ipp-ntfy]). The only supported value for this 597 delivery method is "application/ipp". Therefore, the IPP Printer does 598 not have to perform any localization with this notification delivery 599 method. However, the client when it receives the Get-Notifications 600 response is expected to localize the attributes that have the 'keyword' 601 attribute syntax according to the charset and natural language requested 602 in the Get-Notifications request. 604 9 Security Considerations 606 The IPP Model and Semantics document [ipp-mod] discusses high level 607 security requirements (Client Authentication, Server Authentication and 608 Operation Privacy). Client Authentication is the mechanism by which the 609 client proves its identity to the server in a secure manner. Server 610 Authentication is the mechanism by which the server proves its identity 611 to the client in a secure manner. Operation Privacy is defined as a 612 mechanism for protecting operations from eavesdropping. 614 Unlike other Event Notification delivery methods in which the IPP 615 Printer initiates the Event Notification, with the method defined in 616 this document, the Notification Recipient is the client who issues the 617 Get-Notifications operation. Therefore, there is no chance of "spam" 618 notifications with this method. Furthermore, such a client can close 619 down the HTTP channel at any time, and so can avoid future unwanted 620 Event Notifications at any time. 622 10 References 624 [ipp-mod] 625 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 626 "Internet Printing Protocol/1.1: Model and Semantics", , March 1, 2000. 629 [ipp-ntfy] 630 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 631 Bergman, R., "Internet Printing Protocol/1.1: IPP Event 632 Notification Specification", , 633 March 8, 2000. 635 [ipp-pro] 636 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 637 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 638 05.txt, March 1, 2000. 640 [rfc2026] 641 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 642 2026, October 1996. 644 Expires: September 8, 2000 646 [RFC2616] 647 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 648 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 649 RFC 2616, June 1999. 651 11 Authors' Addresses 653 Carl-Uno Manros 654 Xerox Corporation 655 701 Aviation Blvd. 656 El Segundo, CA 90245 658 Phone: 310-333- 659 Fax: 310-333-5514 660 e-mail: manros@cp10.es.xerox.com 662 Tom Hastings 663 Xerox Corporation 664 737 Hawaii St. ESAE 231 665 El Segundo, CA 90245 667 Phone: 310-333-6413 668 Fax: 310-333-5514 669 e-mail: hastings@cp10.es.xerox.com 671 Robert Herriot 672 Xerox Corp. 673 3400 Hill View Ave, Building 1 674 Palo Alto, CA 94304 676 Phone: 650-813-7696 677 Fax: 650-813-6860 678 e-mail: robert.herriot@pahv.xerox.com 680 Harry Lewis 681 IBM 682 P.O. Box 1900 683 Boulder, CO 80301-9191 685 Phone: (303) 924-5337 686 FAX: 687 e-mail: harryl@us.ibm.com 689 12 Full Copyright Statement 691 Copyright (C) The Internet Society (2000). All Rights Reserved. 693 This document and translations of it may be copied and furnished to 694 others, and derivative works that comment on or otherwise explain it or 695 assist in its implementation may be prepared, copied, published and 696 distributed, in whole or in part, without restriction of any kind, 698 Expires: September 8, 2000 699 provided that the above copyright notice and this paragraph are included 700 on all such copies and derivative works. However, this document itself 701 may not be modified in any way, such as by removing the copyright notice 702 or references to the Internet Society or other Internet organizations, 703 except as needed for the purpose of developing Internet standards in 704 which case the procedures for copyrights defined in the Internet 705 Standards process must be followed, or as required to translate it into 706 languages other than English. 708 The limited permissions granted above are perpetual and will not be 709 revoked by the Internet Society or its successors or assigns. 711 This document and the information contained herein is provided on an "AS 712 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 713 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 714 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 715 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 716 FITNESS FOR A PARTICULAR PURPOSE. 718 Expires: September 8, 2000