idnits 2.17.1 draft-ietf-ipp-notify-get-10.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 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. == 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 mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 260 has weird spacing: '...ll), or a pu...' == Line 1436 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 132, but not defined ** Obsolete undefined reference: RFC 2911 (Obsoleted by RFC 8011) == Missing Reference: 'RFC 2910' is mentioned on line 132, but not defined ** Obsolete undefined reference: RFC 2910 (Obsoleted by RFC 8010) == Missing Reference: 'RFCNNNN' is mentioned on line 1202, but not defined == Unused Reference: 'RFC2565' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'RFC2566' is defined on line 1101, 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: 10 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Printing Protocol WG R. Herriot 2 INTERNET-DRAFT Global Workflow Solutions 3 T. Hastings 4 Updates: RFC 2911 and [ipp-ntfy] Xerox Corp. 5 [Target category: standards track] H. Lewis 6 Expires: December 21,2004 IBM Corp. 7 June 21,2004 9 Internet Printing Protocol (IPP): 10 The 'ippget' Delivery Method for Event Notifications 12 Copyright (C) The Internet Society (2003). All Rights Reserved. 14 Status of this Memo: 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed as 28 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes an extension to the Internet Printing 32 Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This 33 document specifies the 'ippget' Pull Delivery Method for use with the 34 "Internet Printing Protocol (IPP): Event Notifications and 35 Subscriptions" specification (ipp-ntfy). This IPPGET Delivery Method 36 is REQUIRED for all clients and Printers that support ipp-ntfy. The 37 Notification Recipient, acting as a client, fetches (pulls) Event 38 Notifications using the Get-Notifications operation defined in this 39 document. 41 Table of Contents 43 1 Introduction.....................................................4 45 2 Terminology......................................................4 46 2.1 Conformance Terminology........................................4 47 2.2 Other terminology..............................................5 49 3 Model and Operation..............................................5 51 4 General Information..............................................7 53 5 Get-Notifications operation......................................8 54 5.1 Get-Notifications Request......................................9 55 5.1.1 notify-subscription-ids (1setOf integer(1:MAX)).............10 56 5.1.2 notify-sequence-numbers (1setOf integer(1:MAX)).............10 57 5.1.3 notify-wait (boolean).......................................11 58 5.2 Get-Notifications Response....................................11 59 5.2.1 notify-get-interval (integer(0:MAX))........................14 60 5.2.2 printer-up-time (integer(1:MAX))............................16 62 6 Additional Information about Subscription Template Attributes...19 63 6.1 notify-pull-method (type2 keyword)............................19 65 7 Subscription Description Attributes.............................19 67 8 Additional Printer Description Attributes.......................19 68 8.1 ippget-event-life (integer(15:MAX))...........................19 70 9 New Values for Existing Printer Description Attributes..........21 71 9.1 notify-pull-method-supported (1setOf type2 keyword)...........21 72 9.2 operations-supported (1setOf type2 enum)......................21 74 10 New Status Codes...............................................21 75 10.1 successful-ok-events-complete (0x0007).......................21 77 11 Encoding and Transport.........................................22 79 12 Conformance Requirements.......................................23 80 12.1 Conformance for IPP Printers.................................23 81 12.2 Conformance for IPP Clients..................................24 83 13 Normative References...........................................25 85 14 Informative References.........................................25 87 15 IANA Considerations............................................26 88 15.1 Attribute Registrations......................................26 89 15.2 Delivery Method and Additional keyword attribute value 90 registrations for existing attributes.............................26 91 15.3 Additional enum attribute values.............................27 92 15.4 Operation Registrations......................................27 93 15.5 Status code Registrations....................................27 95 16 Intellectual Property..........................................28 97 17 Internationalization Considerations............................28 99 18 Security Considerations........................................28 100 18.1 Notification Recipient client access rights..................29 101 18.2 Printer security threats.....................................29 102 18.3 Notification Recipient security threats......................29 103 18.4 Security requirements for Printers...........................30 104 18.5 Security requirements for clients............................30 106 19 Contributors...................................................30 108 20 Authors' Addresses.............................................31 110 21 Description of Base IPP documents (Informative)................31 112 22 Full Copyright Statement.......................................32 114 Table of Tables 116 Table 1 - Information about the Delivery Method....................7 117 Table 2 - Combinations of "notify-wait", "status-code", and "notify- 118 get-interval".................................................15 119 Table 3 - Attributes in Event Notification Content................17 120 Table 4 - Additional Attributes in Event Notification Content for Job 121 Events........................................................18 122 Table 5 - Combinations of Events and Subscribed Events for "job- 123 impressions-completed"........................................18 124 Table 6 - Additional Attributes in Event Notification Content for 125 Printer Events................................................19 126 Table 7 - Operation-id assignments................................21 127 Table 8 - The "event-notification-attributes-tag" value...........23 129 1 Introduction 131 This document describes an extension to the Internet Printing 132 Protocol/1.1: Model and Semantics [RFC 2911], [RFC 2910]. This 133 document specifies the 'ippget' Pull Delivery Method for use with the 134 "Internet Printing Protocol (IPP): Event Notifications and 135 Subscriptions" specification [ipp-ntfy]. This IPPGET Delivery Method 136 is REQUIRED for all clients and Printers that support [ipp-ntfy]. 137 The Notification Recipient, acting as a client, fetches (pulls) Event 138 Notifications using the Get-Notifications operation defined in this 139 document. For a description of the base IPP documents, see section 140 21 of this document. For a description of the IPP Event Notification 141 Model, see [ipp-ntfy]. 143 With this Pull Delivery Method, when an Event occurs, the Printer 144 saves the Event Notification for a period of time called the Event 145 Life. The Notification Recipient fetches (pulls) the Event 146 Notifications using the Get-Notifications operation. This operation 147 causes the Printer to return all Event Notifications held for the 148 specified Subscription object(s). If the Notification Recipient has 149 selected the Event Wait Mode option to wait for additional Event 150 Notifications, the Printer MAY continue to return Event Notifications 151 to the Notification Recipient as asynchronous Get-Notification 152 responses as Events occur using the transaction originated by the 153 Notification Recipient. 155 The Notification Recipient can terminate Event Wait Mode (without 156 closing the connection) by supplying the "notify-wait" (boolean) 157 attribute with a 'false' value in a subsequent Get-Notifications 158 request. Similarly, the Printer can terminate Event Wait Mode 159 (without closing the connection) by returning the "notify-get- 160 interval" (integer) operation attribute in a Get-Notifications 161 response which tells the Notification Recipient how long to wait 162 before trying again. 164 2 Terminology 166 This section defines the following terms that are used throughout 167 this document: 169 2.1 Conformance Terminology 171 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 172 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 173 conformance as defined in RFC 2119 [RFC2119] and [RFC2911] section 174 12.1. If an implementation supports the extension defined in this 175 document, then these terms apply; otherwise, they do not. These 176 terms define conformance to this document only; they do not affect 177 conformance to other documents, unless explicitly stated otherwise. 179 2.2 Other terminology 181 This document uses the same terminology as [RFC2911], such as 182 "client", "Printer", "Job", "attribute", "attribute value", 183 "keyword", "operation", "request", "response", and "support" with the 184 same meanings. This document also uses terminology defined in [ipp- 185 ntfy], such as "Subscription (object)", "Notification Recipient", 186 "Event", "Event Notification", "Compound Event Notification", "Event 187 Life", and "Event Notification Attribute Group" with the same 188 meanings. In addition, this document defines the following terms for 189 use in this document: 191 Event Wait Mode: The mode requested by a Notification Recipient 192 client in its Get-Notifications Request and granted by a Printer 193 to keep the connection open while the Printer sends subsequent 194 Event Notifications to the Notification Recipient as they occur 195 as additional Get-Notification operation responses. 197 3 Model and Operation 199 In a Subscription Creation Operation, when the "notify-pull-method" 200 attribute is present and has the 'ippget' keyword value, the client 201 is requesting that the Printer use the 'ippget' Pull Delivery Method 202 for the Event Notifications associated with the new Subscription 203 Object. 205 When an Event occurs, the Printer MUST generate an Event Notification 206 and MUST assign it the Event Life. The Printer MUST hold an Event 207 Notification for its assigned Event Life. 209 When a Notification Recipient wants to receive Event Notifications 210 for a Subscription object, it performs the Get-Notifications 211 operation supplying the Subscription object's subscription-id, which 212 causes the Printer to return all un-expired Event Notifications held 213 for that Subscription object. If the Notification Recipient has 214 selected the Event Wait Mode option to wait for additional Event 215 Notifications, the response to the Get-Notifications request 216 continues indefinitely as the Printer continues to send Event 217 Notifications in the response as Events occur for that Subscription 218 object. 220 When the Notification Recipient requests Event Notifications for per- 221 Job Subscription Objects, the Notification Recipient typically 222 performs the Get-Notifications operation within a second of 223 performing the Subscription Creation operation. Because the Printer 224 MUST save Event Notifications for at least 15 seconds (see section 225 8.1), the Notification Recipient is unlikely to miss any Event 226 Notifications that occur between the Subscription Creation and the 227 Get-Notifications operation. 229 The 'ippget' Delivery Method is designed primarily for (1) a client 230 that wants to get Events (from the job's per-Job Subscription object) 231 for a job that it has submitted and (2) for a privileged client that 232 wants to get all job or printer Events from a per-Printer 233 Subscription object. 235 4 General Information 237 If a Printer supports this Delivery Method, the following are its 238 characteristics. 240 Table 1 - Information about the Delivery Method 242 Document Method Conformance Requirement Delivery Method 243 Realization 245 1. What is the URL scheme name for the 'ippget' keyword method 246 Push Delivery Method or the keyword name 247 method name for the Pull Delivery 248 Method? 249 2. Is the Delivery Method REQUIRED, REQUIRED 250 RECOMMENDED or OPTIONAL for an IPP 251 Printer to support? 252 3. What transport and delivery protocols IPP with one new 253 does the Printer use to deliver the operation. 254 Event Notification Content, i.e., what 255 is the entire network stack? 256 4. Can several Event Notifications be Yes. 257 combined into a Compound Event 258 Notification? 259 5. Is the Delivery Method initiated by This Delivery Method is 260 the Notification Recipient (pull), or a pull method with 261 by the Printer (push)? aspects of a push 262 method, though the 263 Printer does not 264 initiate the operation. 265 6. Is the Event Notification content Machine Consumable 266 Machine Consumable or Human 267 Consumable? 268 7. What section in this document answers Section 5 269 the following question? For a Machine 270 Consumable Event Notification, what is 271 the representation and encoding of 272 values defined in section 9.1 of [ipp- 273 ntfy] and the conformance requirements 274 thereof? For a Human Consumable Event 275 Notification, what is the 276 representation and encoding of pieces 277 of information defined in section 9.2 278 of [ipp-ntfy] and the conformance 279 requirements thereof? 280 8. What are the latency and reliability Same as IPP and the 281 of the transport and delivery underlying HTTP 282 protocol? transport 284 9. What are the security aspects of the Same as IPP and the 285 transport and delivery protocol, e.g., underlying HTTP 286 how it is handled in firewalls? transport and in the 287 same direction, so no 288 new firewall 289 considerations. 290 10.What are the content length None 291 restrictions? 292 11.What are the additional values or None 293 pieces of information that a Printer 294 sends in an Event Notification content 295 and the conformance requirements 296 thereof? 297 12.What are the additional Subscription None 298 Template and/or Subscription 299 Description attributes and the 300 conformance requirements thereof? 301 13.What are the additional Printer "ipp-event-life" 302 Description attributes and the (integer (15: MAX)) 303 conformance requirements thereof? 305 5 Get-Notifications operation 307 This operation is issued by a client acting in the role of a 308 Notification Recipient requesting the Printer to return all Event 309 Notifications held for the identified Subscription object(s). 311 A Printer MUST support this operation, MUST accept the request in any 312 state (see [RFC2911] "printer-state" and "printer-state-reasons" 313 attributes), and MUST remain in the same state with the same 314 "printer-state-reasons" values. 316 When a Printer performs this operation, it MUST return all and only 317 those Event Notifications: 319 1. Whose associated Subscription Object's "notify-subscription-id" 320 Subscription Description attribute equals one of the values of 321 the "notify-subscription-ids" (1setOf integer(1:MAX)) operation 322 attribute AND 324 2. Whose associated Subscription Object's contains the "notify- 325 pull-method" attribute and it has the 'ippget' keyword value AND 327 3. Whose "notify-sequence-number" is equal to or greater than the 328 corresponding value of the "notify-sequence-numbers (1setOf 329 integer(1:MAX)) operation attribute, if supplied AND 331 4. Whose Event Life has not yet expired AND 333 5. Where the Notification Recipient client has read-access rights 334 to the identified Subscription Object (see Access Rights 335 paragraph below). 337 The Notification Recipient client MUST either: (a) request Event Wait 338 Mode by supplying the "notify-wait" operation attribute with a 'true' 339 value or (b) suppress Event Wait Mode by omitting the "notify-wait" 340 operation attribute or by supplying it with a 'false' value. In 341 order to terminate Event Wait Mode subsequently, the Notification 342 Recipient client MUST close the connection. In order to terminate 343 Event Wait Mode, the Printer MUST either (a) return the "notify-get- 344 interval" operation attribute in a Get-Notifications response 345 (RECOMMENDED behavior) or (b) close the connection. The "notify-get- 346 interval" operation attributes tells the Notification Recipient how 347 long to wait before trying a subsequent Get-Notifications request. 349 Access Rights: The authenticated user (see [RFC2911] section 8.3) 350 performing this operation MUST be (1) the owner of each Subscription 351 Object identified by the "notify-subscription-ids" operation 352 attribute (see section 5.1.1), (2) an operator or administrator of 353 the Printer (see [RFC2911] Sections 1 and 8.5), or (3) be otherwise 354 authorized by the Printer's administrator-configured security policy 355 to request Event Notifications from the target Subscription 356 Object(s). Otherwise, the IPP Printer MUST reject the operation and 357 return: 'client-error-forbidden', 'client-error-not-authenticated', 358 or 'client-error-not-authorized' status code as appropriate. 359 Furthermore, the Printer's security policy MAY limit the attributes 360 returned by the Get-Notifications operation, in a manner similar to 361 the Get-Job-Attributes operation (see [RFC2911] end of section 362 3.3.4.2). 364 5.1 Get-Notifications Request 366 The following groups of attributes are part of the Get-Notifications 367 Request: 368 Group 1: Operation Attributes 369 Natural Language and Character Set: 370 The "attributes-charset" and "attributes-natural-language" 371 attributes as described in [RFC2911] section 3.1.4.1. 373 Target: 374 The "printer-uri" (uri) operation attribute which is the target 375 for this operation as described in [RFC2911] section 3.1.5. 377 Requesting User Name: 378 The "requesting-user-name" (name(MAX)) attribute SHOULD be 379 supplied by the client as described in [RFC2911] section 8.3. 381 5.1.1 notify-subscription-ids (1setOf integer(1:MAX)) 383 This attribute identifies one or more Subscription objects for 384 which Events are requested. The client MUST supply this 385 attribute with at least one value. The Printer object MUST 386 support this attribute with multiple values. 388 If no Subscription Object exists with the supplied identifier 389 or the identified Subscription Object does not contain the 390 "notify-pull-method" attribute with the 'ippget' keyword value, 391 the Printer MUST return the 'client-error-not-found' status 392 code. 394 Note: The name of both the "notify-subscription-ids" and 395 "notify-sequence-numbers" end in 's', since they are 396 multi-valued. However, there are other occurrences of 397 these attribute names without the 's' that are single 398 valued. 400 5.1.2 notify-sequence-numbers (1setOf integer(1:MAX)) 402 This attribute specifies one or more lowest Event Notification 403 sequence number values for the Subscription objects identified 404 by the corresponding values of the "notify-subscription-ids" 405 operation attribute. The Notification Recipient SHOULD supply 406 this attribute and the number of values SHOULD be the same as 407 the number of values of the "notify-subscriptions-ids" 408 attribute. The Printer MUST support this attribute with 409 multiple values. 411 The Printer MUST NOT return Notification Events with lower 412 sequence numbers for the corresponding Subscription object. 413 Therefore, by supplying the proper values for this attribute 414 the Notification Recipient can prevent getting the same Event 415 Notifications from a Subscription object that were returned on 416 a previous Get-Notifications request. The Notification 417 Recipient SHOULD remember the highest "notify-sequence-number" 418 value returned for each Subscription object requested and 419 SHOULD pass that value for each requested Subscription object 420 on the next Get-Notifications request. 422 If the Notification Recipient supplies fewer values for this 423 attribute (including omitting this attribute) than for the 424 "notify-subscription-ids" operation attribute, the Printer 425 assumes a '1' value for each missing value. A value of '1' 426 causes the Printer to return any un-expired Event Notification 427 for that Subscription object, since '1' is the lowest possible 428 sequence number. If the Notification Recipient supplies more 429 values for this attribute than the number of values for the 430 "notify-subscription-ids" operation attribute, the Printer 431 ignores the extra values. 433 Note: If a Notification Recipient performs two consecutive Get- 434 Notifications operations with the same value for "notify- 435 sequence-number" (or omits the attribute), the time stamp of 436 the first Event Notification in the second Get-Notifications 437 Response may be less than the time stamp of the last Event 438 Notification in the first Get-Notification Response. This 439 happens because the Printer sends all unexpired Event 440 Notification with a sequence number equal or higher according 441 to the ordering specified in [ipp-ntfy] and some Event 442 Notifications from the first Get-Notifications operation may 443 not have expired by the time the second Get-Notifications 444 operation occurs. 446 5.1.3 notify-wait (boolean) 448 This value indicates whether or not the Notification Recipient 449 wants Event Wait Mode. The client MAY supply this attribute. 450 The Printer object MUST support both values of this attribute. 452 If the client supplies the 'false' value or omits this 453 attribute, the client is not requesting Event Wait Mode. If 454 the value is 'true', the client is requesting Event Wait Mode. 455 See the beginning of section 5.2 for the rules for Event Wait 456 Mode. 458 5.2 Get-Notifications Response 460 The Printer has the following options for responding to a Get- 461 Notifications Request: 463 1. The Printer can reject the request and return the 'server-error- 464 busy' status code, if the Printer is too busy to accept this 465 operation at this time. In this case, the Printer MUST return 466 the "get-notify-interval" operation attribute to indicate when 467 the client SHOULD try again. 469 2. If the Notification Recipient did not request Event Wait Mode 470 ("notify-wait-mode" = 'false' or omitted), the Printer MUST 471 return immediately whatever Event Notifications it currently 472 holds in the requested Subscription object(s) and MUST return 473 the "notify-get-interval" operation attribute with number of 474 seconds from now at which the Notification Recipient SHOULD 475 repeat the Get-Notifications Request to get future Event 476 Notifications. 478 3. If the Notification Recipient requested Event Wait Mode 479 ("notify-wait-mode" = 'true'), the Printer MUST return 480 immediately whatever Event Notifications it currently holds in 481 the requested Subscription object(s) and MUST continue to return 482 Event Notifications as they occur until all of the requested 483 Subscription Objects are canceled. A Subscription Object is 484 canceled either via the Cancel-Subscription operation or by the 485 Printer (e.g., the Subscription Object is canceled when the 486 associated Job completes and is no longer in the Job Retention 487 or Job History phase - see the "ippget-event-life 488 (integer(15:MAX))" attribute discussion in section 8.1). 490 However, the Printer MAY decide to terminate Event Wait Mode at 491 any time, including in the first response. In this case the 492 Printer MUST return the "notify-get-interval" operation 493 attribute. This attribute indicates that the Printer wishes to 494 leave Event Wait Mode and the number of seconds in the future 495 that the Notification Recipient SHOULD try the Get-Notifications 496 operation again. The Notification Recipient MUST accept this 497 response and MUST disconnect. If the Notification Recipient 498 does not disconnect, the Printer SHOULD do so. 500 From the Notification Recipient's view, the response appears as an 501 initial burst of data, which includes the Operation Attributes Group 502 and one Event Notification Attributes Group per Event Notification 503 that the Printer is holding. After the initial burst of data, if the 504 Notification Recipient has selected the Event Wait Mode option to 505 wait for additional Event Notifications, the Notification Recipient 506 receives occasional Event Notification Attribute Groups. Proxy 507 servers may delay some Event Notifications or cause time-outs to 508 occur. The client MUST be prepared to perform the Get-Notifications 509 operation again when time-outs occur. 511 Each attribute is encoded using the IPP rules for encoding attributes 512 [RFC2910] and MAY be encoded in any order. Note: the Get-Jobs 513 response in [RFC2911] acts as a model for encoding multiple groups of 514 attributes. See section 11 for the encoding and transport rules. 516 The following groups of attributes are part of the Get-Notifications 517 Response: 518 Group 1: Operation Attributes 519 Status Message: 520 In addition to the REQUIRED status code returned in every 521 response, the response OPTIONALLY includes a "status-message" 522 (text(255)) and/or a "detailed-status-message" (text(MAX)) 523 operation attribute as described in [RFC2911] sections 13 and 524 3.1.6. 526 The Printer can return any status codes defined in [RFC2911]. 527 If the status code is not 'successful-xxx', the Printer MUST 528 NOT return any Event Notification Attribute groups. The 529 following is a description of the important status codes: 531 successful-ok: the response contains all Event Notification 532 associated with the specified subscription-ids that had 533 been supplied in the "notify-subscription-ids" operation 534 attribute in the request. If the requested Subscription 535 Objects have no associated Event Notification, the 536 response MUST contain zero Event Notifications. 537 successful-ok-events-complete: indicate when this return 538 is the last return for all Subscription objects that 539 match the request, whether or not there are Event 540 Notifications being returned. This condition occurs for 541 Event Wait Mode with Notification Recipients waiting for 542 responses when the Subscription Object is: (1) canceled 543 with a Cancel-Subscription operation, (2) deleted when 544 the Per-Printer Subscription lease time expires, or (3) 545 when the 'job-completed' event occurs for a Per-Job 546 Subscription. This condition also occurs for a Get- 547 Notifications request that a Notification Recipient makes 548 after the job completes, but before the Event Life 549 expires. See section 10.1. 550 client-error-not-found: The Printer has no Subscription 551 Object's whose "notify-subscription-id" attribute equals 552 any of the values of the "notify-subscription-ids" 553 operation attribute supplied or the identified 554 Subscription Object does not contain the "notify-pull- 555 method" attribute with the 'ippget' keyword value. 556 server-error-busy: The Printer is too busy to accept this 557 operation. The Printer SHOULD return the "notify-get- 558 interval" operation attribute in the Operation Attributes 559 of the response, then the Notification Recipient SHOULD 560 wait for the number of seconds specified by the "notify- 561 get-interval" operation attribute before performing this 562 operation again. If the "notify-get-interval" Operation 563 Attribute is not present, the Notification Recipient 564 SHOULD use the normal network back-off algorithms for 565 determining when to perform this operation again. 567 Natural Language and Character Set: 568 The "attributes-charset" and "attributes-natural-language" 569 attributes as described in [RFC2911] section 3.1.4.2. 571 The Printer MUST use the values of "notify-charset" and 572 "notify-natural-language", respectively, from one Subscription 573 Object associated with the Event Notifications in this 574 response. 576 Normally, there is only one matched Subscription Object, or the 577 value of the "notify-charset" and "notify-natural-language" 578 attributes is the same in all Subscription Objects. If not, 579 the Printer MUST pick one Subscription Object from which to 580 obtain the value of these attributes. The algorithm for 581 picking the Subscription Object is implementation dependent. 582 The choice of natural language is not critical because 'text' 583 and 'name' values can override the "attributes-natural- 584 language" operation attribute. The Printer's choice of charset 585 is critical because a bad choice may leave it unable to send 586 some 'text' and 'name' values accurately. 588 5.2.1 notify-get-interval (integer(0:MAX)) 590 The value of this operation attribute is the number of seconds 591 that the Notification Recipient SHOULD wait before trying the 592 Get-Notifications operation again. The Printer MUST return 593 this operation attribute if: (1) it is too busy to return 594 events, (2) the Notification Recipient client did not request 595 Event Wait Mode, or (3) the Printer is terminating Event Wait 596 Mode. The client MUST accept this attribute and SHOULD re- 597 issue the Get-Notifications operation (with or without "notify- 598 wait" = 'true') the indicated number of seconds in the future 599 in order to get more Event Notifications This value is 600 intended to help the client be a good network citizen. 602 The value of this attribute MUST be at least as large as the 603 value of the Printer's "ippget-event-life" Printer Description 604 attribute (see section 8.1). The Printer MAY return a value 605 that is larger than the value of the "ippget-event-life" 606 Printer Description attribute provided that the Printer 607 increases the Event Life for this Subscription object, so that 608 Notification Recipients taking account of the larger value and 609 polling with a longer interval will not miss events. Note; 610 implementing such an algorithm requires some hidden attributes 611 in the Subscription object that are IMPLEMENTATION DEPENDENT. 613 If the Printer wants to remain in Event Wait Mode, then the 614 Printer MUST NOT return this attribute in the response. 616 Here is a complete table of combinations of "notify-wait", 617 "status-code", "notify-get-interval", and Event Notification 618 Attributes Groups for Get-Notification initial (Wait and No 619 Wait) Responses and subsequent Event Wait Mode Responses (which 620 may be staying in Event Wait Mode or may be requesting the 621 Notification Recipient to leave Event Wait Mode): 623 Table 2 - Combinations of "notify-wait", "status-code", and "notify- 624 get-interval" 626 client sends: Printer returns: Printer Event 627 returns: Notification 628 "notify-wait" "status-code" "notify-get- Attribute 629 interval" Groups 631 1. 'false'* 'successful-ok' MUST return N maybe 632 2. 'false'* 'not-found' MUST NOT MUST NOT 633 3. 'false'* 'busy' MUST return N MUST NOT 634 4. 'false'* 'events- MUST NOT 'job- 635 complete' completed' 636 5. 'true' 'successful-ok' MUST NOT MUST 637 6. 'true' 'successful-ok' MUST return N maybe 638 7. 'true' 'not-found' MUST NOT MUST NOT 639 8. 'true' 'busy' MUST return N MUST NOT 640 9. 'true' 'events- MUST NOT 'job- 641 complete' completed' or 642 maybe other 643 * 'false' or client omits the "notify-wait" attribute. 645 Explanation: 647 1-4: client does not request Event Wait Mode 648 5-9: client requests Event Wait Mode 649 2,7: Subscription object not found, or was canceled earlier; 650 client should NOT try again. 651 3,8: server busy, tells client to try later; client should try 652 again in N seconds. 653 4: client polled after job completed, but before Event Life 654 expired, and got the 'job-completed' event, so the client 655 shouldn't bother trying again; client should NOT try again 656 later. 657 5: Printer returns one or more Event Notifications and is OK 658 to stay in Event Wait Mode; the client waits for more Event 659 Notifications to be returned. 660 6: Printer wants to leave Event Wait mode. Can happen on the 661 first response (with or without Event Notifications) or happen 662 on a subsequent response with or without Event Notifications; 663 the client SHOULD try again in N seconds. 664 9: Printer either (1) returns 'job-completed' event or (2) the 665 Subscription Object was canceled by either a Cancel-Job or a 666 Per-Printer Subscription expired without being renewed. For 667 case (1), at least one Event Notification MUST be returned, 668 while for case (2), it is unlikely that any Event Notifications 669 are returned; the client should NOT try again. 671 5.2.2 printer-up-time (integer(1:MAX)) 673 The value of this attribute is the Printer's "printer-up-time" 674 attribute at the time the Printer sends this response. The 675 Printer MUST return this attribute. Because each Event 676 Notification also contains the value of this attribute when the 677 event occurred, the value of this attribute lets a Notification 678 Recipient know when each Event Notification occurred relative 679 to the time of this response. 681 Group 2: Unsupported Attributes 682 See [RFC2911] section 3.1.7 for details on returning 683 Unsupported Attributes. 685 Group 3 through N: Event Notification Attributes 686 The Printer responds with one Event Notification Attributes 687 Group per matched Event Notification. The entire response is 688 considered a single Compound Event Notification (see [ipp- 689 ntfy]). The matched Event Notifications are all un-expired 690 Event Notification associated with the matched Subscription 691 Objects and MUST follow the "Event Notification Ordering" 692 requirements for Event Notifications within a Compound Event 693 Notification specified in [ipp-ntfy] section 9. In other 694 words, the Printer MUST order these Event Notification groups 695 in ascending time stamp (and sequence number) order for a 696 Subscription object. If Event Notifications for multiple 697 Subscription objects are being returned, the Notification 698 Events for the next Subscription object follow in ascending 699 time stamp order, etc. 701 Each Event Notification Group MUST contain all of attributes 702 specified in section 9.1 ("Content of Machine Consumable Event 703 Notifications") of [ipp-ntfy] with exceptions denoted by 704 asterisks in the tables below. 706 The tables below are copies of the tables in section 9.1 707 ("Content of Machine Consumable Event Notifications") of [ipp- 708 ntfy] except that each cell in the "Sends" column is a "MUST". 710 If more than one Event Notification is being returned and the 711 status of each is not the same, then the Printer MUST return a 712 "notify-status-code" attribute in each Event Notification 713 Attributes group to indicate the differing status values. 715 For an Event Notification for all Events, the Printer includes 716 the attributes shown in Table 3. 718 Table 3 - Attributes in Event Notification Content 720 Source Value Sends Source 721 Object 723 notify-subscription-id (integer(1:MAX)) MUST Subscription 724 notify-printer-uri (uri) MUST Subscription 725 notify-subscribed-event (type2 keyword) MUST Event 726 Notification 727 printer-up-time (integer(1:MAX)) * MUST Printer 728 printer-current-time (dateTime) MUST ** Printer 729 notify-sequence-number (integer (0:MAX)) MUST Subscription 730 notify-charset (charset) MUST Subscription 731 notify-natural-language (naturalLanguage) MUST Subscription 732 notify-user-data (octetString(63)) MUST *** Subscription 733 notify-text (text) MUST Event 734 Notification 735 attributes from the "notify-attributes" MUST **** Printer 736 attribute 737 attributes from the "notify-attributes" MUST **** Job 738 attribute 739 attributes from the "notify-attributes" MUST **** Subscription 740 attribute 742 * As specified in [ipp-ntfy] section 9, the value of the 743 "printer-up-time" attribute sent in each Event Notification 744 MUST be the time at which the Event occurred, not the time at 745 which the Event Notification was sent. 747 ** The Printer MUST send the "printer-current-time" attribute 748 if and only if it supports the "printer-current-time" attribute 749 on the Printer object. 751 *** If the associated Subscription Object does not contain a 752 "notify-user-data" attribute, the Printer MUST send an octet- 753 string of length 0. 755 **** If the "notify-attributes" attribute is present on the 756 Subscription Object, the Printer MUST send all attributes 757 specified by the "notify-attributes" attribute. Note: if the 758 Printer doesn't support the "notify-attributes" attribute, it 759 is not present on the associated Subscription Object. 761 For Event Notifications for Job Events, the Printer includes 762 the additional attributes shown in Table 4. 764 Table 4 - Additional Attributes in Event Notification Content for 765 Job Events 767 Source Value Sends Source 768 Object 770 job-id (integer(1:MAX)) MUST Job 771 job-state (type1 enum) MUST Job 772 job-state-reasons (1setOf type2 keyword) MUST Job 773 job-impressions-completed (integer(0:MAX)) MUST * Job 775 * The Printer MUST send the "job-impressions-completed" 776 attribute in an Event Notification only for the combinations of 777 Events and Subscribed Events shown in Table 5. 779 Table 5 - Combinations of Events and Subscribed Events for "job- 780 impressions-completed" 782 Job Event Subscribed Job Event 784 'job-progress' 'job-progress' 785 'job-completed' 'job-completed' 786 'job-completed' 'job-state-changed' 788 For Event Notification for Printer Events, the Printer includes 789 the additional attributes shown in Table 6. 791 Table 6 - Additional Attributes in Event Notification Content for 792 Printer Events 794 Source Value Sends Source 795 Object 797 printer-state (type1 enum) MUST Printer 798 printer-state-reasons (1setOf type2 keyword) MUST Printer 799 printer-is-accepting-jobs (boolean) MUST Printer 801 6 Additional Information about Subscription Template Attributes 803 The 'ippget' Delivery Method does not define any addition 804 Subscription Template attributes. The 'ippget' Delivery Method has 805 the same conformance requirements for Subscription Template 806 attributes as defined in [ipp-ntfy]. This section defines additional 807 information about Subscription Template attributes defined in [ipp- 808 ntfy]. 810 6.1 notify-pull-method (type2 keyword) 812 This Subscription Template attribute identifies the Pull Delivery 813 Method to be used for the Subscription Object (see [ipp-ntfy]). In 814 order to support the 'ippget' Pull Delivery Method defined in this 815 document, the Printer MUST support this attribute with the following 816 keyword value: 818 'ippget': indicates that the 'ippget' Pull Delivery Method is to 819 be used for this Subscription Object. 821 7 Subscription Description Attributes 823 The 'ippget' Delivery Method has the same conformance requirements 824 for Subscription Description attributes as defined in [ipp-ntfy]. 825 The 'ippget' Delivery Method does not define any addition 826 Subscription Description attributes. 828 8 Additional Printer Description Attributes 830 This section defines additional Printer Description attributes for 831 use with the 'ippget' Delivery Method. 833 8.1 ippget-event-life (integer(15:MAX)) 835 This Printer Description attribute specifies the Event Life value 836 that the Printer assigns to each Event, i.e., the number of seconds 837 after an Event occurs during which a Printer will return that Event 838 in an Event Notification in a Get-Notifications response. After the 839 Event Life expires for the Event, the Printer MAY no longer return an 840 Event Notification for that Event in a Get-Notifications response. 842 The Printer MUST support this attribute if it supports the 'ippget' 843 Delivery Method. The value MUST be 15 or more (at least 15 seconds) 844 and 60 (seconds) is the RECOMMENDED value to align with the PWG Job 845 Monitoring MIB [RFC2707] jmGeneralJobPersistence and 846 jmGeneralAttributePersistence objects. 848 For example, assume the following: 850 1. a client performs a Job Creation operation that creates a 851 Subscription Object associated with the 'ippget' Delivery 852 Method, AND 854 2. an Event associated with the new Job occurs immediately after 855 the Subscription Object is created, AND 857 3. the same client or some other client performs a Get- 858 Notifications operation such that the client is connected N 859 seconds after the Job Creation operation. 861 Then, if N is less than the value of this attribute, the client(s) 862 performing the Get-Notifications operations can expect not to miss 863 any Event-Notifications, barring some unforeseen lack of memory space 864 in the Printer. Note: The client MUST initiate the Get- 865 Notifications a time that is sufficiently less that N seconds to 866 account for network latency so that it is connected to the Printer 867 before N seconds elapses. 869 If a Printer supports the 'ippget' Delivery Method, it MUST keep 870 'completed', 'canceled', or 'aborted' Job objects in the Job 871 Retention and/or Job History phases for at least as long as this 872 attribute's value. The Printer MAY retain jobs longer that this 873 value. See [RFC2911] section 4.3.7.1 and the discussion in [ipp- 874 ntfy] 'job-completed' event) that explains that a Notification 875 Recipients can query the Job after receiving a 'job-completed' Event 876 Notification in order to find out other information about the job 877 that is 'completed', 'aborted', or 'canceled'. However, this 878 attribute has no effect on the Cancel-Subscription operation which 879 deletes the Subscription object immediately, whether or not it 880 contain the "notify-pull-method" attribute with the 'ippget' keyword 881 value. Immediately thereafter, subsequent Get-Notifications 882 Responses MUST NOT contain Event Notifications associated with the 883 canceled Subscription object. 885 9 New Values for Existing Printer Description Attributes 887 This section defines additional values for existing Printer 888 Description attributes defined in [ipp-ntfy]. 890 9.1 notify-pull-method-supported (1setOf type2 keyword) 892 The following keyword value for the "notify-pull-method-supported" 893 attribute is added in order to support the new Delivery Method 894 defined in this document: 896 'ippget' - The IPP Notification Pull Delivery Method defined in 897 this document. 899 9.2 operations-supported (1setOf type2 enum) 901 Table 7 lists the "operation-id" value defined in order to support 902 the new Get-Notifications operation defined in this document. 904 Table 7 - Operation-id assignments 906 Value Operation Name 908 0x001C Get-Notifications 910 10 New Status Codes 912 The following status code is defined as an extension for this 913 Delivery Method and is returned as the status code of the Get- 914 Notifications operation in Group 1 or Group 3 to N (see section 5.2). 916 10.1 successful-ok-events-complete (0x0007) 918 The Printer MUST return the 'successful-ok-events-complete' status 919 code to indicate when this Get-Notifications response is the last 920 response for a Subscription object, whether or not there are Event 921 Notifications being returned. This condition occurs for Event Wait 922 Mode with Notification Recipients waiting for responses when the 923 Subscription Object is: (1) canceled with a Cancel-Subscription 924 operation, (2) deleted when the Per-Printer Subscription lease time 925 expires, or (3) when the 'job-completed' event occurs for a Per-Job 926 Subscription. This condition also occurs for a Get-Notifications 927 request that a Notification Recipient makes after the job completes, 928 but before the Event Life expires. 930 11 Encoding and Transport 932 This section defines the encoding and transport considerations for 933 this Delivery Method based on [RFC2910]. 935 The encoding of a Get-Notifications Response is modeled the Get-Jobs 936 Response (see [RFC2911]). In a Get-Notifications Response, each 937 Event Notification Attributes Group MUST start with an 'event- 938 notification-attributes-tag' (see the section "Encodings of 939 Additional Attribute Tags" in [ipp-ntfy]), and end with an 'end-of- 940 attributes-tag'. In addition, for Event Wait Mode the multi- 941 part/related is used to separate each multiple response (in time) to 942 a single Get-Notifications Request. 944 The Printer returns Get-Notification Response as follows: 946 1. If the Notification Recipient client did not request Event Wait 947 Mode ("notify-wait" = 'false' or omitted), the Printer ends the 948 response with an 'end-of-attributes-tag' (see [RFC2911] Get-Jobs 949 encoding) as with any operation response. 951 2. If the Notification Recipient client requests Event Wait Mode 952 ("notify-wait" = 'true') and the Printer wishes to honor the 953 request, the Printer MUST return the response as an 954 application/ipp part inside a multi-part/related MIME media 955 type. When one or more additional Events occur, the Printer 956 returns each as an additional Event Notification Group using a 957 separate application/ipp part under the multi-part/related type. 959 3. If the client requested Event Wait Mode ("notify-wait" = 960 'true'), but the Printer does not wish to honor the request in 961 the initial response but wants the client explicitly poll for 962 Event Notifications, the Printer MUST return the "notify-get- 963 interval" operation attribute (see section 5.2.1). The Printer 964 returns the response as an application/ipp part which MAY be 965 inside an multi-part/related type. The client MUST accept this 966 response and re-issue the Get-Notifications request in the 967 future indicated by the value of the "notify-get-interval" 968 attribute value.. 970 4. If the client requested Event Wait Mode ("notify-wait" = 971 'true'), and the Printer initially honored the request, but 972 later wishes to leave Event Wait Mode, the Printer MUST return 973 the "notify-get-interval" operation attribute (see section 974 5.2.1). The Printer returns the response as an application/ipp 975 part which MUST be inside an multi-part/related type. 977 NOTE: if a Notification Recipient fails to receive a response, it can 978 ask the Printer for the same Event Notifications again. The 979 Notification Recipient will receive the same Event Notifications as 980 it should have received the first time except for those Event 981 Notifications that have expired in the meantime. 983 The Printer MAY chunk the responses, but this has no significance to 984 the IPP semantics. 986 This notification delivery method uses the IPP transport and encoding 987 [RFC2910] for the Get-Notifications operation with the following 988 extension allocated in [ipp-ntfy]: 990 Table 8 - The "event-notification-attributes-tag" value 992 Tag Value (Hex) Meaning 994 0x07 "event-notification-attributes-tag" 996 12 Conformance Requirements 998 This section lists the conformance requirements for clients and 999 Printers. 1001 12.1 Conformance for IPP Printers 1003 It is OPTIONAL for a Printer to support IPP Notifications as defined 1004 in [ipp-ntfy]. However, if a Printer supports IPP Notifications, the 1005 Printer MUST support the 'ippget' Delivery Method as defined in this 1006 document as one of its Delivery Methods. IPP Printers that conform 1007 to this specification: 1009 1. MUST meet the conformance requirements defined in [ipp-ntfy] for 1010 a Pull Delivery Method; 1012 2. MUST support the Get-Notifications operation defined in section 1013 5, including Event Wait Mode; 1015 3. MUST support the Subscription Template object attributes as 1016 defined in section 6; 1018 4. MUST support the Subscription Description object attributes as 1019 defined in section 7; 1021 5. MUST support the "ippget-event-life" Printer Description 1022 attribute defined in section 8.1, including retaining jobs in 1023 the Job Retention and/or Job History phases for at least as long 1024 as the value specified by the Printer's "ippget-event-life"; 1026 6. MUST support the additional values for IPP/1.1 Printer 1027 Description attributes defined in section 9; 1029 7. MUST support the 'successful-ok-events-complete' status code as 1030 described in section 10.1; 1032 8. MUST listen for the IPP Get-Notifications operation requests on 1033 IANA-assigned well-known port 631, unless explicitly configured 1034 by system administrators or site policies; 1036 9. SHOULD NOT listen for IPP Get-Notifications operation requests 1037 on any other port, unless explicitly configured by system 1038 administrators or site policies. 1040 10. MUST meet the security conformance requirements as stated in 1041 section 18.4. 1043 12.2 Conformance for IPP Clients 1045 It is OPTIONAL for an IPP Client to support IPP Notifications as 1046 defined in [ipp-ntfy]. However, if a client supports IPP 1047 Notifications, the client MUST support the 'ippget' Delivery Method 1048 as defined in this document as one of its Delivery Methods. IPP 1049 Clients that conform to this specification: 1051 1. MUST create Subscription Objects by sending Subscription 1052 Creation operation requests containing the "notify-pull-method" 1053 attribute (as opposed to the "notify-recipient-uri" attribute) 1054 using the 'ippget' keyword value (see sections 6.1 and 15.2); 1056 2. MUST send IPP Get-Notifications operation requests (see section 1057 5.1) via the port specified in the associated 'ipp' URL (if 1058 present) or otherwise via IANA assigned well-known port 631; 1060 3. MUST convert the associated 'ipp' URLs for use in IPP Get- 1061 Notifications operation to their corresponding 'http' URL forms 1062 for use in the HTTP layer according to the rules in section 5 1063 "IPP URL Scheme" in [RFC2910]. 1065 4. MUST meet the security conformance requirements as stated in 1066 section 18.5. 1068 13 Normative References 1070 [ipp-ntfy] 1071 Herriot, R., and T. Hastings, "Internet Printing Protocol/1.1: IPP 1072 Event Notifications and Subscriptions", , June 21, 2004. 1075 [RFC2119] 1076 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1077 Levels", RFC 2119 , March 1997 1079 [RFC2910] 1080 Herriot, R., Butler, S., Moore, P., and R. Tuner, "Internet 1081 Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 1082 2000. 1084 [RFC2911] 1085 deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, 1086 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 1087 September 2000. 1089 14 Informative References 1091 [notify-req] 1092 Hastings, T., deBry, R., and H. Lewis, "Internet Printing Protocol 1093 (IPP): Requirements for IPP Notifications", , June 21, 2004. 1096 [RFC2565] 1097 Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet 1098 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1099 1999. 1101 [RFC2566] 1102 R. deBry, T. Hastings, R. Herriot, S. Isaacson, and P. Powell, 1103 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1104 April 1999. 1106 [RFC2567] 1107 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1108 2567, April 1999. 1110 [RFC2568] 1111 Zilles, S., "Rationale for the Structure and Model and Protocol for 1112 the Internet Printing Protocol", RFC 2568, April 1999. 1114 [RFC2569] 1115 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1116 LPD and IPP Protocols", RFC 2569, April 1999. 1118 [RFC2616] 1119 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1120 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1121 RFC 2616, June 1999. 1123 [RFC2707] 1124 Bergman, R., Hastings, T., Isaacson, S., and H. Lewis, "Job 1125 Monitoring MIB - V1.0", November 1999. 1127 [RFC3196] 1128 Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, 1129 "Internet Printing Protocol/1.1: Implementer's Guide", RFC3196, 1130 November 2001. 1132 15 IANA Considerations 1134 This section contains the exact information for IANA to add to the 1135 IPP Registries according to the procedures defined in RFC 2911 1136 [RFC2911] section 6. The resulting registrations will be published 1137 in the http://www.iana.org/assignments/ipp-registrations registry. 1139 Note to RFC Editors: Replace RFC NNNN below with the RFC number 1140 for this document, so that it accurately reflects the content of 1141 the information for the IANA Registry. 1143 15.1 Attribute Registrations 1145 The following table lists the attributes defined in this document. 1146 This is to be registered according to the procedures in RFC 2911 1147 [RFC2911] section 6.2. 1149 Printer Description attributes: Reference Section 1150 ------------------------------- --------- ------- 1151 ippget-event-life (integer(15:MAX)) [RFCNNNN] 8.1 1153 15.2 Delivery Method and Additional keyword attribute value 1154 registrations for existing attributes 1156 This section lists additional keyword attribute value registrations 1157 for use with existing attributes defined in other documents. These 1158 are to be registered according to the procedures in RFC 2911 1159 [RFC2911] section 6.1. According to [ipp-ntfy] section 24.7.3, Pull 1160 Delivery Method registrations are the keyword attribute value 1161 registrations for the "notify-pull-method" and "notify-pull-method- 1162 supported" attributes. 1164 Attribute (attribute syntax) 1165 Values Reference Section 1166 ----------------------- --------- ------- 1167 notify-pull-method (type2 keyword) [ipp-ntfy] 5.3.2 1168 notify-pull-method-supported (1setOf type2 keyword) 1169 [ipp-ntfy] 5.3.2.1 1170 ippget [RFCNNNN] 9.1 1172 15.3 Additional enum attribute values 1174 The following table lists the enum attribute values defined in this 1175 document. These are to be registered according to the procedures in 1176 RFC 2911 [RFC2911] section 6.1. 1178 Attribute (attribute syntax) 1179 Value Name Reference Section 1180 ------ ----------------------------- --------- ------- 1181 operations-supported (type2 enum) [RFC2911] 4.4.15 1182 0x001C Get-Notifications [RFCNNNN] 9.2 1184 15.4 Operation Registrations 1186 The following table lists the operations defined in this document. 1187 This is to be registered according to the procedures in RFC 2911 1188 [RFC2911] section 6.4. 1190 Operations: Reference Section 1191 ----------- --------- ------- 1192 Get-Notifications [RFCNNNN] 5 1194 15.5 Status code Registrations 1196 The following table lists the status codes defined in this document. 1197 This is to be registered according to the procedures in RFC 2911 1198 [RFC2911] section 6.6. 1200 Status codes: Reference Section 1201 ------------- --------- ------- 1202 successful-ok-events-complete (0x0007) [RFCNNNN] 10.1 1204 16 Intellectual Property 1206 The IETF takes no position regarding the validity or scope of any 1207 intellectual property or other rights that might be claimed to 1208 pertain to the implementation or use of the technology described in 1209 this document or the extent to which any license under such rights 1210 might or might not be available; neither does it represent that it 1211 has made any effort to identify any such rights. Information on the 1212 IETF's procedures with respect to rights in standards-track and 1213 standards-related documentation can be found in RFC 2028. Copies of 1214 claims of rights made available for publication and any assurances of 1215 licenses to be made available, or the result of an attempt made to 1216 obtain a general license or permission for the use of such 1217 proprietary rights by implementers or users of this specification can 1218 be obtained from the IETF Secretariat. 1220 The IETF invites any interested party to bring to its attention any 1221 copyrights, patents or patent applications, or other proprietary 1222 rights which may cover technology that may be required to practice 1223 this standard. Please address the information to the IETF Executive 1224 Director. 1226 17 Internationalization Considerations 1228 The IPP Printer MUST localize the "notify-text" attribute as 1229 specified in section 14 of [ipp-ntfy]. 1231 In addition, when the client receives the Get-Notifications response, 1232 it is expected to localize the attributes that have the 'keyword' 1233 attribute syntax according to the charset and natural language 1234 requested in the Get-Notifications request. 1236 18 Security Considerations 1238 The IPP Model and Semantics document [RFC2911 section 8] discusses 1239 high-level security requirements (Client Authentication, Server 1240 Authentication and Operation Privacy). The IPP Transport and 1241 Encoding document [RFC2910 section 8] discusses the security 1242 requirements for the IPP protocol. Client Authentication is the 1243 mechanism by which the client proves its identity to the server in a 1244 secure manner. Server Authentication is the mechanism by which the 1245 server proves its identity to the client in a secure manner. 1246 Operation Privacy is defined as a mechanism for protecting operations 1247 from eavesdropping. 1249 The 'ippget' Delivery Method with its Get-Notifications operations 1250 leverages the security mechanism that are used in IPP/1.1 [RFC2910 1251 and RFC2911] without adding any additional security mechanisms in 1252 order to maintain the same security support as IPP/1.1. 1254 The access control model for the Get-Notifications operation defined 1255 in this document is the same as the access control model for the Get- 1256 Job-Attributes operation (see [RFC2911] section 3.2.6). The primary 1257 difference is that a Get-Notifications operation is directed at 1258 Subscription Objects rather than at Job objects, and a returned 1259 attribute group contains Event Notification attributes rather than 1260 Job object attributes. 1262 18.1 Notification Recipient client access rights 1264 The Notification Recipient client MUST have the following access 1265 rights to the Subscription object(s) targeted by the Get- 1266 Notifications operation request: 1268 The authenticated user (see [RFC2911] section 8.3) performing this 1269 operation MUST be (1) the owner of each Subscription Object 1270 identified by the "notify-subscription-ids" operation attribute 1271 (see section 5.1.1), (2) an operator or administrator of the 1272 Printer (see [RFC2911] Sections 1 and 8.5), or (3) be otherwise 1273 authorized by the Printer's administrator-configured security 1274 policy to request Event Notifications from the target Subscription 1275 Object(s). Furthermore, the Printer's security policy MAY limit 1276 the attributes returned by the Get-Notifications operation, in a 1277 manner similar to the Get-Job-Attributes operation (see [RFC2911] 1278 end of section 3.3.4.2). 1280 18.2 Printer security threats 1282 Because the Get-Notifications operation is sent in the same direction 1283 as Job Creation operations, usually by the same client, this Event 1284 Notification Delivery Method poses no additional authentication, 1285 authorization, privacy, firewall, or port assignment issues above 1286 those for the IPP Get-Job-Attributes and Get-Printer-Attributes 1287 operations (see [RFC2911] sections 3.2.6 and 3.2.5). 1289 18.3 Notification Recipient security threats 1291 Unwanted Events Notifications (spam): Unlike Push Event Notification 1292 Delivery Methods in which the IPP Printer initiates the Event 1293 Notification, with the Pull Delivery Method defined in this document, 1294 the Notification Recipient is the client who initiates the Get- 1295 Notifications operation (see section 5). Therefore, there is no 1296 chance of "spam" notifications with this method. 1298 Note: when a client stays connected to a Printer using the Event 1299 Wait Mode (see section 5.1.3) in order to receive Event Notifications 1300 as they occur, such a client can close down the IPP connection at any 1301 time, and so can avoid future unwanted Event Notifications at any 1302 time. 1304 It is true that client has control about whether to ask for Event 1305 Notifications. However, if the client subscribes to an event, and 1306 does a Get-Notifications request, the client gets all events for the 1307 Subscription Object in the sequence number range (see section 5.1.2), 1308 not just the ones the client wants. If a client subscribes to a Per- 1309 Printer Subscription job event, such as 'job-completed', and someone 1310 then starts and cancels thousands of jobs, the client would have to 1311 receive these events in addition to the ones the client is interested 1312 in. A client can protect itself better by subscribing to his own 1313 jobs using a Per-Job Subscription, rather than creating a Per-Printer 1314 subscription whose Job events apply to all jobs. 1316 18.4 Security requirements for Printers 1318 For the Get-Notifications operation defined in this document, the 1319 same Printer conformance requirements apply for supporting and using 1320 Client Authentication, Server Authentication and Operation Privacy as 1321 stated in [RFC2910] section 8 for all IPP operations. 1323 18.5 Security requirements for clients 1325 For the Get-Notifications operation defined in this document, the 1326 same client conformance requirements apply for supporting and using 1327 Client Authentication, Server Authentication and Operation Privacy as 1328 stated in [RFC2910] section 8 for all IPP operations. 1330 19 Contributors 1332 Carl Kugler and Harry Lewis contributed the basic idea of in-band 1333 "smart polling" coupled with multiple responses for a single 1334 operation on the same connection, one response for each event as it 1335 occurs. Without their continual persuasion, we would not have 1336 arrived at this Delivery Method specification and would not have been 1337 able to agree on a single REQUIRED Delivery Method for IPP. 1339 Carl Kugler 1340 IBM 1341 P.O. Box 1900 1342 Boulder, CO 80301-9191 1343 Phone: 1344 Fax: 1345 e-mail: kugler@us.ibm.com 1347 20 Authors' Addresses 1349 Robert Herriot 1350 Global Workflow Solutions 1351 706 Colorado Ave. 1352 Palo Alto, CA 94303 1354 Phone: 650-324-4000 1355 email: bob@herriot.com 1357 Thomas N. Hastings 1358 Xerox Corporation 1359 737 Hawaii St. ESAE 231 1360 El Segundo CA 90245 1362 Phone: 310-333-6413 1363 Fax: 310-333-5514 1364 email: hastings@cp10.es.xerox.com 1366 Harry Lewis 1367 IBM 1368 P.O. Box 1900 1369 Boulder, CO 80301-9191 1371 Phone: 303-924-5337 1372 FAX: 1373 e-mail: harryl@us.ibm.com 1375 21 Description of Base IPP documents (Informative) 1377 The base set of IPP documents includes: 1379 Design Goals for an Internet Printing Protocol [RFC2567] 1380 Rationale for the Structure and Model and Protocol for the Internet 1381 Printing Protocol [RFC2568] 1382 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 1383 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 1384 Internet Printing Protocol/1.1: Implementer's Guide [RFC3196] 1385 Mapping between LPD and IPP Protocols [RFC2569] 1387 The "Design Goals for an Internet Printing Protocol" document takes a 1388 broad look at distributed printing functionality, and it enumerates 1389 real-life scenarios that help to clarify the features that need to be 1390 included in a printing protocol for the Internet. It identifies 1391 requirements for three types of users: end users, operators, and 1392 administrators. It calls out a subset of end user requirements that 1393 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 1394 been added to IPP/1.1. 1395 The "Rationale for the Structure and Model and Protocol for the 1396 Internet Printing Protocol" document describes IPP from a high level 1397 view, defines a roadmap for the various documents that form the suite 1398 of IPP specification documents, and gives background and rationale 1399 for the IETF working group's major decisions. 1400 The "Internet Printing Protocol/1.1: Model and Semantics" document 1401 describes a simplified model with abstract objects, their attributes, 1402 and their operations that are independent of encoding and transport. 1403 It introduces a Printer and a Job object. The Job object optionally 1404 supports multiple documents per Job. It also addresses security, 1405 internationalization, and directory issues. 1406 The "Internet Printing Protocol/1.1: Encoding and Transport" document 1407 is a formal mapping of the abstract operations and attributes defined 1408 in the model document onto HTTP/1.1 [RFC2616]. It defines the 1409 encoding rules for a new Internet MIME media type called 1410 "application/ipp". This document also defines the rules for 1411 transporting over HTTP a message body whose Content-Type is 1412 "application/ipp". This document defines the 'ipp' scheme for 1413 identifying IPP printers and jobs. 1414 The "Internet Printing Protocol/1.1: Implementer's Guide" document 1415 gives insight and advice to implementers of IPP clients and IPP 1416 objects. It is intended to help them understand IPP/1.1 and some of 1417 the considerations that may assist them in the design of their client 1418 and/or IPP object implementations. For example, a typical order of 1419 processing requests is given, including error checking. Motivation 1420 for some of the specification decisions is also included. 1421 The "Mapping between LPD and IPP Protocols" document gives some 1422 advice to implementers of gateways between IPP and LPD (Line Printer 1423 Daemon) implementations. 1425 22 Full Copyright Statement 1427 Copyright (C) The Internet Society (2003). All Rights Reserved. 1428 This document and translations of it may be copied and furnished to 1429 others, and derivative works that comment on or otherwise explain it 1430 or assist in its implementation may be prepared, copied, published 1431 and distributed, in whole or in part, without restriction of any 1432 kind, provided that the above copyright notice and this paragraph are 1433 included on all such copies and derivative works. However, this 1434 document itself may not be modified in any way, such as by removing 1435 the copyright notice or references to the Internet Society or other 1436 Internet organizations, except as needed for the purpose of 1437 developing Internet standards in which case the procedures for 1438 copyrights defined in the Internet Standards process must be 1439 followed, or as required to translate it into languages other than 1440 English. 1441 The limited permissions granted above are perpetual and will not be 1442 revoked by the Internet Society or its successors or assigns. 1443 This document and the information contained herein is provided on an 1444 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1445 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1446 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1447 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1448 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1449 Acknowledgement 1451 Funding for the RFC Editor function is currently provided by the 1452 Internet Society.