idnits 2.17.1 draft-ietf-ipp-notify-get-01.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 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 the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 18) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 13 Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 11 IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 385 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [RFC2119], [RFC2717], [RFC2910], [RFC2911], [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 85: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 237: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 238: '... NOT, MAY, NEED NOT, and OPTION...' RFC 2119 keyword, line 262: '... client SHOULD choose a value f...' RFC 2119 keyword, line 266: '...urs, the Printer MUST generate an Even...' (65 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 331 has weird spacing: '...ication a pu...' == Line 357 has weird spacing: '...ansport tra...' == Line 361 has weird spacing: '...elivery tran...' == Line 895 has weird spacing: '...ent who s th...' == Line 968 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 (November 16, 2000) is 8561 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? 'RFC2567' on line 69 looks like a reference -- Missing reference section? 'RFC2568' on line 71 looks like a reference -- Missing reference section? 'RFC2911' on line 922 looks like a reference -- Missing reference section? 'RFC2910' on line 918 looks like a reference -- Missing reference section? 'RFC2569' on line 75 looks like a reference -- Missing reference section? 'RFC2616' on line 913 looks like a reference -- Missing reference section? 'RFC2119' on line 241 looks like a reference -- Missing reference section? 'RFC2717' on line 871 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Robert Herriot (editor) 3 Xerox Corp. 4 Carl Kugler 5 IBM, Corp. 6 Harry Lewis 7 IBM, Corp. 8 November 16, 2000 9 Internet Printing Protocol (IPP): 10 The 'ippget' Delivery Method for Event Notifications 12 Copyright (C) The Internet Society (2000). All Rights Reserved. 14 Status of this Memo: 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of [rfc2026]. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed as 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The notification extension document [ipp-ntfy] defines operations that 36 a client can perform in order to create Subscription Objects in a 37 Printer and carry out other operations on them. A Subscription Object 38 represents a Subscription abstraction. The Subscription Object 39 specifies that when one of the specified Events occurs, the Printer 40 sends an asynchronous Event Notification to the specified Notification 41 Recipient via the specified Delivery Method (i.e., protocol). 43 The notification extension document [ipp-ntfy] specifies that each 44 Delivery Method is defined in another document. This document is one 45 such document, and it specifies the 'ippget' delivery method. 47 The 'ippget' Delivery Method is a 'pull and push' Delivery Method. That 48 is, the Printer saves Event Notification for a period of time and 49 expects the Notification Recipient to fetch the Event Notifications 50 (the pull part). The Printer continues to send Event Notifications to 51 the Notification Recipient as Events occur (the push part) if the 52 client has selected the option to wait for additional Event 53 Notifications. 55 When a Printer supports this Delivery Method, it holds each Event 56 Notification for an amount of time, called the Event Notification Lease 57 Time. 59 When a Notification Recipient wants to receive Event Notifications, it 60 performs an IPP operation called 'Get-Notifications', which this 61 document defines. This operation causes the Printer to return all Event 62 Notifications held for the Notification Recipient. If the Notification 63 Recipient has selected the option to wait for additional Event 64 Notifications, the Printer continues sending Event Notifications to the 65 Notification Recipient as additional Events occur. 67 The basic set of IPP documents includes: 69 Design Goals for an Internet Printing Protocol [RFC2567] 70 Rationale for the Structure and Model and Protocol for the Internet 71 Printing Protocol [RFC2568] 72 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 73 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 74 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 75 Mapping between LPD and IPP Protocols [RFC2569] 76 Internet Printing Protocol/1.0 & 1.1: IPP Event Notification 77 Specification [ipp-ntfy] 79 The "Design Goals for an Internet Printing Protocol" document takes a 80 broad look at distributed printing functionality, and it enumerates 81 real-life scenarios that help to clarify the features that need to be 82 included in a printing protocol for the Internet. It identifies 83 requirements for three types of users: end users, operators, and 84 administrators. It calls out a subset of end user requirements that 85 are satisfied in IPP/1.0. A few OPTIONAL operator operations have been 86 added to IPP/1.1. 88 The "Rationale for the Structure and Model and Protocol for the 89 Internet Printing Protocol" document describes IPP from a high level 90 view, defines a roadmap for the various documents that form the suite 91 of IPP specification documents, and gives background and rationale for 92 the IETF working group's major decisions. 94 The "Internet Printing Protocol/1.1: Model and Semantics" document 95 describes a simplified model with abstract objects, their attributes, 96 and their operations that are independent of encoding and transport. 97 It introduces a Printer and a Job object. The Job object optionally 98 supports multiple documents per Job. It also addresses security, 99 internationalization, and directory issues. 101 The "Internet Printing Protocol/1.1: Encoding and Transport" document 102 is a formal mapping of the abstract operations and attributes defined 103 in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 104 rules for a new Internet MIME media type called "application/ipp". 105 This document also defines the rules for transporting over HTTP a 106 message body whose Content-Type is "application/ipp". This document 107 defines a new scheme named 'ippget' for identifying IPP printers and 108 jobs. 110 The "Internet Printing Protocol/1.1: Implementer's Guide" document 111 gives insight and advice to implementers of IPP clients and IPP 112 objects. It is intended to help them understand IPP/1.1 and some of 113 the considerations that may assist them in the design of their client 114 and/or IPP object implementations. For example, a typical order of 115 processing requests is given, including error checking. Motivation for 116 some of the specification decisions is also included. 118 The "Mapping between LPD and IPP Protocols" document gives some advice 119 to implementers of gateways between IPP and LPD (Line Printer Daemon) 120 implementations. 122 The "Event Notification Specification" document describes an extension 123 to the IPP/1.0, IPP/1.1, and future versions. This extension allows a 124 client to subscribe to printing related Events. Subscriptions are 125 modeled as Subscription Objects. The Subscription Object specifies 126 that when one of the specified Event occurs, the Printer sends an 127 asynchronous Event Notification to the specified Notification Recipient 128 via the specified Delivery Method (i.e., protocol). A client 129 associates Subscription Objects with a particular Job by performing the 130 Create-Job-Subscriptions operation or by submitting a Job with 131 subscription information. A client associates Subscription Objects 132 with the Printer by performing a Create-Printer-Subscriptions 133 operation. Four other operations are defined for Subscription Objects: 134 Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, 135 and Cancel-Subscription. 137 Table of Contents 139 1 Introduction......................................................7 141 2 Terminology.......................................................7 143 3 Model and Operation...............................................8 145 4 General Information...............................................9 147 5 Get-Notifications operation......................................11 148 5.1 Get-Notifications Request.....................................12 149 5.2 Get-Notifications Response....................................13 151 6 Subscription Template Attributes.................................18 152 6.1 Subscription Template Attribute Conformance...................18 153 6.2 Additional Information about Subscription Template Attributes.18 154 6.2.1 notify-recipient-uri (uri).................................18 155 6.3 Subscription Description Attribute Conformance................19 157 7 Additional Printer Description Attributes........................19 158 7.1 Printer Description Attribute Conformance.....................19 159 7.2 New Values for Existing Printer Description Attributes........19 160 7.2.1 notify-schemes-supported (1setOf uriScheme)................19 161 7.2.2 operations-supported (1setOf type2 enum)...................19 162 7.3 begin-to-expire-time-interval (integer(0:MAX))................20 164 8 New Status Codes.................................................20 165 8.1 redirection-other-site (0x300)................................20 167 9 Encoding.........................................................20 169 10 Conformance Requirements.........................................21 171 11 IANA Considerations..............................................21 173 12 Internationalization Considerations..............................21 175 13 Security Considerations..........................................21 177 14 References.......................................................22 179 15 Authors' Addresses...............................................22 181 16 Full Copyright Statement.........................................23 182 Table of Tables 184 Table 1 - Information about the Delivery Method.......................9 186 Table 2 - Attributes in Event Notification Content...................16 188 Table 3 - Additional Attributes in Event Notification Content for Job 189 Events...........................................................17 191 Table 4 - Combinations of Events and Subscribed Events for "job- 192 impressions-completed"...........................................17 194 Table 5 - Additional Attributes in Event Notification Content for 195 Printer Events...................................................18 197 Table 6 - Operation-id assignments...................................19 198 1 Introduction 200 The notification extension document [ipp-ntfy] defines operations that 201 a client can perform in order to create Subscription Objects in a 202 Printer and carry out other operations on them. A Subscription Object 203 represents a Subscription abstraction. The Subscription Object 204 specifies that when one of the specified Events occurs, the Printer 205 sends an asynchronous Event Notification to the specified Notification 206 Recipient via the specified Delivery Method (i.e., protocol). 208 The notification extension document [ipp-ntfy] specifies that each 209 Delivery Method is defined in another document. This document is one 210 such document, and it specifies the 'ippget' delivery method. 212 The 'ippget' Delivery Method is a 'pull and push' Delivery Method. That 213 is, the Printer saves Event Notification for a period of time and 214 expects the Notification Recipient to fetch the Event Notifications 215 (the pull part). The Printer continues to send Event Notifications to 216 the Notification Recipient as Events occur (the push part) if the 217 client has selected the option to wait for additional Event 218 Notifications. 220 When a Printer supports this Delivery Method, it holds each Event 221 Notification for an amount of time, called the Event Notification Lease 222 Time. 224 When a Notification Recipient wants to receive Event Notifications, it 225 performs an IPP operation called 'Get-Notifications', which this 226 document defines. This operation causes the Printer to return all Event 227 Notifications held for the Notification Recipient. If the Notification 228 Recipient has selected the option to wait for additional Event 229 Notifications, the Printer the Printer continues to send Event 230 Notifications to the Notification Recipient as Events occur. 232 2 Terminology 234 This section defines the following terms that are used throughout this 235 document: 237 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 238 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 239 conformance to this specification. These terms are defined in [RFC2911 240 section 13.1 on conformance terminology, most of which is taken from 241 RFC 2119 [RFC2119]. 243 Event Notification Lease: The lease that is associated with an Event 244 Notification. When the lease expires, the Printer discards the 245 associated Event Notification. 247 Event Notification Lease Time: The expiration time assigned to a lease 248 that is associated with an Event Notification. 250 Event Notification Attributes Group: The attributes group in a response 251 that contains attributes that are part of an Event Notification. 253 For other capitalized terms that appear in this document, see [ipp- 254 ntfy]. 256 3 Model and Operation 258 In a Subscription Creation Operation, when the value of the "notify- 259 recipient-uri" attributes has the scheme 'ippget', the client is 260 requesting that the Printer use the 'ippget' Delivery Method for the 261 Event Notifications associated with the new Subscription Object. The 262 client SHOULD choose a value for the address part of the "notify- 263 recipient-uri" attribute that uniquely identifies the Notification 264 Recipient. 266 When an Event occurs, the Printer MUST generate an Event Notification 267 and MUST assign it the Event Notification Lease Time. The Printer MUST 268 hold an Event Notification for its assigned Event Notification Lease 269 Time. The Printer MUST assign the same Event Notification Lease Time to 270 each Event Notification. 272 When a Notification Recipient wants to receive Event Notifications, it 273 performs the Get-Notifications operation, which causes the Printer to 274 return all unexpired Event Notifications held for the Notification 275 Recipient. If the Notification Recipient has selected the option to 276 wait for additional Event Notifications, the response to the Get- 277 Notifications request continues indefinitely as the Printer continues 278 to send Event Notifications in the response as Events occur. For the 279 Get-Notification operation, the Printer sends only those Event 280 Notifications that are generated from Subscription Objects whose 281 "notify-recipient-uri" equals the "notify-recipient-uri" Operation 282 Attribute in the Get-Notifications operation. 284 If a Notification Recipient performs the Get-Notifications operation 285 twice in quick succession, it will receive nearly the same Event 286 Notification both times because most of the Event Notifications are 287 those that the Printer saves for a few seconds after the Event occurs. 288 There are two possible differences. Some old Event Notifications may 289 not be present in the second response because their Event Notification 290 Leases have expired. Some new Event Notifications may be present in 291 the second response but not the first response. 293 When the Notification Recipient requests Event Notifications for per- 294 Job Subscription Objects, the Notification Recipient typically performs 295 the Get-Notifications operation within a second of performing the 296 Subscription Creation operation. Because the Printer is likely to save 297 Event Notifications for several seconds, the Notification Recipient is 298 unlikely to miss any Event Notifications that occur between the 299 Subscription Creation and the Get-Notifications operation. 301 4 General Information 303 If a Printer supports this Delivery Method, the following are its 304 characteristics. 306 Table 1 - Information about the Delivery Method 308 Document Method Conformance Delivery Method Realization 309 Requirement 311 1.What is the URL scheme name ippget 312 for the Delivery Method? 314 2.Is the Delivery Method RECOMMENDED 315 REQUIRED, RECOMMENDED or 316 OPTIONAL for an IPP Printer to 317 support? 319 3.What transport and delivery IPP with one new operation. 320 protocols does the Printer use 321 to deliver the Event 322 Notification Content, i.e., 323 what is the entire network 324 stack? 326 4.Can several Event Yes. 327 Notifications be combined into 328 a Compound Event Notification? 330 5.Is the Delivery Method This Delivery Method is a pull and 331 initiated by the Notification a push. 332 Recipient (pull), or by the 333 Printer (push)? 335 6.Is the Event Notification Machine Consumable 336 content Machine Consumable or 337 Human Consumable? 339 7.What section in this document Section 5 340 answers the following 341 question? For a Machine 342 Consumable Event Notification, 343 what is the representation and 344 encoding of values defined in 345 section 9.1 of [ipp-ntfy] and 346 the conformance requirements 347 thereof? For a Human 348 Consumable Event Notification, 349 what is the representation and 350 encoding of pieces of 351 information defined in section 352 9.2 of [ipp-ntfy] and the 353 conformance requirements 354 thereof? 356 8.What are the latency and Same as IPP and the underlying HTTP 357 reliability of the transport transport 358 and delivery protocol? 360 9.What are the security aspects Same as IPP and the underlying HTTP 361 of the transport and delivery transport 362 protocol, e.g., how it is 363 handled in firewalls? 365 10. What are the content length None 366 restrictions? 368 11. What are the additional None 369 values or pieces of 370 information that a Printer 371 sends in an Event Notification 372 content and the conformance 373 requirements thereof? 375 12. What are the additional None 376 Subscription Template and/or 377 Subscription Description 378 attributes and the conformance 379 requirements thereof? 381 13. What are the additional None 382 Printer Description attributes 383 and the conformance 384 requirements thereof? 386 5 Get-Notifications operation 388 This operation causes the Printer to return all Event Notifications 389 held for the Notification Recipient. 391 A Printer MUST support this operation. 393 When a Printer performs this operation, it MUST return all and only 394 those Event Notifications: 396 a)Whose associated Subscription Object's "notify-recipient-uri" 397 attribute equals the "notify-recipient-uri" Operation attribute 398 AND 400 b)Whose associated Subscription Object's "notify-recipient-uri" 401 attribute has a scheme value of 'ippget' AND 403 c)Whose Event Notification Lease Time has not yet expired AND 405 d)Where the Notification Recipient is the owner of or has read- 406 access rights to the associated Subscription Object. 408 The Printer MUST respond to this operation immediately with whatever 409 Event Notifications it currently holds. If the Notification Recipient 410 has selected the option to wait for additional Event Notifications, the 411 Printer MUST continue to send Event Notifications as they occur until 412 all of the associated Subscription Objects are cancelled. A 413 Subscription Object is cancelled either via the Cancel-Subscription 414 operation or by the Printer (e.g. the Subscription Object is cancelled 415 when the associated Job completes). 417 Note, the Printer terminates the operation in the same way that it 418 normally terminates IPP operations. For example, if the Printer is 419 sending chunked data, it can send a 0 length chunk to denote the end of 420 the operation or it can close the connection. If the Notification 421 Recipient wishes to terminate the Get-Notifications operation, it can 422 close the connection. 424 The Printer MUST accept the request in any state (see [RFC2911] 425 "printer-state" and "printer-state-reasons" attributes) and MUST remain 426 in the same state with the same "printer-state-reasons". 428 Access Rights: If the policy of the Printer is to allow all users to 429 access all Event Notifications, then the Printer MUST accept this 430 operation from any user. Otherwise, the authenticated user (see 431 [RFC2911] section 8.3) performing this operation MUST either be the 432 owner of each Subscription Object identified by the "notify-recipient- 433 uri" Operation attribute (as determined during a Subscription Creation 434 Operation) or an operator or administrator of the Printer (see 435 [RFC2911] Sections 1 and 8.5). Otherwise, the IPP object MUST reject 436 the operation and return: 'client-error-forbidden', 'client-error-not- 437 authenticated', or 'client-error-not-authorized' as appropriate. 439 5.1 Get-Notifications Request 441 The following groups of attributes are part of the Get-Notifications 442 Request: 444 Group 1: Operation Attributes 446 Natural Language and Character Set: 447 The "attributes-charset" and "attributes-natural-language" 448 attributes as described in [RFC2911] section 3.1.4.1. 450 Target: 451 The "printer-uri" (uri) operation attribute which is the target 452 for this operation as described in [RFC2911] section 3.1.5. 454 Requesting User Name: 455 The "requesting-user-name" (name(MAX)) attribute SHOULD be 456 supplied by the client as described in [RFC2911] section 8.3. 458 "notify-recipient-uri" (url): 459 The client MUST supply this attribute. The Printer object MUST 460 support this attribute. The Printer matches the value of this 461 attribute (byte for byte with no case conversion) against the 462 value of the "notify-recipient-uri" in each Subscription Object in 463 the Printer. If there are no matches, the IPP Printer MUST return 464 the 'client-error-not-found' status code. For each matched 465 Subscription Object, the IPP Printer MUST return all unexpired 466 Event Notifications associated with it. The Printer MUST send 467 additional Event Notifications as Events occur if and only if the 468 value of the "notify-no-wait" attribute is 'false' or not supplied 469 by the client (see the next attribute below). 471 Note: this attribute allows a subscribing client to pick URLs that 472 are unique, e.g. the client's own URL or a friend's URL, which in 473 both cases is likely the URL of the person's host. An application 474 could make a URL unique for each application. 476 "notify-no-wait" (boolean): 477 The client MAY supply this attribute. The Printer object MUST 478 support this attribute. If the value of this attribute is 'false', 479 the Printer MUST send all un-expired Event Notifications (as 480 defined in the previous attribute) and it MUST continue to send 481 responses for as long as the Subscription Objects associated with 482 the specified "notify-recipient-uri" continue to exist. If the 483 value of this attribute is 'true', the Printer MUST send all un- 484 expired Event Notifications (as defined in the previous attribute) 485 and the Printer MUST conclude the operation without waiting for 486 any additional Events to occur. If the client doesn't supply this 487 attribute, the Printer MUST behave as if the client had supplied 488 this attribute with the value of 'false'. 490 5.2 Get-Notifications Response 492 The following groups of attributes are part of the Get-Notifications 493 Response: 495 Group 1: Operation Attributes 497 Status Message: 498 In addition to the REQUIRED status code returned in every 499 response, the response OPTIONALLY includes a "status-message" 500 (text(255)) and/or a "detailed-status-message" (text(MAX)) 501 operation attribute as described in [RFC2911] sections 13 and 502 3.1.6. 504 The Printer can return any status codes defined in [RFC2911]. If 505 the status code is not 'successful-', the Printer MUST NOT return 506 any Event Notification Attribute groups. The following is a 507 description of the important status codes: 509 successful-ok: the response contains all Event Notification 510 associated with the specified "notify-recipient-uri". If the 511 specified Subscription Objects have no associated Event 512 Notification, the response MUST contain zero Event 513 Notifications. 514 client-error-not-found: The Printer has no Subscription 515 Object's whose "notify-recipient-uri" attribute equals the 516 "notify-recipient-uri" Operation attribute. 517 server-error-busy: The Printer is too busy to accept this 518 operation. If the "suggested-ask-again-time-interval" 519 operation attribute is present in the Operation Attributes of 520 the response, then the Notification Recipient SHOULD wait for 521 the number of seconds specified by the "suggested-ask-again- 522 time-interval" attribute before performing this operation 523 again. If the "suggested-ask-again-time-interval" Operation 524 Attribute is not present, the Notification Recipient should 525 use the normal network back-off algorithms for determining 526 when to perform this operation again. 527 redirection-other-site: The Printer does not handle this 528 operation and requests the Notification Recipient to perform 529 the operation with the uri specified by the "notify-ippget- 530 redirect" Operation Attribute in the response. 532 Natural Language and Character Set: 533 The "attributes-charset" and "attributes-natural-language" 534 attributes as described in [RFC2911] section 3.1.4.2. 536 The Printer MUST use the values of "notify-charset" and "notify- 537 natural-language", respectively, from one Subscription Object 538 associated with the Event Notifications in this response. 540 Normally, there is only one matched Subscription Object, or the 541 value of the "notify-charset" and "notify-natural-language" 542 attributes is the same in all Subscription Objects. If not, the 543 Printer MUST pick one Subscription Object from which to obtain the 544 value of these attributes. The algorithm for picking the 545 Subscription Object is implementation dependent. The choice of 546 natural language is not critical because 'text' and 'name' values 547 can override the "attributes-natural-language" Operation 548 attribute. The Printer's choice of charset is critical because a 549 bad choice may leave it unable to send some 'text' and 'name' 550 values accurately. 552 "printer-up-time" (integer(0:MAX)): 553 The value of this attribute is the Printer's "printer-up-time" 554 attribute at the time the Printer sends this response. Because 555 each Event Notification also contains the value of this attribute 556 when the event occurred, the value of this attribute lets a 557 Notification Recipient know when each Event Notification occurred 558 relative to the time of this response. 560 "suggested-ask-again-time-interval" (integer(0:MAX)): 561 The value of this attribute is the number of seconds that the 562 Notification Recipient SHOULD wait before trying this operation 563 again when 564 a)the Printer returns the 'server-error-busy' status code OR 565 b)the Printer returns the 'successful-ok' status code and 566 the client supplied the "notify-no-wait" attribute with a 567 value of 'true'. 568 This value is intended to help the client be a good network 569 citizen. 571 "notify-ippget-redirect" (uri): 572 The value of this attribute is uri that the Notification Recipient 573 MUST use for the Get-Notifications operation. This attribute is 574 present in the Operation Attributes if and only if the status code 575 has the value 'redirection-other-site'. 577 Group 2: Unsupported Attributes 579 See [RFC2911] section 3.1.7 for details on returning Unsupported 580 Attributes. 582 If the "subscription-ids" attribute contained subscription-ids 583 that do not exist, the Printer returns them in this group as value 584 of the "subscription-ids" attribute. 586 Group 3 through N: Event Notification Attributes 588 The Printer responds with one Event Notification Attributes Group 589 per matched Event Notification. The initial matched Event 590 Notifications are all un-expired Event Notification associated 591 with the matched Subscription Objects. If the Notification 592 Recipient has selected the option to wait for additional Event 593 Notifications, the Printer the subsequent Event Notifications in 594 the response are Event Notifications associated with the matched 595 Subscription Objects as the corresponding Event occurs. 597 From the Notification Recipient's view, the response appears as an 598 initial burst of data, which includes the Operation Attributes 599 Group and one Event Notification Attributes Groups per Event 600 Notification that the Printer is holding. After the initial burst 601 of data, if the Notification Recipient has selected the option to 602 wait for additional Event Notifications, the Notification 603 Recipient receives occasional Event Notification Attribute Groups. 604 Proxy servers may delay some Event Notifications or cause time- 605 outs to occur. The client MUST be prepared to perform the Get- 606 Notifications operation again when time-outs occur. 608 Each Event Notification Group MUST start with an 'event- 609 notification-attributes-tag' (see the section "Encodings of 610 Additional Attribute Tags" in [ipp-ntfy]). 612 Each attribute is encoded using the IPP rules for encoding 613 attributes [RFC2910] and may be encoded in any order. Note: the 614 Get-Jobs response in [RFC2911] acts as a model for encoding 615 multiple groups of attributes. 617 Each Event Notification Group MUST contain all of attributes 618 specified in section 9.1 ("Content of Machine Consumable Event 619 Notifications") of [ipp-ntfy] with exceptions denoted by asterisks 620 in the tables below. 622 The tables below are copies of the tables in section 9.1 ("Content 623 of Machine Consumable Event Notifications") of [ipp-ntfy] except 624 that each cell in the "Sends" column is a "MUST". 626 For an Event Notification for all Events, the Printer includes the 627 following attributes. 629 Table 2 - Attributes in Event Notification Content 631 Source Value Sends Source Object 633 notify-subscription-id (integer(1:MAX)) MUST Subscription 635 notify-printer-uri (uri) MUST Subscription 637 notify-subscribed-event (type2 keyword) MUST Event 638 Notification 640 printer-up-time (integer(MIN:MAX)) MUST Printer 642 printer-current-time (dateTime)* MUST Printer 644 notify-sequence-number (integer (0:MAX)) MUST Subscription 646 notify-charset (charset) MUST Subscription 648 notify-natural-language (naturalLanguage) MUST Subscription 650 notify-user-data (octetString(63)) ** MUST Subscription 652 notify-text (text) MUST Event 653 Notification 655 attributes from the "notify-attributes" MUST Printer 656 attribute *** 658 attributes from the "notify-attributes" MUST Job 659 attribute *** 661 attributes from the "notify-attributes" MUST Subscription 662 attribute *** 664 * The Printer MUST send "printer-current-time" if and only if it 665 supports the "printer-current-time" attribute on the Printer 666 object. 668 ** If the associated Subscription Object does not contain a 669 "notify-user-data" attribute, the Printer MUST send an octet- 670 string of length 0. 672 *** If the "notify-attributes" attribute is present on the 673 Subscription Object, the Printer MUST send all attributes 674 specified by the "notify-attributes" attribute. Note: if the 675 Printer doesn't support the "notify-attributes" attribute, it is 676 not present on the associated Subscription Object. 678 For Event Notifications for Job Events, the Printer includes the 679 following additional attributes. 681 Table 3 - Additional Attributes in Event Notification Content for 682 Job Events 684 Source Value Sends Source Object 686 job-id (integer(1:MAX)) MUST Job 688 job-state (type1 enum) MUST Job 690 job-state-reasons (1setOf type2 keyword) MUST Job 692 job-impressions-completed MUST Job 693 (integer(0:MAX)) * 695 * The Printer MUST send the "job-impressions-completed" attribute 696 in an Event Notification only for the combinations of Events and 697 Subscribed Events shown in Table 4. 699 Table 4 - Combinations of Events and Subscribed Events for "job- 700 impressions-completed" 702 Job Event Subscribed Job Event 704 'job-progress' 'job-progress' 706 'job-completed' 'job-completed' 708 'job-completed' 'job-state-changed' 710 For Event Notification for Printer Events, the Printer includes 711 the following additional attributes. 713 Table 5 - Additional Attributes in Event Notification Content for 714 Printer Events 716 Source Value Sends Source Object 718 printer-state (type1 enum) MUST Printer 720 printer-state-reasons (1setOf type2 MUST Printer 721 keyword) 723 printer-is-accepting-jobs (boolean) MUST Printer 725 6 Subscription Template Attributes 727 This section defines the Subscription object conformance requirements 728 for Printers. 730 6.1 Subscription Template Attribute Conformance 732 The 'ippget' Delivery Method has the same conformance requirements for 733 Subscription Template attributes as defined in [ipp-ntfy]. The 734 'ippget' Delivery Method does not define any addition Subscription 735 Template attributes. 737 6.2 Additional Information about Subscription Template Attributes 739 This section defines additional information about Subscription Template 740 attributes defined in [ipp-ntfy]. 742 6.2.1notify-recipient-uri (uri) 744 This section describes the syntax of the value of this attribute for 745 the 'ippget' Delivery Method. The syntax for values of this attribute 746 for other Delivery Method is defined in other Delivery Method 747 Documents. 749 In order to support the 'ippget' Delivery Method and Protocol, the 750 Printer MUST support the following syntax: 752 The 'ippget://' URI scheme. The remainder of the URI indicates 753 something unique about the Notification Recipient, such as its host 754 and address that the Printer uses to match the "notify-recipient- 755 uri" Operation attribute supplied in the Get-Notifications request. 757 6.3 Subscription Description Attribute Conformance 759 The 'ippget' Delivery Method has the same conformance requirements for 760 Subscription Description attributes as defined in [ipp-ntfy]. The 761 'ippget' Delivery Method does not define any addition Subscription 762 Description attributes. 764 7 Additional Printer Description Attributes 766 This section defines the Printer Description Attributes conformance 767 requirements for Printers. 769 7.1 Printer Description Attribute Conformance 771 The 'ippget' Delivery Method has the same conformance requirements for 772 Printer Description attributes as defined in [ipp-ntfy]. The 'ippget' 773 Delivery Method does not define any addition Printer Description 774 attributes. 776 7.2 New Values for Existing Printer Description Attributes 778 This section defines additional values for existing Printer Description 779 attributes. 781 7.2.1notify-schemes-supported (1setOf uriScheme) 783 The following "notify-schemes-supported" value is added in order to 784 support the new Delivery Method defined in this document: 786 'ippget' - The IPP Notification Delivery Method defined in this 787 document. 789 7.2.2operations-supported (1setOf type2 enum) 791 Table 6 lists the "operation-id" value added in order to support the 792 new operation defined in this document. 794 Table 6 - Operation-id assignments 796 Value Operation Name 798 0x001C Get-Notifications 800 7.3 begin-to-expire-time-interval (integer(0:MAX)) 802 This attribute specifies the number of seconds that a Printer keeps an 803 Event Notification that is associated with this Delivery Method. 805 The Printer MUST support this attribute if it supports this Delivery 806 Method. 808 The value of this attribute is the minimum number of seconds that MUST 809 elapse between the time the Printer creates an Event Notification 810 object for this Delivery Method and the time the Printer discards the 811 same Event Notification. 813 For example, assume the following: 815 1. a client performs a Job Creation operation that creates a 816 Subscription Object associated with this Delivery Method, AND 818 2. an Event associated with the new Job occurs immediately after the 819 Subscription Object is created, AND 821 3. the same client or some other client performs a Get-Notifications 822 operation N seconds after the Job Creation operation. 824 Then, if N is less than the value of this attribute, the client 825 performing the Get-Notifications operations can expect not miss any 826 Event-Notifications, barring some unforeseen lack of memory space in 827 the Printer. 829 8 New Status Codes 831 The following status codes are defined as extensions for this Delivery 832 Method and are returned as the status code of the Get-Notifications 833 operation. 835 8.1 redirection-other-site (0x300) 837 This status code means that the Printer doesn't perform that Get- 838 Notifications operation and that the "notify-ippget-redirect" Operation 839 Attribute in the response contains the uri that the Notification 840 Recipient MUST use for performing the Get-Notifications operation. 842 9 Encoding 844 This notification delivery method uses the IPP transport and encoding 845 [RFC2910] for the Get-Notifications operation with one extension: 847 notification-attributes-tag = %x07 ; tag of 848 7 850 10 Conformance Requirements 852 If the Printer supports the 'ippget' Delivery Method, the Printer MUST: 854 1.meet the conformance requirements defined in [ipp-ntfy]. 856 2.support the Get-Notifications operation defined in section 5. 858 3.support the Subscription object attributes as defined in section 6. 860 4.support the additional values for IPP/1.1 Printer Description 861 attributes defined in section 7.2. 863 5.support the "begin-to-expire-time-interval" Printer Description 864 attribute defined in section 7.3. 866 6.support the "redirection-other-site" status code defined 8.1 868 11 IANA Considerations 870 The 'ippget' URL scheme for the 'ippget' Delivery Method will be 871 registered with IANA according to the procedures of [RFC2717]. 873 12 Internationalization Considerations 875 The IPP Printer MUST localize the "notify-text" attribute as specified 876 in section 14 of [ipp-ntfy]. 878 In addition, when the client receives the Get-Notifications response, 879 it is expected to localize the attributes that have the 'keyword' 880 attribute syntax according to the charset and natural language 881 requested in the Get-Notifications request. 883 13 Security Considerations 885 The IPP Model and Semantics document [RFC2911] discusses high-level 886 security requirements (Client Authentication, Server Authentication and 887 Operation Privacy). Client Authentication is the mechanism by which 888 the client proves its identity to the server in a secure manner. 889 Server Authentication is the mechanism by which the server proves its 890 identity to the client in a secure manner. Operation Privacy is 891 defined as a mechanism for protecting operations from eavesdropping. 893 Unlike other Event Notification delivery methods in which the IPP 894 Printer initiates the Event Notification, with the method defined in 895 this document, the Notification Recipient is the client who s the 896 Get-Notifications operation. Therefore, there is no chance of "spam" 897 notifications with this method. Furthermore, such a client can close 898 down the HTTP channel at any time, and so can avoid future unwanted 899 Event Notifications at any time. 901 14 References 903 [ipp-ntfy] 904 R. Herriot, Hastings, T., Isaacson, S., Martin, J., deBry, R., 905 Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP 906 Event Notification Specification", , June 30, 2000. 909 [rfc2026] 910 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 911 2026, October 1996. 913 [RFC2616] 914 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 915 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 916 RFC 2616, June 1999. 918 [RFC2910] 919 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 920 Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 922 [RFC2911] 923 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 924 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 925 September 2000. 927 15 Authors' Addresses 929 Robert Herriot 930 Xerox Corp. 931 3400 Hill View Ave, Building 1 932 Palo Alto, CA 94304 934 Phone: 650-813-7696 935 Fax: 650-813-6860 936 e-mail: robert.herriot@pahv.xerox.com 938 Carl Kugler 939 IBM 940 P.O. Box 1900 941 Boulder, CO 80301-9191 943 Phone: 944 Fax: 945 e-mail: kugler@us.ibm.com 947 Harry Lewis 948 IBM 949 P.O. Box 1900 950 Boulder, CO 80301-9191 952 Phone: 303-924-5337 953 FAX: 954 e-mail: harryl@us.ibm.com 956 16 Full Copyright Statement 958 Copyright (C) The Internet Society (2000). All Rights Reserved. 960 This document and translations of it may be copied and furnished to 961 others, and derivative works that comment on or otherwise explain it or 962 assist in its implementation may be prepared, copied, published and 963 distributed, in whole or in part, without restriction of any kind, 964 provided that the above copyright notice and this paragraph are 965 included on all such copies and derivative works. However, this 966 document itself may not be modified in any way, such as by removing the 967 copyright notice or references to the Internet Society or other 968 Internet organizations, except as needed for the purpose of developing 969 Internet standards in which case the procedures for copyrights defined 970 in the Internet Standards process must be followed, or as required to 971 translate it into languages other than English. 973 The limited permissions granted above are perpetual and will not be 974 revoked by the Internet Society or its successors or assigns. 976 This document and the information contained herein is provided on an 977 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 978 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 979 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 980 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 981 FITNESS FOR A PARTICULAR PURPOSE.