idnits 2.17.1 draft-ietf-ipp-notify-get-08.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: ---------------------------------------------------------------------------- ** 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2911, but the abstract doesn't seem to directly say this. It does mention RFC2911 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 267 has weird spacing: '...ll), or a p...' == Line 1490 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in '[Target category: standards track]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC2911, updated by this document, for RFC5378 checks: 1999-02-22) -- 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 (October 10, 2002) is 7868 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: 'RFC 2911' is mentioned on line 135, but not defined ** Obsolete undefined reference: RFC 2911 (Obsoleted by RFC 8011) == Missing Reference: 'RFC 2910' is mentioned on line 135, but not defined ** Obsolete undefined reference: RFC 2910 (Obsoleted by RFC 8010) == Unused Reference: 'RFC2565' is defined on line 1154, but no explicit reference was found in the text == Unused Reference: 'RFC2566' is defined on line 1159, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) -- Obsolete informational reference (is this intentional?): RFC 2565 (Obsoleted by RFC 2910) -- Obsolete informational reference (is this intentional?): RFC 2566 (Obsoleted by RFC 2911) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Printing Protocol WG R. Herriot 3 INTERNET-DRAFT consultant 4 T. Hastings 5 Updates: RFC 2911 and [ipp-ntfy] Xerox Corp. 6 [Target category: standards track] H. Lewis 7 Expires: April 10, 2003 IBM Corp. 8 October 10, 2002 10 Internet Printing Protocol (IPP): 11 The 'ippget' Delivery Method for Event Notifications 13 Copyright (C) The Internet Society (2002). All Rights Reserved. 15 Status of this Memo: 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC 2026. Internet-Drafts are 19 working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working 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 26 material 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.html 31 The list of Internet-Draft Shadow Directories can be accessed as 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes an extension to the Internet Printing 37 Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This 38 document specifies the 'ippget' Pull Delivery Method for use with the 39 "Internet Printing Protocol (IPP): Event Notifications and 40 Subscriptions" specification (ipp-ntfy). This IPPGET Delivery Method 41 is REQUIRED for all clients and Printers that support ipp-ntfy. The 42 Notification Recipient, acting as a client, fetches (pulls) Event 43 Notifications using the Get-Notifications operation defined in this 44 document. 46 Table of Contents 48 1 Introduction.....................................................4 50 2 Terminology......................................................4 51 2.1 Conformance Terminology........................................4 52 2.2 Other terminology..............................................5 54 3 Model and Operation..............................................5 56 4 General Information..............................................7 58 5 Get-Notifications operation......................................8 59 5.1 Get-Notifications Request.....................................10 60 5.1.1 notify-subscription-ids (1setOf integer(1:MAX)).............10 61 5.1.2 notify-sequence-numbers (1setOf integer(1:MAX)).............10 62 5.1.3 notify-wait (boolean).......................................11 63 5.2 Get-Notifications Response....................................12 64 5.2.1 notify-get-interval (integer(0:MAX))........................14 65 5.2.2 printer-up-time (integer(1:MAX))............................17 67 6 Additional Information about Subscription Template Attributes...21 68 6.1 notify-pull-method (type2 keyword)............................21 70 7 Subscription Description Attributes.............................21 72 8 Additional Printer Description Attributes.......................22 73 8.1 ippget-event-life (integer(15:MAX))...........................22 75 9 New Values for Existing Printer Description Attributes..........23 76 9.1 notify-pull-method-supported (1setOf type2 keyword)...........23 77 9.2 operations-supported (1setOf type2 enum)......................23 79 10 New Status Codes...............................................23 80 10.1 successful-ok-events-complete (0x0007).......................24 82 11 Encoding and Transport.........................................24 84 12 Conformance Requirements.......................................25 85 12.1 Conformance for IPP Printers.................................26 86 12.2 Conformance for IPP Clients..................................26 88 13 Normative References...........................................27 90 14 Informative References.........................................27 92 15 IANA Considerations............................................28 93 15.1 Attribute Registrations......................................29 94 15.2 Additional keyword attribute value registrations for existing 95 attributes........................................................29 96 15.3 Additional enum attribute values.............................29 97 15.4 Operation Registrations......................................29 98 15.5 Status code Registrations....................................30 100 16 Internationalization Considerations............................30 102 17 Security Considerations........................................30 103 17.1 Notification Recipient client access rights..................31 104 17.2 Printer security threats.....................................31 105 17.3 Notification Recipient security threats......................31 106 17.4 Security requirements for Printers...........................32 107 17.5 Security requirements for clients............................32 109 18 Contributors...................................................32 111 19 Authors' Addresses.............................................32 113 20 Description of Base IPP documents (Informative)................33 115 21 Full Copyright Statement.......................................35 117 Table of Tables 119 Table 1 - Information about the Delivery Method....................7 120 Table 2 - Combinations of "notify-wait", "status-code", and "notify- 121 get-interval" .................................................16 122 Table 3 - Attributes in Event Notification Content................19 123 Table 4 - Additional Attributes in Event Notification Content for Job 124 Events ........................................................20 125 Table 5 - Combinations of Events and Subscribed Events for "job- 126 impressions-completed" ........................................20 127 Table 6 - Additional Attributes in Event Notification Content for 128 Printer Events ................................................21 129 Table 7 - Operation-id assignments................................23 130 Table 8 - The "event-notification-attributes-tag" value...........25 132 1 Introduction 134 This document describes an extension to the Internet Printing 135 Protocol/1.1: Model and Semantics [RFC 2911], [RFC 2910]. This 136 document specifies the 'ippget' Pull Delivery Method for use with the 137 "Internet Printing Protocol (IPP): Event Notifications and 138 Subscriptions" specification [ipp-ntfy]. This IPPGET Delivery Method 139 is REQUIRED for all clients and Printers that support [ipp-ntfy]. 140 The Notification Recipient, acting as a client, fetches (pulls) Event 141 Notifications using the Get-Notifications operation defined in this 142 document. For a description of the base IPP documents, see section 143 20 of this document. For a description of the IPP Event Notification 144 Model, see [ipp-ntfy]. 146 With this Pull Delivery Method, when an Event occurs, the Printer 147 saves the Event Notification for a period of time called the Event 148 Life. The Notification Recipient fetches (pulls) the Event 149 Notifications using the Get-Notifications operation. This operation 150 causes the Printer to return all Event Notifications held for the 151 specified Subscription object(s). If the Notification Recipient has 152 selected the Event Wait Mode option to wait for additional Event 153 Notifications, the Printer MAY continue to return Event Notifications 154 to the Notification Recipient as asynchronous Get-Notification 155 responses as Events occur using the transaction originated by the 156 Notification Recipient. 158 The Notification Recipient can terminate Event Wait Mode (without 159 closing the connection) by supplying the "notify-wait" (boolean) 160 attribute with a 'false' value in a subsequent Get-Notifications 161 request. Similarly, the Printer can terminate Event Wait Mode 162 (without closing the connection) by returning the "notify-get- 163 interval" (integer) operation attribute in a Get-Notifications 164 response which tells the Notification Recipient how long to wait 165 before trying again. 167 2 Terminology 169 This section defines the following terms that are used throughout 170 this document: 172 2.1 Conformance Terminology 174 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 175 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 176 conformance as defined in RFC 2119 [RFC2119] and [RFC2911] section 177 12.1. If an implementation supports the extension defined in this 178 document, then these terms apply; otherwise, they do not. These 179 terms define conformance to this document only; they do not affect 180 conformance to other documents, unless explicitly stated otherwise. 182 2.2 Other terminology 184 This document uses the same terminology as [RFC2911], such as 185 "client", "Printer", "Job", "attribute", "attribute value", 186 "keyword", "operation", "request", "response", and "support" with the 187 same meanings. This document also uses terminology defined in [ipp- 188 ntfy], such as "Subscription (object)", "Notification Recipient", 189 "Event", "Event Notification", "Compound Event Notification", "Event 190 Life", and "Event Notification Attribute Group" with the same 191 meanings. In addition, this document defines the following terms for 192 use in this document: 194 Event Wait Mode: The mode requested by a Notification Recipient 195 client in its Get-Notifications Request and granted by a Printer 196 to keep the connection open while the Printer sends subsequent 197 Event Notifications to the Notification Recipient as they occur 198 as additional Get-Notification operation responses. 200 3 Model and Operation 202 In a Subscription Creation Operation, when the "notify-pull-method" 203 attribute is present and has the 'ippget' keyword value, the client 204 is requesting that the Printer use the 'ippget' Pull Delivery Method 205 for the Event Notifications associated with the new Subscription 206 Object. 208 When an Event occurs, the Printer MUST generate an Event Notification 209 and MUST assign it the Event Life. The Printer MUST hold an Event 210 Notification for its assigned Event Life. 212 When a Notification Recipient wants to receive Event Notifications 213 for a Subscription object, it performs the Get-Notifications 214 operation supplying the Subscription object's subscription-id, which 215 causes the Printer to return all un-expired Event Notifications held 216 for that Subscription object. If the Notification Recipient has 217 selected the Event Wait Mode option to wait for additional Event 218 Notifications, the response to the Get-Notifications request 219 continues indefinitely as the Printer continues to send Event 220 Notifications in the response as Events occur for that Subscription 221 object. 223 When the Notification Recipient requests Event Notifications for per- 224 Job Subscription Objects, the Notification Recipient typically 225 performs the Get-Notifications operation within a second of 226 performing the Subscription Creation operation. Because the Printer 227 MUST save Event Notifications for at least 15 seconds (see section 228 8.1), the Notification Recipient is unlikely to miss any Event 229 Notifications that occur between the Subscription Creation and the 230 Get-Notifications operation. 232 The 'ippget' Delivery Method is designed primarily for (1) a client 233 that wants to get Events (from the job's per-Job Subscription object) 234 for a job that it has submitted and (2) for a privileged client that 235 wants to get all job or printer Events from a per-Printer 236 Subscription object. 238 4 General Information 240 If a Printer supports this Delivery Method, the following are its 241 characteristics. 243 Table 1 - Information about the Delivery Method 245 Document Method Conformance Requirement Delivery Method 246 Realization 248 1. What is the URL scheme name for the 'ippget' keyword method 249 Push Delivery Method or the keyword name 250 method name for the Pull Delivery 251 Method? 253 2. Is the Delivery Method REQUIRED, 254 RECOMMENDED or OPTIONAL for an IPP 255 Printer to support? REQUIRED 257 3. What transport and delivery protocols IPP with one new 258 does the Printer use to deliver the operation. 259 Event Notification Content, i.e., what 260 is the entire network stack? 262 4. Can several Event Notifications be Yes. 263 combined into a Compound Event 264 Notification? 266 5. Is the Delivery Method initiated by This Delivery Method is 267 the Notification Recipient (pull), or a pull method with 268 by the Printer (push)? aspects of a push 269 method, though the 270 Printer does not 271 initiate the operation. 273 6. Is the Event Notification content Machine Consumable 274 Machine Consumable or Human 275 Consumable? 277 7. What section in this document answers Section 5 278 the following question? For a Machine 279 Consumable Event Notification, what is 280 the representation and encoding of 281 values defined in section 9.1 of [ipp- 282 ntfy] and the conformance requirements 283 thereof? For a Human Consumable Event 284 thereof? For a Human Consumable Event 285 Notification, what is the 286 representation and encoding of pieces 287 of information defined in section 9.2 288 of [ipp-ntfy] and the conformance 289 requirements thereof? 291 8. What are the latency and reliability Same as IPP and the 292 of the transport and delivery underlying HTTP 293 protocol? transport 295 9. What are the security aspects of the Same as IPP and the 296 transport and delivery protocol, e.g., underlying HTTP 297 how it is handled in firewalls? transport and in the 298 same direction, so no 299 new firewall 300 considerations. 302 10.What are the content length None 303 restrictions? 305 11.What are the additional values or 306 pieces of information that a Printer 307 sends in an Event Notification content 308 and the conformance requirements 309 thereof? None 311 12.What are the additional Subscription None 312 Template and/or Subscription 313 Description attributes and the 314 conformance requirements thereof? 316 13.What are the additional Printer "ipp-event-life" 317 Description attributes and the (integer (15: MAX)) 318 conformance requirements thereof? 320 5 Get-Notifications operation 322 This operation is issued by a client acting in the role of a 323 Notification Recipient requesting the Printer to return all Event 324 Notifications held for the identified Subscription object(s). 326 A Printer MUST support this operation, MUST accept the request in any 327 state (see [RFC2911] "printer-state" and "printer-state-reasons" 328 attributes), and MUST remain in the same state with the same 329 "printer-state-reasons" values. 331 When a Printer performs this operation, it MUST return all and only 332 those Event Notifications: 334 1. Whose associated Subscription Object's "notify-subscription-id" 335 Subscription Description attribute equals one of the values of 336 the "notify-subscription-ids" (1setOf integer(1:MAX)) operation 337 attribute AND 339 2. Whose associated Subscription Object's contains the "notify- 340 pull-method" attribute and it has the 'ippget' keyword value AND 342 3. Whose "notify-sequence-number" is equal to or greater than the 343 corresponding value of the "notify-sequence-numbers (1setOf 344 integer(1:MAX)) operation attribute, if supplied AND 346 4. Whose Event Life has not yet expired AND 348 5. Where the Notification Recipient client has read-access rights 349 to the identified Subscription Object (see Access Rights 350 paragraph below). 352 The Notification Recipient client MUST either: (a) request Event Wait 353 Mode by supplying the "notify-wait" operation attribute with a 'true' 354 value or (b) suppress Event Wait Mode by omitting the "notify-wait" 355 operation attribute or by supplying it with a 'false' value. In 356 order to terminate Event Wait Mode subsequently, the Notification 357 Recipient client MUST close the connection. In order to terminate 358 Event Wait Mode, the Printer MUST either (a) return the "notify-get- 359 interval" operation attribute in a Get-Notifications response 360 (RECOMMENDED behavior) or (b) close the connection. The "notify-get- 361 interval" operation attributes tells the Notification Recipient how 362 long to wait before trying a subsequent Get-Notifications request. 364 Access Rights: The authenticated user (see [RFC2911] section 8.3) 365 performing this operation MUST be (1) the owner of each Subscription 366 Object identified by the "notify-subscription-ids" operation 367 attribute (see section 5.1.1), (2) an operator or administrator of 368 the Printer (see [RFC2911] Sections 1 and 8.5), or (3) be otherwise 369 authorized by the Printer's administrator-configured security policy 370 to request Event Notifications from the target Subscription 371 Object(s). Otherwise, the IPP Printer MUST reject the operation and 372 return: 'client-error-forbidden', 'client-error-not-authenticated', 373 or 'client-error-not-authorized' status code as appropriate. 374 Furthermore, the Printer's security policy MAY limit the attributes 375 returned by the Get-Notifications operation, in a manner similar to 376 the Get-Job-Attributes operation (see [RFC2911] end of section 377 3.3.4.2). 379 5.1 Get-Notifications Request 381 The following groups of attributes are part of the Get-Notifications 382 Request: 384 Group 1: Operation Attributes 386 Natural Language and Character Set: 387 The "attributes-charset" and "attributes-natural-language" 388 attributes as described in [RFC2911] section 3.1.4.1. 390 Target: 391 The "printer-uri" (uri) operation attribute which is the target 392 for this operation as described in [RFC2911] section 3.1.5. 394 Requesting User Name: 395 The "requesting-user-name" (name(MAX)) attribute SHOULD be 396 supplied by the client as described in [RFC2911] section 8.3. 398 5.1.1 notify-subscription-ids (1setOf integer(1:MAX)) 400 This attribute identifies one or more Subscription objects for 401 which Events are requested. The client MUST supply this 402 attribute with at least one value. The Printer object MUST 403 support this attribute with multiple values. 405 If no Subscription Object exists with the supplied identifier 406 or the identified Subscription Object does not contain the 407 "notify-pull-method" attribute with the 'ippget' keyword value, 408 the Printer MUST return the 'client-error-not-found' status 409 code. 411 Note: The name of both the "notify-subscription-ids" and 412 "notify-sequence-numbers" end in 's', since they are 413 multi-valued. However, there are other occurrences of 414 these attribute names without the 's' that are single 415 valued. 417 5.1.2 notify-sequence-numbers (1setOf integer(1:MAX)) 419 This attribute specifies one or more lowest Event Notification 420 sequence number values for the Subscription objects identified 421 by the corresponding values of the "notify-subscription-ids" 422 operation attribute. The Notification Recipient SHOULD supply 423 this attribute and the number of values SHOULD be the same as 424 the number of values of the "notify-subscriptions-ids" 425 attribute. The Printer MUST support this attribute with 426 multiple values. 428 The Printer MUST NOT return Notification Events with lower 429 sequence numbers for the corresponding Subscription object. 430 Therefore, by supplying the proper values for this attribute 431 the Notification Recipient can prevent getting the same Event 432 Notifications from a Subscription object that were returned on 433 a previous Get-Notifications request. The Notification 434 Recipient SHOULD remember the highest "notify-sequence-number" 435 value returned for each Subscription object requested and 436 SHOULD pass that value for each requested Subscription object 437 on the next Get-Notifications request. 439 If the Notification Recipient supplies fewer values for this 440 attribute (including omitting this attribute) than for the 441 "notify-subscription-ids" operation attribute, the Printer 442 assumes a '1' value for each missing value. A value of '1' 443 causes the Printer to return any un-expired Event Notification 444 for that Subscription object, since '1' is the lowest possible 445 sequence number. If the Notification Recipient supplies more 446 values for this attribute than the number of values for the 447 "notify-subscription-ids" operation attribute, the Printer 448 ignores the extra values. 450 Note: If a Notification Recipient performs two consecutive Get- 451 Notifications operations with the same value for "notify- 452 sequence-number" (or omits the attribute), the time stamp of 453 the first Event Notification in the second Get-Notifications 454 Response may be less than the time stamp of the last Event 455 Notification in the first Get-Notification Response. This 456 happens because the Printer sends all unexpired Event 457 Notification with a sequence number equal or higher according 458 to the ordering specified in [ipp-ntfy] and some Event 459 Notifications from the first Get-Notifications operation may 460 not have expired by the time the second Get-Notifications 461 operation occurs. 463 5.1.3 notify-wait (boolean) 465 This value indicates whether or not the Notification Recipient 466 wants Event Wait Mode. The client MAY supply this attribute. 467 The Printer object MUST support both values of this attribute. 469 If the client supplies the 'false' value or omits this 470 attribute, the client is not requesting Event Wait Mode. If 471 the value is 'true', the client is requesting Event Wait Mode. 472 See the beginning of section 5.2 for the rules for Event Wait 473 Mode. 475 5.2 Get-Notifications Response 477 The Printer has the following options for responding to a Get- 478 Notifications Request: 480 1. The Printer can reject the request and return the 'server-error- 481 busy' status code, if the Printer is too busy to accept this 482 operation at this time. In this case, the Printer MUST return 483 the "get-notify-interval" operation attribute to indicate when 484 the client SHOULD try again. 486 2. If the Notification Recipient did not request Event Wait Mode 487 ("notify-wait-mode" = 'false' or omitted), the Printer MUST 488 return immediately whatever Event Notifications it currently 489 holds in the requested Subscription object(s) and MUST return 490 the "notify-get-interval" operation attribute with number of 491 seconds from now at which the Notification Recipient SHOULD 492 repeat the Get-Notifications Request to get future Event 493 Notifications. 495 3. If the Notification Recipient requested Event Wait Mode 496 ("notify-wait-mode" = 'true'), the Printer MUST return 497 immediately whatever Event Notifications it currently holds in 498 the requested Subscription object(s) and MUST continue to return 499 Event Notifications as they occur until all of the requested 500 Subscription Objects are canceled. A Subscription Object is 501 canceled either via the Cancel-Subscription operation or by the 502 Printer (e.g., the Subscription Object is canceled when the 503 associated Job completes and is no longer in the Job Retention 504 or Job History phase - see the "ippget-event-life 505 (integer(15:MAX))" attribute discussion in section 8.1). 507 However, the Printer MAY decide to terminate Event Wait Mode at 508 any time, including in the first response. In this case the 509 Printer MUST return the "notify-get-interval" operation 510 attribute. This attribute indicates that the Printer wishes to 511 leave Event Wait Mode and the number of seconds in the future 512 that the Notification Recipient SHOULD try the Get-Notifications 513 operation again. The Notification Recipient MUST accept this 514 response and MUST disconnect. If the Notification Recipient 515 does not disconnect, the Printer SHOULD do so. 517 From the Notification Recipient's view, the response appears as an 518 initial burst of data, which includes the Operation Attributes Group 519 and one Event Notification Attributes Group per Event Notification 520 that the Printer is holding. After the initial burst of data, if the 521 Notification Recipient has selected the Event Wait Mode option to 522 wait for additional Event Notifications, the Notification Recipient 523 receives occasional Event Notification Attribute Groups. Proxy 524 servers may delay some Event Notifications or cause time-outs to 525 occur. The client MUST be prepared to perform the Get-Notifications 526 operation again when time-outs occur. 528 Each attribute is encoded using the IPP rules for encoding attributes 529 [RFC2910] and MAY be encoded in any order. Note: the Get-Jobs 530 response in [RFC2911] acts as a model for encoding multiple groups of 531 attributes. See section 11 for the encoding and transport rules. 533 The following groups of attributes are part of the Get-Notifications 534 Response: 536 Group 1: Operation Attributes 538 Status Message: 539 In addition to the REQUIRED status code returned in every 540 response, the response OPTIONALLY includes a "status-message" 541 (text(255)) and/or a "detailed-status-message" (text(MAX)) 542 operation attribute as described in [RFC2911] sections 13 and 543 3.1.6. 545 The Printer can return any status codes defined in [RFC2911]. 546 If the status code is not 'successful-xxx', the Printer MUST 547 NOT return any Event Notification Attribute groups. The 548 following is a description of the important status codes: 550 successful-ok: the response contains all Event Notification 551 associated with the specified subscription-ids that had 552 been supplied in the "notify-subscription-ids" operation 553 attribute in the request. If the requested Subscription 554 Objects have no associated Event Notification, the 555 response MUST contain zero Event Notifications. 556 successful-ok-events-complete: indicate when this return 557 is the last return for all Subscription objects that 558 match the request, whether or not there are Event 559 Notifications being returned. This condition occurs for 560 Event Wait Mode with Notification Recipients waiting for 561 responses when the Subscription Object is: (1) canceled 562 with a Cancel-Subscription operation, (2) deleted when 563 the Per-Printer Subscription lease time expires, or (3) 564 when the 'job-completed' event occurs for a Per-Job 565 Subscription. This condition also occurs for a Get- 566 Notifications request that a Notification Recipient makes 567 after the job completes, but before the Event Life 568 expires. See section 10.1. 570 client-error-not-found: The Printer has no Subscription 571 Object's whose "notify-subscription-id" attribute equals 572 any of the values of the "notify-subscription-ids" 573 operation attribute supplied or the identified 574 Subscription Object does not contain the "notify-pull- 575 method" attribute with the 'ippget' keyword value. 576 server-error-busy: The Printer is too busy to accept this 577 operation. The Printer SHOULD return the "notify-get- 578 interval" operation attribute in the Operation Attributes 579 of the response, then the Notification Recipient SHOULD 580 wait for the number of seconds specified by the "notify- 581 get-interval" operation attribute before performing this 582 operation again. If the "notify-get-interval" Operation 583 Attribute is not present, the Notification Recipient 584 SHOULD use the normal network back-off algorithms for 585 determining when to perform this operation again. 587 Natural Language and Character Set: 588 The "attributes-charset" and "attributes-natural-language" 589 attributes as described in [RFC2911] section 3.1.4.2. 591 The Printer MUST use the values of "notify-charset" and 592 "notify-natural-language", respectively, from one Subscription 593 Object associated with the Event Notifications in this 594 response. 596 Normally, there is only one matched Subscription Object, or the 597 value of the "notify-charset" and "notify-natural-language" 598 attributes is the same in all Subscription Objects. If not, 599 the Printer MUST pick one Subscription Object from which to 600 obtain the value of these attributes. The algorithm for 601 picking the Subscription Object is implementation dependent. 602 The choice of natural language is not critical because 'text' 603 and 'name' values can override the "attributes-natural- 604 language" operation attribute. The Printer's choice of charset 605 is critical because a bad choice may leave it unable to send 606 some 'text' and 'name' values accurately. 608 5.2.1 notify-get-interval (integer(0:MAX)) 610 The value of this operation attribute is the number of seconds 611 that the Notification Recipient SHOULD wait before trying the 612 Get-Notifications operation again. The Printer MUST return 613 this operation attribute if: (1) it is too busy to return 614 events, (2) the Notification Recipient client did not request 615 Event Wait Mode, or (3) the Printer is terminating Event Wait 616 Mode. The client MUST accept this attribute and SHOULD re- 617 issue the Get-Notifications operation (with or without "notify- 618 wait" = 'true') the indicated number of seconds in the future 619 in order to get more Event Notifications This value is 620 intended to help the client be a good network citizen. 622 The value of this attribute MUST be at least as large as the 623 value of the Printer's "ippget-event-life" Printer Description 624 attribute (see section 8.1). The Printer MAY return a value 625 that is larger than the value of the "ippget-event-life" 626 Printer Description attribute provided that the Printer 627 increases the Event Life for this Subscription object, so that 628 Notification Recipients taking account of the larger value and 629 polling with a longer interval will not miss events. Note; 630 implementing such an algorithm requires some hidden attributes 631 in the Subscription object that are IMPLEMENTATION DEPENDENT. 633 If the Printer wants to remain in Event Wait Mode, then the 634 Printer MUST NOT return this attribute in the response. 636 Here is a complete table of combinations of "notify-wait", 637 "status-code", "notify-get-interval", and Event Notification 638 Attributes Groups for Get-Notification initial (Wait and No 639 Wait) Responses and subsequent Event Wait Mode Responses (which 640 may be staying in Event Wait Mode or may be requesting the 641 Notification Recipient to leave Event Wait Mode): 643 Table 2 - Combinations of "notify-wait", "status-code", and "notify- 644 get-interval" 646 client sends: Printer returns: Printer Event 647 returns: Notification 648 "notify-wait" "status-code" "notify-get- Attribute 649 interval" Groups 651 1. 'false'* 'successful-ok' MUST return N maybe 653 2. 'false'* 'not-found' MUST NOT MUST NOT 655 3. 'false'* 'busy' MUST return N MUST NOT 657 4. 'false'* 'events- MUST NOT 'job- 658 complete' completed' 660 5. 'true' 'successful-ok' MUST NOT MUST 662 6. 'true' 'successful-ok' MUST return N maybe 664 7. 'true' 'not-found' MUST NOT MUST NOT 666 8. 'true' 'busy' MUST return N MUST NOT 668 9. 'true' 'events- MUST NOT 'job- 669 complete' completed' or 670 maybe other 672 * 'false' or client omits the "notify-wait" attribute. 674 Explanation: 676 1-4: client does not request Event Wait Mode 677 5-9: client requests Event Wait Mode 678 2,7: Subscription object not found, or was canceled earlier; 679 client should NOT try again. 680 3,8: server busy, tells client to try later; client should try 681 again in N seconds. 682 4: client polled after job completed, but before Event Life 683 expired, and got the 'job-completed' event, so the client 684 shouldn't bother trying again; client should NOT try again 685 later. 686 5: Printer returns one or more Event Notifications and is OK 687 to stay in Event Wait Mode; the client waits for more Event 688 Notifications to be returned. 690 6: Printer wants to leave Event Wait mode. Can happen on the 691 first response (with or without Event Notifications) or happen 692 on a subsequent response with or without Event Notifications; 693 the client SHOULD try again in N seconds. 694 9: Printer either (1) returns 'job-completed' event or (2) the 695 Subscription Object was canceled by either a Cancel-Job or a 696 Per-Printer Subscription expired without being renewed. For 697 case (1), at least one Event Notification MUST be returned, 698 while for case (2), it is unlikely that any Event Notifications 699 are returned; the client should NOT try again. 701 5.2.2 printer-up-time (integer(1:MAX)) 703 The value of this attribute is the Printer's "printer-up-time" 704 attribute at the time the Printer sends this response. The 705 Printer MUST return this attribute. Because each Event 706 Notification also contains the value of this attribute when the 707 event occurred, the value of this attribute lets a Notification 708 Recipient know when each Event Notification occurred relative 709 to the time of this response. 711 Group 2: Unsupported Attributes 713 See [RFC2911] section 3.1.7 for details on returning 714 Unsupported Attributes. 716 Group 3 through N: Event Notification Attributes 718 The Printer responds with one Event Notification Attributes 719 Group per matched Event Notification. The entire response is 720 considered a single Compound Event Notification (see [ipp- 721 ntfy]). The matched Event Notifications are all un-expired 722 Event Notification associated with the matched Subscription 723 Objects and MUST follow the "Event Notification Ordering" 724 requirements for Event Notifications within a Compound Event 725 Notification specified in [ipp-ntfy] section 9. In other 726 words, the Printer MUST order these Event Notification groups 727 in ascending time stamp (and sequence number) order for a 728 Subscription object. If Event Notifications for multiple 729 Subscription objects are being returned, the Notification 730 Events for the next Subscription object follow in ascending 731 time stamp order, etc. 733 Each Event Notification Group MUST contain all of attributes 734 specified in section 9.1 ("Content of Machine Consumable Event 735 Notifications") of [ipp-ntfy] with exceptions denoted by 736 asterisks in the tables below. 738 The tables below are copies of the tables in section 9.1 739 ("Content of Machine Consumable Event Notifications") of [ipp- 740 ntfy] except that each cell in the "Sends" column is a "MUST". 742 If more than one Event Notification is being returned and the 743 status of each is not the same, then the Printer MUST return a 744 "notify-status-code" attribute in each Event Notification 745 Attributes group to indicate the differing status values. 747 For an Event Notification for all Events, the Printer includes 748 the attributes shown in Table 3. 750 Table 3 - Attributes in Event Notification Content 752 Source Value Sends Source 753 Object 755 notify-subscription-id (integer(1:MAX)) MUST Subscription 757 notify-printer-uri (uri) MUST Subscription 759 notify-subscribed-event (type2 keyword) MUST Event 760 Notification 762 printer-up-time (integer(1:MAX)) * MUST Printer 764 printer-current-time (dateTime) MUST ** Printer 766 notify-sequence-number (integer (0:MAX)) MUST Subscription 768 notify-charset (charset) MUST Subscription 770 notify-natural-language (naturalLanguage) MUST Subscription 772 notify-user-data (octetString(63)) MUST *** Subscription 774 notify-text (text) MUST Event 775 Notification 777 attributes from the "notify-attributes" MUST **** Printer 778 attribute 780 attributes from the "notify-attributes" MUST **** Job 781 attribute 783 attributes from the "notify-attributes" MUST **** Subscription 784 attribute 786 * As specified in [ipp-ntfy] section 9, the value of the 787 "printer-up-time" attribute sent in each Event Notification 788 MUST be the time at which the Event occurred, not the time at 789 which the Event Notification was sent. 791 ** The Printer MUST send the "printer-current-time" attribute 792 if and only if it supports the "printer-current-time" attribute 793 on the Printer object. 795 *** If the associated Subscription Object does not contain a 796 "notify-user-data" attribute, the Printer MUST send an octet- 797 string of length 0. 799 **** If the "notify-attributes" attribute is present on the 800 Subscription Object, the Printer MUST send all attributes 801 specified by the "notify-attributes" attribute. Note: if the 802 Printer doesn't support the "notify-attributes" attribute, it 803 is not present on the associated Subscription Object. 805 For Event Notifications for Job Events, the Printer includes 806 the additional attributes shown in Table 4. 808 Table 4 - Additional Attributes in Event Notification Content for 809 Job Events 811 Source Value Sends Source 812 Object 814 job-id (integer(1:MAX)) MUST Job 816 job-state (type1 enum) MUST Job 818 job-state-reasons (1setOf type2 keyword) MUST Job 820 job-impressions-completed (integer(0:MAX)) MUST * Job 822 * The Printer MUST send the "job-impressions-completed" 823 attribute in an Event Notification only for the combinations of 824 Events and Subscribed Events shown in Table 5. 826 Table 5 - Combinations of Events and Subscribed Events for "job- 827 impressions-completed" 829 Job Event Subscribed Job Event 831 'job-progress' 'job-progress' 833 'job-completed' 'job-completed' 835 'job-completed' 'job-state-changed' 836 For Event Notification for Printer Events, the Printer includes 837 the additional attributes shown in Table 6. 839 Table 6 - Additional Attributes in Event Notification Content for 840 Printer Events 842 Source Value Sends Source 843 Object 845 printer-state (type1 enum) MUST Printer 847 printer-state-reasons (1setOf type2 keyword) MUST Printer 849 printer-is-accepting-jobs (boolean) MUST Printer 851 6 Additional Information about Subscription Template Attributes 853 The 'ippget' Delivery Method does not define any addition 854 Subscription Template attributes. The 'ippget' Delivery Method has 855 the same conformance requirements for Subscription Template 856 attributes as defined in [ipp-ntfy]. This section defines additional 857 information about Subscription Template attributes defined in [ipp- 858 ntfy]. 860 6.1 notify-pull-method (type2 keyword) 862 This Subscription Template attribute identifies the Pull Delivery 863 Method to be used for the Subscription Object (see [ipp-ntfy]). In 864 order to support the 'ippget' Pull Delivery Method defined in this 865 document, the Printer MUST support this attribute with the following 866 keyword value: 868 'ippget': indicates that the 'ippget' Pull Delivery Method is to 869 be used for this Subscription Object. 871 7 Subscription Description Attributes 873 The 'ippget' Delivery Method has the same conformance requirements 874 for Subscription Description attributes as defined in [ipp-ntfy]. 875 The 'ippget' Delivery Method does not define any addition 876 Subscription Description attributes. 878 8 Additional Printer Description Attributes 880 This section defines additional Printer Description attributes for 881 use with the 'ippget' Delivery Method. 883 8.1 ippget-event-life (integer(15:MAX)) 885 This Printer Description attribute specifies the Event Life value 886 that the Printer assigns to each Event, i.e., the number of seconds 887 after an Event occurs during which a Printer will return that Event 888 in an Event Notification in a Get-Notifications response. After the 889 Event Life expires for the Event, the Printer MAY no longer return an 890 Event Notification for that Event in a Get-Notifications response. 892 The Printer MUST support this attribute if it supports the 'ippget' 893 Delivery Method. The value MUST be 15 or more (at least 15 seconds) 894 and 60 (seconds) is the RECOMMENDED value to align with the PWG Job 895 Monitoring MIB [RFC2707] jmGeneralJobPersistence and 896 jmGeneralAttributePersistence objects. 898 For example, assume the following: 900 1.a client performs a Job Creation operation that creates a 901 Subscription Object associated with the 'ippget' Delivery 902 Method, AND 904 2.an Event associated with the new Job occurs immediately after 905 the Subscription Object is created, AND 907 3.the same client or some other client performs a Get- 908 Notifications operation such that the client is connected N 909 seconds after the Job Creation operation. 911 Then, if N is less than the value of this attribute, the client(s) 912 performing the Get-Notifications operations can expect not to miss 913 any Event-Notifications, barring some unforeseen lack of memory space 914 in the Printer. Note: The client MUST initiate the Get- 915 Notifications a time that is sufficiently less that N seconds to 916 account for network latency so that it is connected to the Printer 917 before N seconds elapses. 919 If a Printer supports the 'ippget' Delivery Method, it MUST keep 920 'completed', 'canceled', or 'aborted' Job objects in the Job 921 Retention and/or Job History phases for at least as long as this 922 attribute's value. The Printer MAY retain jobs longer that this 923 value. See [RFC2911] section 4.3.7.1 and the discussion in [ipp- 924 ntfy] 'job-completed' event) that explains that a Notification 925 Recipients can query the Job after receiving a 'job-completed' Event 926 Notification in order to find out other information about the job 927 that is 'completed', 'aborted', or 'canceled'. However, this 928 attribute has no effect on the Cancel-Subscription operation which 929 deletes the Subscription object immediately, whether or not it 930 contain the "notify-pull-method" attribute with the 'ippget' keyword 931 value. Immediately thereafter, subsequent Get-Notifications 932 Responses MUST NOT contain Event Notifications associated with the 933 canceled Subscription object. 935 9 New Values for Existing Printer Description Attributes 937 This section defines additional values for existing Printer 938 Description attributes defined in [ipp-ntfy]. 940 9.1 notify-pull-method-supported (1setOf type2 keyword) 942 The following keyword value for the "notify-pull-method-supported" 943 attribute is added in order to support the new Delivery Method 944 defined in this document: 946 'ippget' - The IPP Notification Pull Delivery Method defined in 947 this document. 949 9.2 operations-supported (1setOf type2 enum) 951 Table 7 lists the "operation-id" value defined in order to support 952 the new Get-Notifications operation defined in this document. 954 Table 7 - Operation-id assignments 956 Value Operation Name 958 0x001C Get-Notifications 960 10 New Status Codes 962 The following status code is defined as an extension for this 963 Delivery Method and is returned as the status code of the Get- 964 Notifications operation in Group 1 or Group 3 to N (see section 5.2). 966 10.1 successful-ok-events-complete (0x0007) 968 The Printer MUST return the 'successful-ok-events-complete' status 969 code to indicate when this Get-Notifications response is the last 970 response for a Subscription object, whether or not there are Event 971 Notifications being returned. This condition occurs for Event Wait 972 Mode with Notification Recipients waiting for responses when the 973 Subscription Object is: (1) canceled with a Cancel-Subscription 974 operation, (2) deleted when the Per-Printer Subscription lease time 975 expires, or (3) when the 'job-completed' event occurs for a Per-Job 976 Subscription. This condition also occurs for a Get-Notifications 977 request that a Notification Recipient makes after the job completes, 978 but before the Event Life expires. 980 11 Encoding and Transport 982 This section defines the encoding and transport considerations for 983 this Delivery Method based on [RFC2910]. 985 The encoding of a Get-Notifications Response is modeled the Get-Jobs 986 Response (see [RFC2911]). In a Get-Notifications Response, each 987 Event Notification Attributes Group MUST start with an 'event- 988 notification-attributes-tag' (see the section "Encodings of 989 Additional Attribute Tags" in [ipp-ntfy]), and end with an 'end-of- 990 attributes-tag'. In addition, for Event Wait Mode the multi- 991 part/related is used to separate each multiple response (in time) to 992 a single Get-Notifications Request. 994 The Printer returns Get-Notification Response as follows: 996 1. If the Notification Recipient client did not request Event Wait 997 Mode ("notify-wait" = 'false' or omitted), the Printer ends the 998 response with an 'end-of-attributes-tag' (see [RFC2911] Get-Jobs 999 encoding) as with any operation response. 1001 2. If the Notification Recipient client requests Event Wait Mode 1002 ("notify-wait" = 'true') and the Printer wishes to honor the 1003 request, the Printer MUST return the response as an 1004 application/ipp part inside a multi-part/related MIME media 1005 type. When one or more additional Events occur, the Printer 1006 returns each as an additional Event Notification Group using a 1007 separate application/ipp part under the multi-part/related type. 1009 3. If the client requested Event Wait Mode ("notify-wait" = 1010 'true'), but the Printer does not wish to honor the request in 1011 the initial response but wants the client explicitly poll for 1012 Event Notifications, the Printer MUST return the "notify-get- 1013 interval" operation attribute (see section 5.2.1). The Printer 1014 returns the response as an application/ipp part which MAY be 1015 inside an multi-part/related type. The client MUST accept this 1016 response and re-issue the Get-Notifications request in the 1017 future indicated by the value of the "notify-get-interval" 1018 attribute value.. 1020 4. If the client requested Event Wait Mode ("notify-wait" = 1021 'true'), and the Printer initially honored the request, but 1022 later wishes to leave Event Wait Mode, the Printer MUST return 1023 the "notify-get-interval" operation attribute (see section 1024 5.2.1). The Printer returns the response as an application/ipp 1025 part which MUST be inside an multi-part/related type. 1027 Note: All of the above is without either the Printer or the 1028 Notification Recipient closing the connection. In fact, the 1029 connection SHOULD remain open for any subsequent IPP operations. 1030 However, either the Notification Recipient or the Printer can 1031 abnormally terminate by closing the connection. But, if the Printer 1032 closes the connection too soon after returning the response, the 1033 client may not receive the response. 1035 The Printer MAY chunk the responses, but this has no significance to 1036 the IPP semantics. 1038 Note: While HTTP/1.1 allows a proxy to collect chunked responses 1039 over a period of time and return them back as a single un-chunked 1040 response (with a Content Length instead). However, in practice no 1041 proxy wants to have an infinite buffer. Also no proxy want to hold 1042 up responses, since user would be furious. 1044 This notification delivery method uses the IPP transport and encoding 1045 [RFC2910] for the Get-Notifications operation with the following 1046 extension allocated in [ipp-ntfy]: 1048 Table 8 - The "event-notification-attributes-tag" value 1050 Tag Value (Hex) Meaning 1052 0x07 "event-notification-attributes-tag" 1054 12 Conformance Requirements 1056 This section lists the conformance requirements for clients and 1057 Printers. 1059 12.1 Conformance for IPP Printers 1061 It is OPTIONAL for a Printer to support IPP Notifications as defined 1062 in [ipp-ntfy]. However, if a Printer supports IPP Notifications, the 1063 Printer MUST support the 'ippget' Delivery Method as defined in this 1064 document as one of its Delivery Methods. IPP Printers that conform 1065 to this specification: 1067 1. MUST meet the conformance requirements defined in [ipp-ntfy] for 1068 a Pull Delivery Method; 1070 2. MUST support the Get-Notifications operation defined in section 1071 5, including Event Wait Mode; 1073 3. MUST support the Subscription Template object attributes as 1074 defined in section 6; 1076 4. MUST support the Subscription Description object attributes as 1077 defined in section 7; 1079 5. MUST support the "ippget-event-life" Printer Description 1080 attribute defined in section 8.1, including retaining jobs in 1081 the Job Retention and/or Job History phases for at least as long 1082 as the value specified by the Printer's "ippget-event-life"; 1084 6. MUST support the additional values for IPP/1.1 Printer 1085 Description attributes defined in section 9; 1087 7. MUST support the 'successful-ok-events-complete' status code as 1088 described in section 10.1; 1090 8. MUST listen for the IPP Get-Notifications operation requests on 1091 IANA-assigned well-known port 631, unless explicitly configured 1092 by system administrators or site policies; 1094 9. SHOULD NOT listen for IPP Get-Notifications operation requests 1095 on any other port, unless explicitly configured by system 1096 administrators or site policies. 1098 10. MUST meet the security conformance requirements as stated in 1099 section 17.4. 1101 12.2 Conformance for IPP Clients 1103 It is OPTIONAL for an IPP Client to support IPP Notifications as 1104 defined in [ipp-ntfy]. However, if a client supports IPP 1105 Notifications, the client MUST support the 'ippget' Delivery Method 1106 as defined in this document as one of its Delivery Methods. IPP 1107 Clients that conform to this specification: 1109 1.MUST create Subscription Objects by sending Subscription 1110 Creation operation requests containing the "notify-pull-method" 1111 attribute (as opposed to the "notify-recipient-uri" attribute) 1112 using the 'ippget' keyword value (see sections 6.1 and 15.2); 1114 2.MUST send IPP Get-Notifications operation requests (see section 1115 5.1) via the port specified in the associated 'ipp' URL (if 1116 present) or otherwise via IANA assigned well-known port 631; 1118 3.MUST convert the associated 'ipp' URLs for use in IPP Get- 1119 Notifications operation to their corresponding 'http' URL forms 1120 for use in the HTTP layer according to the rules in section 5 1121 "IPP URL Scheme" in [RFC2910]. 1123 4.MUST meet the security conformance requirements as stated in 1124 section 17.5. 1126 13 Normative References 1128 [ipp-ntfy] 1129 Herriot, R., and T. Hastings, "Internet Printing Protocol/1.1: IPP 1130 Event Notifications and Subscriptions", , September 10, 2002. 1133 [RFC2119] 1134 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1135 Levels", RFC 2119 , March 1997 1137 [RFC2910] 1138 Herriot, R., Butler, S., Moore, P., and R. Tuner, "Internet 1139 Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 1140 2000. 1142 [RFC2911] 1143 deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, 1144 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 1145 September 2000. 1147 14 Informative References 1149 [notify-req] 1150 Hastings, T., deBry, R., and H. Lewis, "Internet Printing Protocol 1151 (IPP): Requirements for IPP Notifications", , work in progress, July 17, 2001. 1154 [RFC2565] 1155 Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet 1156 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1157 1999. 1159 [RFC2566] 1160 R. deBry, T. Hastings, R. Herriot, S. Isaacson, and P. Powell, 1161 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1162 April 1999. 1164 [RFC2567] 1165 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1166 2567, April 1999. 1168 [RFC2568] 1169 Zilles, S., "Rationale for the Structure and Model and Protocol for 1170 the Internet Printing Protocol", RFC 2568, April 1999. 1172 [RFC2569] 1173 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1174 LPD and IPP Protocols", RFC 2569, April 1999. 1176 [RFC2616] 1177 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1178 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1179 RFC 2616, June 1999. 1181 [RFC2707] 1182 Bergman, R., Hastings, T., Isaacson, S., and H. Lewis, "Job 1183 Monitoring MIB - V1.0", November 1999. 1185 [RFC3196] 1186 Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, 1187 "Internet Printing Protocol/1.1: Implementer's Guide", RFC3196, 1188 November 2001. 1190 15 IANA Considerations 1192 This section contains the exact information for IANA to add to the 1193 IPP Registries according to the procedures defined in RFC 2911 1194 [RFC2911] section 6. The resulting registrations will be published 1195 in the http://www.iana.org/assignments/ipp-registrations registry. 1197 Note to RFC Editors: Replace RFC NNNN below with the RFC number 1198 for this document, so that it accurately reflects the content of 1199 the information for the IANA Registry. 1201 15.1 Attribute Registrations 1203 The following table lists the attributes defined in this document. 1204 This is to be registered according to the procedures in RFC 2911 1205 [RFC2911] section 6.2. 1207 Printer Description attributes: Ref. Section: 1208 ippget-event-life (integer(15:MAX)) RFC NNNN 8.1 1210 15.2 Additional keyword attribute value registrations for existing 1211 attributes 1213 This section lists additional keyword attribute value registrations 1214 for use with existing attributes defined in other documents. These 1215 are to be registered according to the procedures in RFC 2911 1216 [RFC2911] section 6.1. 1218 keyword Attribute Values: Ref. Section: 1219 notify-pull-method (type2 keyword) [ipp-ntfy] 5.3.2 1220 notify-pull-method-supported (1setOf type2 keyword) 1221 [ipp-ntfy] 5.3.2.1 1222 ippget RFC NNNN 9.1 1224 15.3 Additional enum attribute values 1226 The following table lists the enum attribute values defined in this 1227 document. These are to be registered according to the procedures in 1228 RFC 2911 [RFC2911] section 6.1. 1230 Attribute 1231 Value Name Reference Section 1232 ------ ----------------------------- --------- ------- 1233 operations-supported (type2 enum) RFC2911 4.4.15 1234 0x001C Get-Notifications RFC NNNN 9.2 1236 15.4 Operation Registrations 1238 The following table lists the operations defined in this document. 1239 This is to be registered according to the procedures in RFC 2911 1240 [RFC2911] section 6.4. 1242 Operations: Ref. Section: 1243 Get-Notifications operation RFC NNNN 5 1245 15.5 Status code Registrations 1247 The following table lists the status codes defined in this document. 1248 This is to be registered according to the procedures in RFC 2911 1249 [RFC2911] section 6.6. 1251 Status codes: Ref. Section: 1252 successful-ok-events-complete (0x0007) RFC NNNN 10.1 1254 16 Internationalization Considerations 1256 The IPP Printer MUST localize the "notify-text" attribute as 1257 specified in section 14 of [ipp-ntfy]. 1259 In addition, when the client receives the Get-Notifications response, 1260 it is expected to localize the attributes that have the 'keyword' 1261 attribute syntax according to the charset and natural language 1262 requested in the Get-Notifications request. 1264 17 Security Considerations 1266 The IPP Model and Semantics document [RFC2911 section 8] discusses 1267 high-level security requirements (Client Authentication, Server 1268 Authentication and Operation Privacy). The IPP Transport and 1269 Encoding document [RFC2910 section 8] discusses the security 1270 requirements for the IPP protocol. Client Authentication is the 1271 mechanism by which the client proves its identity to the server in a 1272 secure manner. Server Authentication is the mechanism by which the 1273 server proves its identity to the client in a secure manner. 1274 Operation Privacy is defined as a mechanism for protecting operations 1275 from eavesdropping. 1277 The 'ippget' Delivery Method with its Get-Notifications operations 1278 leverages the security mechanism that are used in IPP/1.1 [RFC2910 1279 and RFC2911] without adding any additional security mechanisms in 1280 order to maintain the same security support as IPP/1.1. 1282 The access control model for the Get-Notifications operation defined 1283 in this document is the same as the access control model for the Get- 1284 Job-Attributes operation (see [RFC2911] section 3.2.6). The primary 1285 difference is that a Get-Notifications operation is directed at 1286 Subscription Objects rather than at Job objects, and a returned 1287 attribute group contains Event Notification attributes rather than 1288 Job object attributes. 1290 17.1 Notification Recipient client access rights 1292 The Notification Recipient client MUST have the following access 1293 rights to the Subscription object(s) targeted by the Get- 1294 Notifications operation request: 1296 The authenticated user (see [RFC2911] section 8.3) performing this 1297 operation MUST be (1) the owner of each Subscription Object 1298 identified by the "notify-subscription-ids" operation attribute 1299 (see section 5.1.1), (2) an operator or administrator of the 1300 Printer (see [RFC2911] Sections 1 and 8.5), or (3) be otherwise 1301 authorized by the Printer's administrator-configured security 1302 policy to request Event Notifications from the target Subscription 1303 Object(s). Furthermore, the Printer's security policy MAY limit 1304 the attributes returned by the Get-Notifications operation, in a 1305 manner similar to the Get-Job-Attributes operation (see [RFC2911] 1306 end of section 3.3.4.2). 1308 17.2 Printer security threats 1310 Because the Get-Notifications operation is sent in the same direction 1311 as Job Creation operations, usually by the same client, this Event 1312 Notification Delivery Method poses no additional authentication, 1313 authorization, privacy, firewall, or port assignment issues above 1314 those for the IPP Get-Job-Attributes and Get-Printer-Attributes 1315 operations (see [RFC2911] sections 3.2.6 and 3.2.5). 1317 17.3 Notification Recipient security threats 1319 Unwanted Events Notifications (spam): Unlike Push Event Notification 1320 Delivery Methods in which the IPP Printer initiates the Event 1321 Notification, with the Pull Delivery Method defined in this document, 1322 the Notification Recipient is the client who initiates the Get- 1323 Notifications operation (see section 5). Therefore, there is no 1324 chance of "spam" notifications with this method. 1326 Note: when a client stays connected to a Printer using the Event 1327 Wait Mode (see section 5.1.3) in order to receive Event Notifications 1328 as they occur, such a client can close down the IPP connection at any 1329 time, and so can avoid future unwanted Event Notifications at any 1330 time. 1332 It is true that client has control about whether to ask for Event 1333 Notifications. However, if the client subscribes to an event, and 1334 does a Get-Notifications request, the client gets all events for the 1335 Subscription Object in the sequence number range (see section 5.1.2), 1336 not just the ones the client wants. If a client subscribes to a Per- 1337 Printer Subscription job event, such as 'job-completed', and someone 1338 then starts and cancels thousands of jobs, the client would have to 1339 receive these events in addition to the ones the client is interested 1340 in. A client can protect itself better by subscribing to his own 1341 jobs using a Per-Job Subscription, rather than creating a Per-Printer 1342 subscription whose Job events apply to all jobs. 1344 17.4 Security requirements for Printers 1346 For the Get-Notifications operation defined in this document, the 1347 same Printer conformance requirements apply for supporting and using 1348 Client Authentication, Server Authentication and Operation Privacy as 1349 stated in [RFC2910] section 8 for all IPP operations. 1351 17.5 Security requirements for clients 1353 For the Get-Notifications operation defined in this document, the 1354 same client conformance requirements apply for supporting and using 1355 Client Authentication, Server Authentication and Operation Privacy as 1356 stated in [RFC2910] section 8 for all IPP operations. 1358 18 Contributors 1360 Carl Kugler and Harry Lewis contributed the basic idea of in-band 1361 "smart polling" coupled with multiple responses for a single 1362 operation on the same connection, one response for each event as it 1363 occurs. Without their continual persuasion, we would not have 1364 arrived at this Delivery Method specification and would not have been 1365 able to agree on a single REQUIRED Delivery Method for IPP. 1367 Carl Kugler 1368 IBM 1369 P.O. Box 1900 1370 Boulder, CO 80301-9191 1372 Phone: 1373 Fax: 1374 e-mail: kugler@us.ibm.com 1376 19 Authors' Addresses 1378 Robert Herriot 1379 706 Colorado Ave. 1381 Palo Alto, CA 94303 1383 Phone: 650-327-4466 1384 Fax: 650-327-4466 1385 email: bob@herriot.com 1387 Thomas N. Hastings 1388 Xerox Corporation 1389 737 Hawaii St. ESAE 231 1390 El Segundo CA 90245 1392 Phone: 310-333-6413 1393 Fax: 310-333-5514 1394 email: hastings@cp10.es.xerox.com 1396 Harry Lewis 1397 IBM 1398 P.O. Box 1900 1399 Boulder, CO 80301-9191 1401 Phone: 303-924-5337 1402 FAX: 1403 e-mail: harryl@us.ibm.com 1405 IPP Web Page: http://www.pwg.org/ipp/ 1406 IPP Mailing List: ipp@pwg.org 1408 To subscribe to the ipp mailing list, send the following email: 1409 1) send it to majordomo@pwg.org 1410 2) leave the subject line blank 1411 3) put the following two lines in the message body: 1412 subscribe ipp 1413 end 1415 Implementers of this specification document are encouraged to join 1416 the IPP Mailing List in order to participate in any discussions of 1417 clarification issues and review of registration proposals for 1418 additional attributes and values. In order to reduce spam the 1419 mailing list rejects mail from non-subscribers, so you must subscribe 1420 to the mailing list in order to send a question or comment to the 1421 mailing list. 1423 20 Description of Base IPP documents (Informative) 1425 The base set of IPP documents includes: 1427 Design Goals for an Internet Printing Protocol [RFC2567] 1428 Rationale for the Structure and Model and Protocol for the Internet 1429 Printing Protocol [RFC2568] 1430 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 1431 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 1432 Internet Printing Protocol/1.1: Implementer's Guide [RFC3196] 1433 Mapping between LPD and IPP Protocols [RFC2569] 1435 The "Design Goals for an Internet Printing Protocol" document takes a 1436 broad look at distributed printing functionality, and it enumerates 1437 real-life scenarios that help to clarify the features that need to be 1438 included in a printing protocol for the Internet. It identifies 1439 requirements for three types of users: end users, operators, and 1440 administrators. It calls out a subset of end user requirements that 1441 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 1442 been added to IPP/1.1. 1444 The "Rationale for the Structure and Model and Protocol for the 1445 Internet Printing Protocol" document describes IPP from a high level 1446 view, defines a roadmap for the various documents that form the suite 1447 of IPP specification documents, and gives background and rationale 1448 for the IETF working group's major decisions. 1450 The "Internet Printing Protocol/1.1: Model and Semantics" document 1451 describes a simplified model with abstract objects, their attributes, 1452 and their operations that are independent of encoding and transport. 1453 It introduces a Printer and a Job object. The Job object optionally 1454 supports multiple documents per Job. It also addresses security, 1455 internationalization, and directory issues. 1457 The "Internet Printing Protocol/1.1: Encoding and Transport" document 1458 is a formal mapping of the abstract operations and attributes defined 1459 in the model document onto HTTP/1.1 [RFC2616]. It defines the 1460 encoding rules for a new Internet MIME media type called 1461 "application/ipp". This document also defines the rules for 1462 transporting over HTTP a message body whose Content-Type is 1463 "application/ipp". This document defines the 'ipp' scheme for 1464 identifying IPP printers and jobs. 1466 The "Internet Printing Protocol/1.1: Implementer's Guide" document 1467 gives insight and advice to implementers of IPP clients and IPP 1468 objects. It is intended to help them understand IPP/1.1 and some of 1469 the considerations that may assist them in the design of their client 1470 and/or IPP object implementations. For example, a typical order of 1471 processing requests is given, including error checking. Motivation 1472 for some of the specification decisions is also included. 1474 The "Mapping between LPD and IPP Protocols" document gives some 1475 advice to implementers of gateways between IPP and LPD (Line Printer 1476 Daemon) implementations. 1478 21 Full Copyright Statement 1480 Copyright (C) The Internet Society (2002). All Rights Reserved. 1482 This document and translations of it may be copied and furnished to 1483 others, and derivative works that comment on or otherwise explain it 1484 or assist in its implementation may be prepared, copied, published 1485 and distributed, in whole or in part, without restriction of any 1486 kind, provided that the above copyright notice and this paragraph are 1487 included on all such copies and derivative works. However, this 1488 document itself may not be modified in any way, such as by removing 1489 the copyright notice or references to the Internet Society or other 1490 Internet organizations, except as needed for the purpose of 1491 developing Internet standards in which case the procedures for 1492 copyrights defined in the Internet Standards process must be 1493 followed, or as required to translate it into languages other than 1494 English. 1496 The limited permissions granted above are perpetual and will not be 1497 revoked by the Internet Society or its successors or assigns. 1499 This document and the information contained herein is provided on an 1500 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1501 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1502 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1503 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1504 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1506 Acknowledgement 1508 Funding for the RFC Editor function is currently provided by the 1509 Internet Society.