idnits 2.17.1 draft-ietf-ipp-indp-method-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 11) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 80: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 239: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 240: '... NOT, MAY, NEED NOT, and OPTIONAL,...' RFC 2119 keyword, line 300: '...the Delivery Method is RECOMMENDED...' RFC 2119 keyword, line 301: '...REQUIRED, RECOMMENDED, or...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 221 has weird spacing: '...ions to the N...' == Line 297 has weird spacing: '...me name indp...' == Line 306 has weird spacing: '...ter use comp...' == Line 318 has weird spacing: '...ed into combi...' == Line 335 has weird spacing: '...llowing is th...' == (2 more instances...) -- 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 (July 14, 2000) is 8685 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2567' on line 64 looks like a reference -- Missing reference section? 'RFC2568' on line 66 looks like a reference -- Missing reference section? 'RFC2569' on line 70 looks like a reference -- Missing reference section? 'RFC2616' on line 98 looks like a reference -- Missing reference section? 'RFC2119' on line 241 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 4 Hugo Parra 5 Novell, Inc. 6 Tom Hastings 7 Xerox Corp. 8 July 14, 2000 10 Internet Printing Protocol (IPP): 12 The 'indp' Notification Delivery Method and Protocol/1.0 14 Copyright (C) The Internet Society (2000). All Rights Reserved. 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of [rfc2026]. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed as 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The IPP notification extension document [ipp-ntfy] defines operations 38 that a client can perform in order to create Subscription Objects in a 39 Printer and carry out other operations on them. The Subscription Object 40 specifies that when one of the specified Events occurs, the Printer 41 sends an asynchronous Event Notification to the specified Notification 42 Recipient via the specified Delivery Method (i.e., protocol). 44 The notification extension document [ipp-ntfy] specifies that each 45 Delivery Method is defined in another document. This document is one 46 such document, and it specifies the 'indp' Delivery Method and Protocol. 47 This Delivery Method is a simple protocol consisting of a single 48 operation: the Send-Notifications operation which uses the same encoding 49 and transport as IPP. This document defines version '1.0' of the 50 protocol. 52 For this Delivery Method, when an Event occurs, the Printer immediately 53 sends (pushes) an Event Notification via the Send-Notifications 54 operation to the Notification Recipient specified in the Subscription 56 Expires: January 14, 2001 57 Object. The Event Notification content consists of Machine Consumable 58 attributes and a Human Consumable "notify-text" attribute. The 59 Notification Recipient returns a response to the Printer. 61 Expires: January 14, 2001 62 The full set of IPP documents includes: 64 Design Goals for an Internet Printing Protocol [RFC2567] 65 Rationale for the Structure and Model and Protocol for the Internet 66 Printing Protocol [RFC2568] 67 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 68 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 69 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 70 Mapping between LPD and IPP Protocols [RFC2569] 71 Internet Printing Protocol (IPP): IPP Event Notification 72 Specification [ipp-ntfy] 74 The "Design Goals for an Internet Printing Protocol" document takes a 75 broad look at distributed printing functionality, and it enumerates 76 real-life scenarios that help to clarify the features that need to be 77 included in a printing protocol for the Internet. It identifies 78 requirements for three types of users: end users, operators, and 79 administrators. It calls out a subset of end user requirements that are 80 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 81 added to IPP/1.1. 83 The "Rationale for the Structure and Model and Protocol for the Internet 84 Printing Protocol" document describes IPP from a high level view, 85 defines a roadmap for the various documents that form the suite of IPP 86 specification documents, and gives background and rationale for the IETF 87 working group's major decisions. 89 The "Internet Printing Protocol/1.1: Model and Semantics" document 90 describes a simplified model with abstract objects, their attributes, 91 and their operations that are independent of encoding and transport. It 92 introduces a Printer and a Job object. The Job object optionally 93 supports multiple documents per Job. It also addresses security, 94 internationalization, and directory issues. 96 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 97 a formal mapping of the abstract operations and attributes defined in 98 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 99 rules for a new Internet MIME media type called "application/ipp". This 100 document also defines the rules for transporting a message body over 101 HTTP whose Content-Type is "application/ipp". This document defines a 102 new scheme named 'ipp' for identifying IPP printers and jobs. 104 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 105 insight and advice to implementers of IPP clients and IPP objects. It 106 is intended to help them understand IPP/1.1 and some of the 107 considerations that may assist them in the design of their client and/or 108 IPP object implementations. For example, a typical order of processing 109 requests is given, including error checking. Motivation for some of the 110 specification decisions is also included. 112 The "Mapping between LPD and IPP Protocols" document gives some advice 113 to implementers of gateways between IPP and LPD (Line Printer Daemon) 114 implementations. 116 Expires: January 14, 2001 117 The "Internet Printing Protocol (IPP): IPP Event Notification 118 Specification" document defines the semantics for Subscription Creation 119 Operations and the requirements for other Delivery Method documents to 120 define a Delivery Method to carry an Event Notifications to a 121 Notification Recipient. 123 Expires: January 14, 2001 124 Table of Contents 126 1 Introduction......................................................7 128 2 Terminology.......................................................7 130 3 Model and Operation...............................................8 132 4 General Information...............................................8 134 5 Subscription object attributes...................................10 135 5.1Subscription Template Attribute Conformance.....................10 136 5.2Additional Information about Subscription Template Attributes...10 137 5.2.1 notify-recipient-uri (uri)................................10 138 5.3Subscription Description Attribute Conformance..................11 140 6 Printer Description Attributes...................................11 141 6.1Printer Description Attribute Conformance.......................11 142 6.2New Values for Existing Printer Description Attributes..........11 143 6.2.1 notify-schemes-supported (1setOf uriScheme)...............11 144 6.2.2 operations-supported (1setOf type2 enum)..................11 146 7 Attributes Only in Event Notifications...........................12 148 8 Operations for Notification......................................12 149 8.1Send-Notifications operation....................................12 150 8.1.1 Send-Notifications Request................................13 151 8.1.2 Send-Notifications Response...............................15 153 9 Status Codes.....................................................17 154 9.1Additional Status Codes.........................................17 155 9.1.1 successful-ok-ignored-notifications (0x0004)..............17 156 9.2Status Codes returned in Event Notification Attributes Groups...17 157 9.2.1 client-error-not-found (0x0406)...........................18 158 9.2.2 successful-ok-but-cancel-subscription (0x0006)............18 160 10 Encoding and Transport...........................................18 161 10.1 Encoding of the Operation Layer...............................18 162 10.2 Encoding of Transport Layer...................................18 164 11 Conformance Requirements.........................................18 165 11.1 Printer Conformance Requirements..............................19 166 11.2 Notification Recipient Requirements...........................19 168 12 IANA Considerations..............................................19 170 13 Internationalization Considerations..............................19 172 14 Security Considerations..........................................19 174 Expires: January 14, 2001 175 14.1 Security Conformance..........................................20 177 15 References.......................................................20 179 16 Author's Addresses...............................................21 181 17 Full Copyright Statement.........................................21 183 Tables 185 Table 1 - Information about the Delivery Method.......................8 187 Table 2 . Operation-id assignments...................................12 189 Table 3 . Attributes in Event Notification Content...................13 191 Table 4 . Additional Attributes in Event Notification Content for Job 192 Events...........................................................14 194 Table 5 . Combinations of Events and Subscribed Events for "job- 195 impressions-completed"...........................................15 197 Table 6 . Additional Attributes in Event Notification Content for 198 Printer Events...................................................15 200 Expires: January 14, 2001 202 1 Introduction 204 The notification extension document [ipp-ntfy] defines operations that a 205 client can perform in order to create Subscription Objects in a Printer 206 and carry out other operations on them. A Subscription Object represents 207 a Subscription abstraction. The Subscription Object specifies that when 208 one of the specified Events occurs, the Printer sends an asynchronous 209 Event Notification to the specified Notification Recipient via the 210 specified Delivery Method (i.e., protocol). 212 The notification extension document [ipp-ntfy] specifies that each 213 Delivery Method is defined in another document. This document is one 214 such document, and it specifies the 'indp' Delivery Method. This 215 Delivery Method is a simple protocol consisting of a single operation: 216 the Send-Notifications operation which uses the same encoding and 217 transport as IPP. This document defines version '1.0' of the protocol. 219 For the 'indp' Delivery Method, an IPP Printer sends (pushes) a Send- 220 Notifications operation request containing one or more Event 221 Notifications to the Notification Recipient specified in the 222 Subscription Object. The Event Notification content consists of Machine 223 Consumable attributes and a Human Consumable "notify-text" attribute. 225 The Notification Recipient receives the Event Notification as a Send- 226 Notifications operation, in the same way as an IPP Printer receives IPP 227 operations. The Notification Recipient returns a response to the 228 Printer. 230 2 Terminology 232 This section defines the following terms that are used throughout this 233 document: 235 Terms such as attributes, keywords, and support. These terms have 236 special meaning and are defined in the model terminology [ipp-mod] 237 section 12.2. 239 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 240 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 241 conformance as specified in RFC 2119 [RFC2119] and [ipp-mod] 242 section 12.1. These terms refer to conformance to this document, 243 if this document is implemented. 245 Capitalized terms, such as Notification Recipient, Event 246 Notification, Printer, etc., that are defined in [ipp-ntfy] with 247 the same meanings and are not reproduced here. 249 Event Notification Attributes Group . The attributes group in a 250 request that contains Event Notification Attributes in a request or 251 response. 253 Expires: January 14, 2001 255 3 Model and Operation 257 See [ipp-ntfy] for the description of the Event Notification Model and 258 Operation. This Delivery Method takes advantage of combining several 259 Event Notifications into a single Compound Event Notification that is 260 delivery by a single Send-Notification operation to a single 261 Notification Recipient. 263 When creating each Subscription object, the client supplies the "notify- 264 recipient" (uri) Subscription Template attribute. The "notify- 265 recipient" attribute specifies both a single Notification Recipient that 266 is to receive the Notifications when subsequent events occur and the 267 method for notification delivery that the IPP Printer is to use. For 268 the Notification Delivery Method defined in this document, the 269 notification method is 'indp' and the rest of the URI is the address of 270 the Notification Recipient to which the IPP Printer will send the Send- 271 Notifications operation. 273 The 'indp' Notification Delivery Method defined in this document uses a 274 client/server protocol paradigm. The "client" in this relationship is 275 the Printer described in [ipp-ntfy] while the "server" is the 276 Notification Recipient. The Printer invokes the Send-Notifications 277 operation to communicate IPP Event Notification contents to the 278 Notification Recipient. The Notification Recipient only conveys 279 information to the Printer in the form of responses to the operations 280 initiated by the Printer. 282 Printers that implement the 'indp' Notification Delivery Method will 283 need to include an HTTP client stack while Notification Recipients that 284 implement this Delivery Method will need to support an HTTP server 285 stack. See section 10.2 for more details. 287 4 General Information 289 If a Printer supports this Delivery Method, Table 1 lists its 290 characteristics. 292 Table 1 - Information about the Delivery Method 294 Document Method conformance 'indp' realization 295 requirement 297 1.What is the URL scheme name indp 298 for the Delivery Method? 300 2.Is the Delivery Method is RECOMMENDED 301 REQUIRED, RECOMMENDED, or 302 OPTIONAL for an IPP Printer to 303 support? 305 3.What transport and delivery A Printer MUST support a 306 protocol does the Printer use complete HTTP/1.1 stack 307 to deliver the Event 309 Expires: January 14, 2001 310 Document Method conformance 'indp' realization 311 requirement 313 Notification content, i.e., [rfc2616] 314 what is the entire network 315 stack? 317 4.Can several Event A Printer implementation MAY 318 Notifications be combined into combine several Event 319 a Compound Event Notification? Notifications into a single 320 Event Notifications request as 321 separate Event Notification 322 Attributes Groups, see section 323 8.1.1 325 5.Is the Delivery Method This Delivery Method is a push. 326 initiated by the Notification 327 Recipient (pull), or by the 328 Printer (push)? 330 6.Is the Event Notification Machine Consumable with the 331 content Machine Consumable or "notify-text" attribute being 332 Human Consumable? Human Consumable 334 7.What section in this The representation and encoding 335 document answers the following is the same as IPP. See 336 question? For a Machine section 8.1.1 337 Consumable Event Notification, 338 what is the representation and 339 encoding of values defined in 340 section 9.1 of [ipp-ntfy] and 341 the conformance requirements 342 thereof? For a Human Consumable 343 Event Notification, what is the 344 representation and encoding of 345 pieces of information defined 346 in section 9.2 of [ipp-ntfy] 347 and the conformance 348 requirements thereof? 350 8.What are the latency and Same as for IPP/1.0 or IPP/1.1 351 reliability of the transport itself (see [ipp-mod]). 352 and delivery protocol? 354 9.What are the security See section 14 355 aspects of the transport and 356 delivery protocol, e.g., how it 357 is handled in firewalls? 359 10. What are the content They are the same as for 360 length restrictions? IPP/1.0 and IPP/1.1 itself (see 361 [ipp-mod]). 363 Expires: January 14, 2001 365 Document Method conformance 'indp' realization 366 requirement 368 11. What are the additional A new Event Notifications 369 values or pieces of information attribute group (see section 370 that a Printer sends in an 10.1) and additional status 371 Event Notification and the codes for use in the response 372 conformance requirements (see section 9) 373 thereof? 375 12. What are the additional None 376 Subscription Template and/or 377 Subscription Description 378 attributes and the conformance 379 requirements thereof? 381 13. What are the additional None 382 Printer Description attributes 383 and the conformance 384 requirements thereof? 386 The remaining sections of this document parallel the sections of [ipp- 387 ntfy]. 389 5 Subscription object attributes 391 This section defines the Subscription object conformance requirements 392 for Printers. 394 5.1 Subscription Template Attribute Conformance 396 The 'indp' Delivery Method has the same conformance requirements for 397 Subscription Template attributes as defined in [ipp-ntfy]. The 'indp' 398 Delivery Method does not define any addition Subscription Template 399 attributes. 401 5.2 Additional Information about Subscription Template Attributes 403 This section defines additional information about Subscription Template 404 attributes defined in [ipp-ntfy]. 406 5.2.1 notify-recipient-uri (uri) 408 This section describes the syntax of the value of this attribute for the 409 'indp' Delivery Method. The syntax for values of this attribute for 410 other Delivery Method is defined in other Delivery Method Documents. 412 In order to support the 'indp' Delivery Method and Protocol, the Printer 413 MUST support the following syntax: 415 Expires: January 14, 2001 416 The 'indp://' URI scheme. The remainder of the URI indicates the 417 host and address of the Notification Recipient that is to receive 418 the Send-Notification operation. 420 5.3 Subscription Description Attribute Conformance 422 The 'indp' Delivery Method has the same conformance requirements for 423 Subscription Description attributes as defined in [ipp-ntfy]. The 424 'indp' Delivery Method does not define any addition Subscription 425 Description attributes. 427 6 Printer Description Attributes 429 This section defines the Printer Description Attributes conformance 430 requirements for Printers. 432 6.1 Printer Description Attribute Conformance 434 The 'indp' Delivery Method has the same conformance requirements for 435 Printer Description attributes as defined in [ipp-ntfy]. The 'indp' 436 Delivery Method does not define any addition Printer Description 437 attributes. 439 6.2 New Values for Existing Printer Description Attributes 441 This section defines additional values for existing Printer Description 442 attributes. 444 6.2.1 notify-schemes-supported (1setOf uriScheme) 446 The following "notify-schemes-supported" value is added in order to 447 support the new Delivery Method defined in this document: 449 'indp': - The IPP Notification Delivery Method defined in this 450 document. 452 6.2.2 operations-supported (1setOf type2 enum) 454 Table 2 lists the "operation-id" value added in order to support the new 455 operation defined in this document. The operation-id is assigned in the 456 same name space as other operations that a Printer supports. However, a 457 Printer MUST NOT include this value in its "operations-supported" 458 attribute unless it can accept the Send-Notifications request. 460 Expires: January 14, 2001 461 Table 2 . Operation-id assignments 463 Value Operation Name 465 0x001D Send-Notifications 467 7 Attributes Only in Event Notifications 469 No additional attributes are defined only for use in Event Notifications 470 besides those defined in [ipp-ntfy]. 472 8 Operations for Notification 474 This section defines the operation for Event Notification using the 475 'indp' Delivery Method. 477 There is only one operation defined: Send-Notifications. Section 6.2.2 478 assigns of the "operation-id" for the Send-Notifications operation and 479 the following section defined the operation. 481 8.1 Send-Notifications operation 483 This REQUIRED operation allows a Printer to send one or more Event 484 Notifications to a Notification Recipient using HTTP. 486 The Printer composes the information defined for an IPP Notification 487 [ipp-ntfy] and sends it using the Sent-Notifications operation to the 488 Notification Recipient supplied in the Subscription object. 490 The Send-Notifications operations uses the operations model defined by 491 IPP [rfc2566]. This includes, the use of a URI as the identifier for 492 the target of each operation, the inclusion of a version number, 493 operation-id, and request-id in each request, and the definition of 494 attribute groups. The Send-Notifications operation uses the Operation 495 Attributes group, but currently has no need for the Unsupported 496 Attributes, Printer Object Attributes, and Job-Object Attributes groups. 497 However, it uses a new attribute group, the Event Notification 498 Attributes group. 500 The Notification Recipient MUST accept the request in any state. There 501 is no state defined for the Notification Recipient for this Delivery 502 Method. 504 Access Rights: Notification Recipient MAY enforce access rights. If 505 the Printer receives a rejection with these status codes: 'client-error- 506 forbidden', 'client-error-not-authenticated', or 'client-error-not- 507 authorized' status code , the Printer SHOULD cancel the subscription. 509 Expires: January 14, 2001 510 8.1.1 Send-Notifications Request 512 Every operation request MUST contains the following parameters (see 513 [ipp-mod] section 3.1.1): 515 - a "version-number" '1.0' . the version of the 'indp' 516 protocol is '1.0'. 517 - an "operation-id" - the value defined in Table 2 518 - a "request-id" - the contents of the Subscription object's 519 "notify-sequence-number" after incrementing for the first try 520 (see [ipp-ntfy]). 522 The following groups of attributes MUST be part of the Send- 523 Notifications Request: 525 Group 1: Operation Attributes 526 Natural Language and Character Set: 527 The "attributes-charset" and "attributes-natural-language" 528 attributes as defined in [ipp-mod] section 3.1.4.1. 530 Target: 531 A copy of the Subscription object's "notification-recipient- 532 uri" (uri) attribute which is the target of this operation as 533 described in [ipp-mod] section 3.1.5, i.e., the URI of the 534 'indp' Notification Recipient (see section 5.2.1). 536 Group 2 to N: Event Notification Attributes 538 In each group 2 to N, each attribute is encoded using the IPP rules 539 for encoding attributes [ipp-pro] and may be encoded in any order. 540 Note: the Get-Jobs response in [ipp-mod] acts as a model for 541 encoding multiple groups of attributes. 543 Each Event Notification Group MUST contain all of attributes 544 specified in [ipp-ntfy] section 9.1 ("Content of Machine Consumable 545 Event Notifications") with exceptions denoted by asterisks in the 546 tables below. 548 The tables below are copies of the tables in [ipp-ntfy] section 9.1 549 ("Content of Machine Consumable Event Notifications") except that 550 each cell in the "Sends" column is a "MUST". 552 For an Event Notification for all Events, the Printer sends the 553 following attributes. 555 Table 3 . Attributes in Event Notification Content 557 Source Value Sends Source Object 559 notify-subscription-id (integer(1:MAX)) MUST Subscription 561 notify-printer-uri (uri) MUST Subscription 563 notify-subscribed-event (type2 keyword) MUST Event 565 Expires: January 14, 2001 566 Source Value Sends Source Object 568 Notification 570 printer-up-time (integer(MIN:MAX)) MUST Printer 572 printer-current-time (dateTime) * MUST Printer 574 notify-sequence-number (integer (0:MAX)) MUST Subscription 576 notify-charset (charset) MUST Subscription 578 notify-natural-language (naturalLanguage) MUST Subscription 580 notify-user-data (octetString(63)) ** MUST Subscription 582 notify-text (text (MAX)) MUST Event 583 Notification 585 attributes from the "notify-attributes" MUST Printer 586 attribute *** 588 attributes from the "notify-attributes" MUST Job 589 attribute *** 591 attributes from the "notify-attributes" MUST Subscription 592 attribute *** 594 * The Printer MUST send "printer-current-time" if and only if it 595 supports the "printer-current-time" attribute on the Printer 596 object. 598 ** If the associated Subscription Object does not contain a 599 "notify-user-data" attribute, the Printer MUST send an octet-string 600 of length 0. 602 *** If the "notify-attributes" attribute is present on the 603 Subscription Object, the Printer MUST send all attributes specified 604 by the "notify-attributes" attribute. Note: if the Printer doesn't 605 support the "notify-attributes" attribute, it is not present on the 606 associated Subscription Object. 608 For Event Notifications for Job Events, the Printer sends the 609 following additional attributes shown in Table 4. 611 Table 4 . Additional Attributes in Event Notification Content for 612 Job Events 614 Source Value Sends Source Object 616 job-id (integer(1:MAX)) MUST Job 618 Expires: January 14, 2001 619 Source Value Sends Source Object 621 job-state (type1 enum) MUST Job 623 job-state-reasons (1setOf type2 keyword) MUST Job 625 job-impressions-completed MUST Job 626 (integer(0:MAX)) * 628 * The Printer MUST send the "job-impressions-completed" attribute 629 in an Event Notification only for the combinations of Events and 630 Subscribed Events shown in Table 5. 632 Table 5 . Combinations of Events and Subscribed Events for "job- 633 impressions-completed" 635 Job Event Subscribed Job Event 637 'job-progress' 'job-progress' 639 'job-completed' 'job-completed' 641 'job-completed' 'job-state-changed' 643 For Event Notification for Printer Events, the Printer sends the 644 following additional attributes shown in Table 6. 646 Table 6 . Additional Attributes in Event Notification Content for 647 Printer Events 649 Source Value Sends Source Object 651 printer-state (type1 enum) MUST Printer 653 printer-state-reasons (1setOf type2 MUST Printer 654 keyword) 656 printer-is-accepting-jobs (boolean) MUST Printer 658 8.1.2 Send-Notifications Response 660 The Notification Recipient MUST return (to the client which is the 661 Printer) the following sets of attributes as part of a Send- 662 Notifications response: 664 Every operation response contains the following REQUIRED parameters (see 665 [ipp-mod] section 3.1.1}: 667 Expires: January 14, 2001 668 - a "version-number" 669 - a "status-code" 670 - the "request-id" that was supplied in the corresponding request 672 Group 1: Operation Attributes 674 Status Message: 675 As defined in [ipp-mod]. 677 The Notification Recipient can return any status codes defined in 678 [ipp-mod] and section 9.1 that applies to all of the Event 679 Notification Attribute groups. The following is a description of 680 the important status codes: 682 'successful-ok': the Notification Recipient received all of the 683 Event Notification Attribute Groups and was expecting each of 684 them. 685 'successful-ok-ignored-notifications': the Notification 686 Recipient was able to consume some, but not all of the Event 687 Notification Attributes Groups sent. The Event Notification 688 Attributes Groups with a "notify-status-code" attribute are 689 the ones that were ignored or are to be canceled. 690 'client-error-ignored-all-notifications': the Notification 691 Recipient was unable to consume any of the Event Notification 692 Attributes Groups sent. The Event Notification Attributes 693 Groups with a "notify-status-code" attribute are the ones that 694 were ignored or are to be canceled. 696 Natural Language and Character Set: 697 The "attributes-charset" and "attributes-natural-language" 698 attributes as defined in [ipp-mod] section 3.1.4.1. 700 Group 2 to N: Notification Attributes 702 These groups MUST be returned if and only if the "status-code" 703 parameter returned in Group 1 is anything but the 'successful-ok' 704 status code. 706 "notification-status-code" (type2 enum) 707 Indicates whether the Notification Recipient was able to consume 708 the n-th Notification Report as follows: 710 Expires: January 14, 2001 711 'successful-ok' - this Event Notification Attribute Group was 712 consumed 713 'client-error-not-found' - this Event Notification Attribute Group 714 was not able to be consumed. The Printer MUST cancel the 715 Subscription and MUST NOT attempt to send any further Event 716 Notifications from the associated Subscription object. 717 'successful-ok-but-cancel-subscription' - the Event Notification 718 Attribute Group was consumed, but the Notification Recipient 719 wishes to cancel the Subscription object. The Printer MUST 720 cancel the Subscription and MUST NOT attempt to send any further 721 Event Notifications from the associated Subscription object. 723 9 Status Codes 725 This section lists status codes whose meaning have been extended and/or 726 defined for returning in Event Notification Attribute Groups as the 727 value of the "notification-status-code" operation attribute. The code 728 values are allocated in the same space as the status codes in [ipp-mod]. 730 9.1 Additional Status Codes 732 The following status codes are defined as extensions for Notification 733 and are returned as the value of the "status-code" parameter in the 734 Operation Attributes Group of a response (see [ipp-mod] section 735 3.1.6.1). Operations in this document can also return the status codes 736 defined in section 13 of [ipp-mod]. The 'successful-ok' status code is 737 an example of such a status code. 739 9.1.1 successful-ok-ignored-notifications (0x0004) 741 The Notification Recipient was able to consume some, but not all, of the 742 Event Notifications Attributes Groups sent by the Printer in the Send- 743 Notifications request. See section 8.1.2 for further details. 745 9.2 Status Codes returned in Event Notification Attributes Groups 747 This section contains values of the "notify-status-code" attribute that 748 the Notification Recipient returns in a Event Notification Attributes 749 Group in a response when the corresponding Event Notification Attributes 750 Group in the request: 752 1. was not consumed OR 754 2. was consumed, but the Notification Recipient wants to cancel the 755 corresponding Subscription object 757 The following sections are ordered in decreasing order of importance of 758 the status-codes. 760 Expires: January 14, 2001 761 9.2.1 client-error-not-found (0x0406) 763 This status code is defined in [ipp-mod]. This document extends its 764 meaning and allows it to be returned in an Event Notification Attributes 765 Group of a response. 767 The Notification Recipient was unable to consume this Event Notification 768 Attributes Group because it was not expected. See section 8.1.2 for 769 further details. 771 9.2.2 successful-ok-but-cancel-subscription (0x0006) 773 The Notification Recipient was able to consume this Event Notification 774 Attributes Group that the Printer sent, but wants the corresponding 775 Subscription object to be canceled none-the-less. See section 8.1.2 for 776 further details. 778 10 Encoding and Transport 780 This section defines the encoding and transport used by the 'indp' 781 Delivery Method. 783 10.1 Encoding of the Operation Layer 785 The 'indp' Delivery Method uses the IPP operation layer encoding 786 described in [ipp-pro] and the following Event Notification Attributes 787 Group tag allocated by [ipp-ntfy]: 789 Tag Value (Hex) Meaning 791 0x07 "event-notification-attributes-tag" 793 10.2 Encoding of Transport Layer 795 The 'indp' Notification Delivery Method uses the IPP transport layer 796 encoding described in [ipp-pro]. 798 It is REQUIRED that an 'indp' Notification Recipient implementation 799 support HTTP over the IANA assigned Well Known Port assigned to the 800 'indp' Delivery Method as its default port by IANA (see section 12), 801 though a Notification Recipient implementation MAY support HTTP over 802 some other port as well. 804 11 Conformance Requirements 806 This section defines conformance requirements for Printers and 807 Notification Recipients. 809 Expires: January 14, 2001 810 11.1 Printer Conformance Requirements 812 The 'indp' Delivery Method is RECOMMENDED for a Printer to support. 814 If the Printer supports the 'indp' Delivery Method, the Printer MUST: 816 1.meet the conformance requirements defined in [ipp-ntfy]. 818 2.support the conformance requirements for Subscription object 819 attributes defined in section 5, including the syntax for the 820 "notify-recipient-uri" Subscription Object attribute defined in 821 section 5.2.1. 823 3.support the conformance requirements for Printer Description object 824 attributes defined in section 6. 826 4.support the 'indp' protocol by sending Event Notifications using the 827 Send-Notifications operation defined in section 8.1. 829 5.support sending Event Notification via email with the content 830 specified in section 8.1.1. 832 11.2 Notification Recipient Requirements 834 A Notification Recipient MUST accept Send-Notifications requests and 835 return Send-Notifications responses as defined in sections 8 and 9. 837 12 IANA Considerations 839 The 'indp' URL scheme for the 'indp' Delivery Method and Protocol will 840 be registered with IANA. IANA will assign a default port to use with 841 the 'indp' Delivery Method and Protocol. 843 13 Internationalization Considerations 845 When the client requests Human Consumable form by supplying the "notify- 846 text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or 847 any Notification Service that the IPP Printer might be configured to 848 use) supplies and localizes the text value of the "human-readable- 849 report" attribute in the Notification according to the charset and 850 natural language requested in the notification subscription. 852 14 Security Considerations 854 The IPP Model and Semantics document [ipp-mod] discusses high level 855 security requirements (Client Authentication, Server Authentication and 856 Operation Privacy). Client Authentication is the mechanism by which the 857 client proves its identity to the server in a secure manner. Server 858 Authentication is the mechanism by which the server proves its identity 860 Expires: January 14, 2001 861 to the client in a secure manner. Operation Privacy is defined as a 862 mechanism for protecting operations from eavesdropping. 864 The Notification Recipient can cancel unwanted Subscriptions created by 865 other parties without having to be the owner of the subscription by 866 returning the 'successful-ok-but-cancel-subscription' status code in the 867 Send-Notifications response returned to the Printer. 869 14.1 Security Conformance 871 Printers (client) MAY support Digest Authentication [rfc2617]. If 872 Digest Authentication is supported, then MD5 and MD5-sess MUST be 873 supported, but the Message Integrity feature NEED NOT be supported. 875 Notification Recipient (server) MAY support Digest Authentication 876 [rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess 877 MUST be supported, but the Message Integrity feature NEED NOT be 878 supported. 880 Notification Recipients MAY support TLS for client authentication, 881 server authentication and operation privacy. If a Notification Recipient 882 supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 883 cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites 884 are OPTIONAL. Notification recipients MAY support Basic Authentication 885 (described in HTTP/1.1 [rfc2616]) for client authentication if the 886 channel is secure. TLS with the above mandated cipher suite can provide 887 such a secure channel. 889 15 References 891 [ipp-mod] 892 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 893 "Internet Printing Protocol/1.0: Model and Semantics", , May 22, 2000. 896 [ipp-ntfy] 897 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 898 Bergman, R., "Internet Printing Protocol/1.1: IPP Event 899 Notification Specification", , July 900 13, 2000. 902 [ipp-pro] 903 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 904 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 905 06.txt, May 30, 2000. 907 [rfc2026] 908 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 909 2026, October 1996. 911 Expires: January 14, 2001 913 [rfc2616] 914 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 915 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 916 RFC 2616, June 1999. 918 [rfc2617] 919 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. 920 Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access 921 Authentication", RFC 2617, June 1999. 923 16 Author's Addresses 925 Hugo Parra 926 Novell, Inc. 927 1800 South Novell Place 928 Provo, UT 84606 930 Phone: 801-861-3307 931 Fax: 801-861-2517 932 e-mail: hparra@novell.com 934 Tom Hastings 935 Xerox Corporation 936 737 Hawaii St. ESAE 231 937 El Segundo, CA 90245 939 Phone: 310-333-6413 940 Fax: 310-333-5514 941 e-mail: hastings@cp10.es.xerox.com 943 17 Full Copyright Statement 945 Copyright (C) The Internet Society (2000). All Rights Reserved. 947 This document and translations of it may be copied and furnished to 948 others, and derivative works that comment on or otherwise explain it or 949 assist in its implementation may be prepared, copied, published and 950 distributed, in whole or in part, without restriction of any kind, 951 provided that the above copyright notice and this paragraph are included 952 on all such copies and derivative works. However, this document itself 953 may not be modified in any way, such as by removing the copyright notice 954 or references to the Internet Society or other Internet organizations, 955 except as needed for the purpose of developing Internet standards in 956 which case the procedures for copyrights defined in the Internet 957 Standards process must be followed, or as required to translate it into 958 languages other than English. 960 The limited permissions granted above are perpetual and will not be 961 revoked by the Internet Society or its successors or assigns. 963 This document and the information contained herein is provided on an "AS 964 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 966 Expires: January 14, 2001 967 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 968 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 969 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 970 FITNESS FOR A PARTICULAR PURPOSE. 972 Expires: January 14, 2001