idnits 2.17.1 draft-ietf-ipp-notify-get-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 ([RFC2911,RFC2910], [RFC2566,RFC2565]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 255 has weird spacing: '...me name ipp...' == Line 276 has weird spacing: '...ication and a...' == Line 1117 has weird spacing: '...ent who s th...' == Line 1321 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'.) -- 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 (April 5, 2001) is 8422 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: 'IANA-PORTREG' is mentioned on line 829, but not defined == Missing Reference: 'IANA-MIMEREG' is mentioned on line 838, but not defined == Missing Reference: 'US-ASCII' is mentioned on line 847, but not defined == Unused Reference: 'RFC2026' is defined on line 1140, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1900 ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2565 (Obsoleted by RFC 2910) ** Obsolete normative reference: RFC 2566 (Obsoleted by RFC 2911) ** Downref: Normative reference to an Experimental RFC: RFC 2567 ** Downref: Normative reference to an Experimental RFC: RFC 2568 ** Downref: Normative reference to an Experimental RFC: RFC 2569 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) Summary: 19 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Robert Herriot (editor) 3 Xerox Corp. 4 [Target category: standards track] Carl Kugler 5 IBM, Corp. 6 Harry Lewis 7 IBM, Corp. 8 April 5, 2001 9 Internet Printing Protocol (IPP): 10 The 'ippget' Delivery Method for Event Notifications 12 Copyright (C) The Internet Society (2001). 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 [rfc2026]. 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. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed as 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes an extension to the Internet Printing 36 Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. 37 This document specifies the 'ippget' Delivery Method for use with the 38 IPP Event Notification Specification [ipp-ntfy].The 'ippget' Delivery 39 Method is a 'pull and push' Delivery Method. That is, when an Event 40 occurs, the Printer saves the Event Notification for a period of time 41 called the Event Notification Lease Time. The Notification Recipient 42 fetches (pulls) Event Notifications using the Get-Notifications 43 operation. If the Notification Recipient has selected the option to 44 wait for additional Event Notifications, the Printer continues to 45 return (push) Event Notifications to the Notification Recipient as 46 Get-Notification responses as Events occur. 48 Table of Contents 50 1 Introduction....................................................4 52 2 Terminology.....................................................4 54 3 Model and Operation.............................................5 56 4 General Information.............................................6 58 5 Get-Notifications operation.....................................8 59 5.1 Get-Notifications Request...................................10 60 5.2 Get-Notifications Response..................................11 62 6 Subscription Template Attributes...............................16 63 6.1 Subscription Template Attribute Conformance.................16 64 6.2 Additional Information about Subscription Template Attributes16 65 6.2.1 notify-recipient-uri (uri)................................16 66 6.3 Subscription Description Attribute Conformance..............17 68 7 Additional Printer Description Attributes......................17 69 7.1 Printer Description Attribute Conformance...................17 70 7.2 New Values for Existing Printer Description Attributes......17 71 7.2.1 notify-schemes-supported (1setOf uriScheme)...............17 72 7.2.2 operations-supported (1setOf type2 enum)..................17 73 7.3 begin-to-expire-time-interval (integer(0:MAX))..............18 75 8 New Status Codes...............................................18 76 8.1 redirection-other-site (0x300)..............................19 78 9 The IPPGET URL Scheme..........................................19 79 9.1 The IPPGET URL Scheme Applicability and Intended Usage......19 80 9.2 The IPPGET URL Scheme Associated Port.......................19 81 9.3 The IPPGET URL Scheme Associated MIME Type..................19 82 9.4 The IPPGET URL Scheme Character Encoding....................20 83 9.5 The IPPGET URL Scheme Syntax in ABNF........................20 84 9.5.1 IPPGET URL Examples.......................................21 85 9.5.2 IPPGET URL Comparisons....................................22 87 10 Encoding.......................................................22 89 11 Conformance Requirements.......................................22 90 11.1 Conformance for IPP Printers................................22 91 11.2 Conformance for IPP Clients.................................23 93 12 IANA Considerations............................................23 94 12.1 Operation Registrations.....................................24 95 12.2 Additional values of existing attributes....................24 96 12.2.1 Additional values for the "notify-schemes-supported" Printer 97 attribute..............................................24 98 12.2.2 Additional values for the "operations-supported" Printer 99 attribute..............................................24 100 12.3 Attribute Registrations.....................................25 101 12.4 Status code Registrations...................................25 103 13 Internationalization Considerations............................25 105 14 Security Considerations........................................25 107 15 References.....................................................26 109 16 Authors' Addresses.............................................28 111 17 Description of Base IPP documents..............................28 113 18 Full Copyright Statement.......................................30 115 Table of Tables 117 Table 1 - Information about the Delivery Method....................7 119 Table 2 - Attributes in Event Notification Content................14 121 Table 3 - Additional Attributes in Event Notification Content for Job 123 Events ........................................................15 125 Table 4 - Combinations of Events and Subscribed Events for "job- 127 impressions-completed" ........................................15 129 Table 5 - Additional Attributes in Event Notification Content for 131 Printer Events ................................................16 133 Table 6 - Operation-id assignments................................18 135 Table 7 - The "event-notification-attributes-tag" value...........22 137 1 Introduction 139 The "IPP Event Notification Specification" document [ipp-ntfy] 140 defines an extension to Internet Printing Protocol/1.0 (IPP) 141 [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. This extension 142 defines operations that a client can perform in order to create 143 Subscription Objects in a Printer and carry out other operations on 144 them. A Subscription Object represents a Subscription abstraction. 145 A client associates Subscription Objects with a particular Job by 146 performing the Create-Job-Subscriptions operation or by submitting a 147 Job with subscription information. A client associates Subscription 148 Objects with the Printer by performing a Create-Printer-Subscriptions 149 operation. Four other operations are defined for Subscription 150 Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew- 151 Subscription, and Cancel-Subscription. The Subscription Object 152 specifies that when one of the specified Events occurs, the Printer 153 sends an asynchronous Event Notification to the specified 154 Notification Recipient via the specified Delivery Method (i.e., 155 protocol). 157 The "IPP Event Notification Specification" document [ipp-ntfy] 158 specifies that each Delivery Method is defined in another document. 159 This document is one such document, and it specifies the 'ippget' 160 delivery method. 162 The 'ippget' Delivery Method is a 'pull and push' Delivery Method. 163 That is, when an Event occurs, the Printer saves the Event 164 Notification for a period of time called the Event Notification Lease 165 Time. The Notification Recipient fetches (pulls) the Event 166 Notifications using the Get-Notifications operation. This operation 167 causes the Printer to return all Event Notifications held for the 168 Notification Recipient. If the Notification Recipient has selected 169 the option to wait for additional Event Notifications, the Printer 170 continues to return (push) Event Notifications to the Notification 171 Recipient as Get-Notification responses as Events occur. 173 2 Terminology 175 This section defines the following terms that are used throughout 176 this document: 178 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 179 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 180 conformance to this specification. These terms are defined in 181 [RFC2911 section 13.1 on conformance terminology, most of which is 182 taken from RFC 2119 [RFC2119]. 184 Event Notification Lease: The lease that is associated with an Event 185 Notification. When the lease expires, the Printer discards the 186 associated Event Notification. 188 Event Notification Lease Time: The expiration time assigned to a 189 lease that is associated with an Event Notification. 191 Event Notification Attributes Group: The attributes group in a 192 response that contains attributes that are part of an Event 193 Notification. 195 For other capitalized terms that appear in this document, see [ipp- 196 ntfy]. 198 3 Model and Operation 200 In a Subscription Creation Operation, when the value of the "notify- 201 recipient-uri" attribute has the scheme 'ippget', the client is 202 requesting that the Printer use the 'ippget' Delivery Method for the 203 Event Notifications associated with the new Subscription Object. The 204 client SHOULD choose a value for the address part of the "notify- 205 recipient-uri" attribute that uniquely identifies the Notification 206 Recipient. 208 When an Event occurs, the Printer MUST generate an Event Notification 209 and MUST assign it the Event Notification Lease Time. The Printer 210 MUST hold an Event Notification for its assigned Event Notification 211 Lease Time. The Printer MUST assign the same Event Notification 212 Lease Time to each Event Notification. 214 When a Notification Recipient wants to receive Event Notifications, 215 it performs the Get-Notifications operation, which causes the Printer 216 to return all un-expired Event Notifications held for the 217 Notification Recipient. If the Notification Recipient has selected 218 the option to wait for additional Event Notifications, the response 219 to the Get-Notifications request continues indefinitely as the 220 Printer continues to send Event Notifications in the response as 221 Events occur. For the Get-Notification operation, the Printer sends 222 only those Event Notifications that are generated from Subscription 223 Objects whose "notify-recipient-uri" attribute value equals the value 224 of the "notify-recipient-uri" Operation Attribute in the Get- 225 Notifications operation. 227 If a Notification Recipient performs the Get-Notifications operation 228 twice in quick succession, it will receive nearly the same Event 229 Notification both times because most of the Event Notifications are 230 those that the Printer saves for a few seconds after the Event 231 occurs. There are two possible differences. Some old Event 232 Notifications may not be present in the second response because their 233 Event Notification Leases have expired. Some new Event Notifications 234 may be present in the second response but not the first response. 236 When the Notification Recipient requests Event Notifications for per- 237 Job Subscription Objects, the Notification Recipient typically 238 performs the Get-Notifications operation within a second of 239 performing the Subscription Creation operation. Because the Printer 240 is likely to save Event Notifications for several seconds, the 241 Notification Recipient is unlikely to miss any Event Notifications 242 that occur between the Subscription Creation and the Get- 243 Notifications operation. 245 4 General Information 247 If a Printer supports this Delivery Method, the following are its 248 characteristics. 250 Table 1 - Information about the Delivery Method 252 Document Method Conformance Delivery Method Realization 253 Requirement 255 1. What is the URL scheme name ippget 256 for the Delivery Method? 258 2. Is the Delivery Method RECOMMENDED 259 REQUIRED, RECOMMENDED or 260 OPTIONAL for an IPP Printer 261 to support? 263 3. What transport and delivery IPP with one new operation. 264 protocols does the Printer 265 use to deliver the Event 266 Notification Content, i.e., 267 what is the entire network 268 stack? 270 4. Can several Event Yes. 271 Notifications be combined 272 into a Compound Event 273 Notification? 275 5. Is the Delivery Method This Delivery Method is a pull 276 initiated by the Notification and a push. 277 Recipient (pull), or by the 278 Printer (push)? 280 6. Is the Event Notification Machine Consumable 281 content Machine Consumable or 282 Human Consumable? 284 7. What section in this document Section 5 285 answers the following 286 question? For a Machine 287 Consumable Event 288 Notification, what is the 289 representation and encoding 290 of values defined in section 291 9.1 of [ipp-ntfy] and the 292 conformance requirements 293 thereof? For a Human 294 Consumable Event 295 Notification, what is the 296 representation and encoding 297 of pieces of information 298 defined in section 9.2 of 299 [ipp-ntfy] and the 300 conformance requirements 301 thereof? 303 8. What are the latency and Same as IPP and the underlying 304 reliability of the transport HTTP transport 305 and delivery protocol? 307 9. What are the security aspects Same as IPP and the underlying 308 of the transport and delivery HTTP transport 309 protocol, e.g., how it is 310 handled in firewalls? 312 10. What are the content length None 313 restrictions? 315 11. What are the additional None 316 values or pieces of 317 information that a Printer 318 sends in an Event 319 Notification content and the 320 conformance requirements 321 thereof? 323 12. What are the additional None 324 Subscription Template and/or 325 Subscription Description 326 attributes and the 327 conformance requirements 328 thereof? 330 13. What are the additional None 331 Printer Description 332 attributes and the 333 conformance requirements 334 thereof? 336 5 Get-Notifications operation 338 This operation causes the Printer to return all Event Notifications 339 held for the Notification Recipient. 341 A Printer MUST support this operation. 343 When a Printer performs this operation, it MUST return all and only 344 those Event Notifications: 346 1. Whose associated Subscription Object's "notify-recipient-uri" 347 attribute equals the "notify-recipient-uri" Operation attribute 348 AND 350 2. Whose associated Subscription Object's "notify-recipient-uri" 351 attribute has a scheme value of 'ippget' AND 353 3. Whose Event Notification Lease Time has not yet expired AND 355 4. Where the Notification Recipient is the owner of or has read- 356 access rights to the associated Subscription Object. 358 The Printer MUST respond to this operation immediately with whatever 359 Event Notifications it currently holds. If the Notification Recipient 360 has selected the option to wait for additional Event Notifications, 361 the Printer MUST continue to send Event Notifications as they occur 362 until all of the associated Subscription Objects are cancelled. A 363 Subscription Object is cancelled either via the Cancel-Subscription 364 operation or by the Printer (e.g. the Subscription Object is 365 cancelled when the associated Job completes). 367 Note, the Printer terminates the operation in the same way that it 368 normally terminates IPP operations. For example, if the Printer is 369 sending chunked data, it can send a 0 length chunk to denote the end 370 of the operation or it can close the connection. If the Notification 371 Recipient wishes to terminate the Get-Notifications operation, it can 372 close the connection. 374 The Printer MUST accept the request in any state (see [RFC2911] 375 "printer-state" and "printer-state-reasons" attributes) and MUST 376 remain in the same state with the same "printer-state-reasons" 377 values. 379 Access Rights: If the policy of the Printer is to allow all users to 380 access all Event Notifications, then the Printer MUST accept this 381 operation from any user. Otherwise, the authenticated user (see 382 [RFC2911] section 8.3) performing this operation MUST either be the 383 owner of each Subscription Object identified by the "notify- 384 recipient-uri" Operation attribute (as determined during a 385 Subscription Creation Operation) or an operator or administrator of 386 the Printer (see [RFC2911] Sections 1 and 8.5). Otherwise, the IPP 387 object MUST reject the operation and return: 'client-error- 388 forbidden', 'client-error-not-authenticated', or 'client-error-not- 389 authorized' status code as appropriate. 391 5.1 Get-Notifications Request 393 The following groups of attributes are part of the Get-Notifications 394 Request: 396 Group 1: Operation Attributes 398 Natural Language and Character Set: 399 The "attributes-charset" and "attributes-natural-language" 400 attributes as described in [RFC2911] section 3.1.4.1. 402 Target: 403 The "printer-uri" (uri) operation attribute which is the target 404 for this operation as described in [RFC2911] section 3.1.5. 406 Requesting User Name: 407 The "requesting-user-name" (name(MAX)) attribute SHOULD be 408 supplied by the client as described in [RFC2911] section 8.3. 410 "notify-recipient-uri" (url): 411 The client MUST supply this attribute. The Printer object MUST 412 support this attribute. The Printer matches the value of this 413 attribute (byte for byte with no case conversion) against the 414 value of the "notify-recipient-uri" in each Subscription Object 415 in the Printer. If there are no matches, the IPP Printer MUST 416 return the 'client-error-not-found' status code. For each 417 matched Subscription Object, the IPP Printer MUST return all 418 unexpired Event Notifications associated with it. The Printer 419 MUST send additional Event Notifications as Events occur if and 420 only if the value of the "notify-no-wait" attribute is 'false' 421 or not supplied by the client (see the next attribute below). 423 Note: this attribute allows a subscribing client to pick URLs 424 that are unique, e.g. the client's own URL or a friend's URL, 425 which in both cases is likely the URL of the person's host. An 426 application could make a URL unique for each application. 428 "notify-no-wait" (boolean): 429 The client MAY supply this attribute. The Printer object MUST 430 support this attribute. If the value of this attribute is 431 'false', the Printer MUST send all un-expired Event 432 Notifications (as defined in the previous attribute) and it 433 MUST continue to send responses for as long as the Subscription 434 Objects associated with the specified "notify-recipient-uri" 435 continue to exist. If the value of this attribute is 'true', 436 the Printer MUST send all un-expired Event Notifications (as 437 defined in the previous attribute) and the Printer MUST 438 conclude the operation without waiting for any additional 439 Events to occur. If the client doesn't supply this attribute, 440 the Printer MUST behave as if the client had supplied this 441 attribute with the value of 'false'. 443 5.2 Get-Notifications Response 445 The following groups of attributes are part of the Get-Notifications 446 Response: 448 Group 1: Operation Attributes 450 Status Message: 451 In addition to the REQUIRED status code returned in every 452 response, the response OPTIONALLY includes a "status-message" 453 (text(255)) and/or a "detailed-status-message" (text(MAX)) 454 operation attribute as described in [RFC2911] sections 13 and 455 3.1.6. 457 The Printer can return any status codes defined in [RFC2911]. 458 If the status code is not 'successful-', the Printer MUST NOT 459 return any Event Notification Attribute groups. The following 460 is a description of the important status codes: 462 successful-ok: the response contains all Event Notification 463 associated with the specified "notify-recipient-uri". If 464 the specified Subscription Objects have no associated 465 Event Notification, the response MUST contain zero Event 466 Notifications. 467 client-error-not-found: The Printer has no Subscription 468 Object's whose "notify-recipient-uri" attribute equals 469 the "notify-recipient-uri" Operation attribute. 470 server-error-busy: The Printer is too busy to accept this 471 operation. If the "suggested-ask-again-time-interval" 472 operation attribute is present in the Operation 473 Attributes of the response, then the Notification 474 Recipient SHOULD wait for the number of seconds specified 475 by the "suggested-ask-again-time-interval" attribute 476 before performing this operation again. If the 477 "suggested-ask-again-time-interval" Operation Attribute 478 is not present, the Notification Recipient should use the 479 normal network back-off algorithms for determining when 480 to perform this operation again. 481 redirection-other-site: The Printer does not handle this 482 operation and requests the Notification Recipient to 483 perform the operation with the uri specified by the 484 "notify-ippget-redirect" Operation Attribute in the 485 response. 487 Natural Language and Character Set: 488 The "attributes-charset" and "attributes-natural-language" 489 attributes as described in [RFC2911] section 3.1.4.2. 491 The Printer MUST use the values of "notify-charset" and 492 "notify-natural-language", respectively, from one Subscription 493 Object associated with the Event Notifications in this 494 response. 496 Normally, there is only one matched Subscription Object, or the 497 value of the "notify-charset" and "notify-natural-language" 498 attributes is the same in all Subscription Objects. If not, the 499 Printer MUST pick one Subscription Object from which to obtain 500 the value of these attributes. The algorithm for picking the 501 Subscription Object is implementation dependent. The choice of 502 natural language is not critical because 'text' and 'name' 503 values can override the "attributes-natural-language" Operation 504 attribute. The Printer's choice of charset is critical because 505 a bad choice may leave it unable to send some 'text' and 'name' 506 values accurately. 508 "printer-up-time" (integer(0:MAX)): 509 The value of this attribute is the Printer's "printer-up-time" 510 attribute at the time the Printer sends this response. Because 511 each Event Notification also contains the value of this 512 attribute when the event occurred, the value of this attribute 513 lets a Notification Recipient know when each Event Notification 514 occurred relative to the time of this response. 516 "suggested-ask-again-time-interval" (integer(0:MAX)): 517 The value of this attribute is the number of seconds that the 518 Notification Recipient SHOULD wait before trying this operation 519 again when 520 a) the Printer returns the 'server-error-busy' status code 521 OR 522 b) the Printer returns the 'successful-ok' status code and 523 the client supplied the "notify-no-wait" attribute with a 524 value of 'true'. 525 This value is intended to help the client be a good network 526 citizen. 528 "notify-ippget-redirect" (uri): 529 The value of this attribute is uri that the Notification 530 Recipient MUST use for the Get-Notifications operation. This 531 attribute is present in the Operation Attributes if and only if 532 the status code has the value 'redirection-other-site'. 534 Group 2: Unsupported Attributes 536 See [RFC2911] section 3.1.7 for details on returning 537 Unsupported Attributes. 539 If the "subscription-ids" attribute contained subscription-ids 540 that do not exist, the Printer returns them in this group as 541 value of the "subscription-ids" attribute. 543 Group 3 through N: Event Notification Attributes 545 The Printer responds with one Event Notification Attributes 546 Group per matched Event Notification. The initial matched Event 547 Notifications are all un-expired Event Notification associated 548 with the matched Subscription Objects. If the Notification 549 Recipient has selected the option to wait for additional Event 550 Notifications, the Printer the subsequent Event Notifications 551 in the response are Event Notifications associated with the 552 matched Subscription Objects as the corresponding Event occurs. 554 From the Notification Recipient's view, the response appears as 555 an initial burst of data, which includes the Operation 556 Attributes Group and one Event Notification Attributes Groups 557 per Event Notification that the Printer is holding. After the 558 initial burst of data, if the Notification Recipient has 559 selected the option to wait for additional Event Notifications, 560 the Notification Recipient receives occasional Event 561 Notification Attribute Groups. Proxy servers may delay some 562 Event Notifications or cause time-outs to occur. The client 563 MUST be prepared to perform the Get-Notifications operation 564 again when time-outs occur. 566 Each Event Notification Group MUST start with an 'event- 567 notification-attributes-tag' (see the section "Encodings of 568 Additional Attribute Tags" in [ipp-ntfy]). 570 Each attribute is encoded using the IPP rules for encoding 571 attributes [RFC2910] and may be encoded in any order. Note: 572 the Get-Jobs response in [RFC2911] acts as a model for encoding 573 multiple groups of attributes. 575 Each Event Notification Group MUST contain all of attributes 576 specified in section 9.1 ("Content of Machine Consumable Event 577 Notifications") of [ipp-ntfy] with exceptions denoted by 578 asterisks in the tables below. 580 The tables below are copies of the tables in section 9.1 581 ("Content of Machine Consumable Event Notifications") of [ipp- 582 ntfy] except that each cell in the "Sends" column is a "MUST". 584 For an Event Notification for all Events, the Printer includes 585 the attributes shown in Table 2. 587 Table 2 - Attributes in Event Notification Content 589 Source Value Sends Source Object 591 notify-subscription-id (integer(1:MAX)) MUST Subscription 593 notify-printer-uri (uri) MUST Subscription 595 notify-subscribed-event (type2 keyword) MUST Event 596 Notification 598 printer-up-time (integer(MIN:MAX)) MUST Printer 600 printer-current-time (dateTime) MUST * Printer 602 notify-sequence-number (integer (0:MAX)) MUST Subscription 604 notify-charset (charset) MUST Subscription 606 notify-natural-language (naturalLanguage) MUST Subscription 608 notify-user-data (octetString(63)) MUST ** Subscription 610 notify-text (text) MUST Event 611 Notification 613 attributes from the "notify-attributes" MUST *** Printer 614 attribute 616 attributes from the "notify-attributes" MUST *** Job 617 attribute 619 attributes from the "notify-attributes" MUST *** Subscription 620 attribute 622 * The Printer MUST send the "printer-current-time" attribute if 623 and only if it supports the "printer-current-time" attribute on 624 the Printer object. 626 ** If the associated Subscription Object does not contain a 627 "notify-user-data" attribute, the Printer MUST send an octet- 628 string of length 0. 630 *** If the "notify-attributes" attribute is present on the 631 Subscription Object, the Printer MUST send all attributes 632 specified by the "notify-attributes" attribute. Note: if the 633 Printer doesn't support the "notify-attributes" attribute, it 634 is not present on the associated Subscription Object. 636 For Event Notifications for Job Events, the Printer includes 637 the additional attributes shown in Table 3. 639 Table 3 - Additional Attributes in Event Notification Content for 640 Job Events 642 Source Value Sends Source 643 Object 645 job-id (integer(1:MAX)) MUST Job 647 job-state (type1 enum) MUST Job 649 job-state-reasons (1setOf type2 keyword) MUST Job 651 job-impressions-completed (integer(0:MAX)) MUST * Job 653 * The Printer MUST send the "job-impressions-completed" 654 attribute in an Event Notification only for the combinations of 655 Events and Subscribed Events shown in Table 4. 657 Table 4 - Combinations of Events and Subscribed Events for "job- 658 impressions-completed" 660 Job Event Subscribed Job Event 662 'job-progress' 'job-progress' 664 'job-completed' 'job-completed' 666 'job-completed' 'job-state-changed' 668 For Event Notification for Printer Events, the Printer includes 669 the additional attributes shown in Table 5. 671 Table 5 - Additional Attributes in Event Notification Content for 672 Printer Events 674 Source Value Sends Source 675 Object 677 printer-state (type1 enum) MUST Printer 679 printer-state-reasons (1setOf type2 keyword) MUST Printer 681 printer-is-accepting-jobs (boolean) MUST Printer 683 6 Subscription Template Attributes 685 This section defines the Subscription object conformance requirements 686 for Printers. 688 6.1 Subscription Template Attribute Conformance 690 The 'ippget' Delivery Method has the same conformance requirements 691 for Subscription Template attributes as defined in [ipp-ntfy]. The 692 'ippget' Delivery Method does not define any addition Subscription 693 Template attributes. 695 6.2 Additional Information about Subscription Template Attributes 697 This section defines additional information about Subscription 698 Template attributes defined in [ipp-ntfy]. 700 6.2.1 notify-recipient-uri (uri) 702 This section describes the syntax of the value of this attribute for 703 the 'ippget' Delivery Method. The syntax for values of this 704 attribute for other Delivery Method is defined in other Delivery 705 Method Documents. 707 In order to support the 'ippget' Delivery Method and Protocol, the 708 Printer MUST support the following syntax: 710 The 'ippget://' URI scheme. The remainder of the URI indicates 711 something unique about the Notification Recipient, such as its host 712 name or host address (and optional path) that the Printer uses to 713 match the "notify-recipient-uri" Operation attribute supplied in 714 the Get-Notifications request. See section 9 for a complete 715 definition of the syntax of the IPPGET URL. 717 6.3 Subscription Description Attribute Conformance 719 The 'ippget' Delivery Method has the same conformance requirements 720 for Subscription Description attributes as defined in [ipp-ntfy]. 721 The 'ippget' Delivery Method does not define any addition 722 Subscription Description attributes. 724 7 Additional Printer Description Attributes 726 This section defines the Printer Description Attributes conformance 727 requirements for Printers. 729 7.1 Printer Description Attribute Conformance 731 The 'ippget' Delivery Method has the same conformance requirements 732 for Printer Description attributes as defined in [ipp-ntfy]. The 733 'ippget' Delivery Method does not define any addition Printer 734 Description attributes. 736 7.2 New Values for Existing Printer Description Attributes 738 This section defines additional values for existing Printer 739 Description attributes. 741 7.2.1 notify-schemes-supported (1setOf uriScheme) 743 The following value for the "notify-schemes-supported" attribute is 744 added in order to support the new Delivery Method defined in this 745 document: 747 'ippget' - The IPP Notification Delivery Method defined in this 748 document. 750 7.2.2 operations-supported (1setOf type2 enum) 752 Table 6 lists the "operation-id" value defined in order to support 753 the new Get-Notifications operation defined in this document. 755 Table 6 - Operation-id assignments 757 Value Operation Name 759 0x001C Get-Notifications 761 7.3 begin-to-expire-time-interval (integer(0:MAX)) 763 This Printer Description attribute specifies the number of seconds 764 that a Printer keeps an Event Notification that is associated with 765 the 'ippget' Delivery Method. 767 The Printer MUST support this attribute if it supports the 'ippget' 768 Delivery Method. 770 The value of this attribute is the minimum number of seconds that 771 MUST elapse between the time the Printer creates an Event 772 Notification object for the 'ippget' Delivery Method and the time the 773 Printer discards the same Event Notification. 775 For example, assume the following: 777 1.a client performs a Job Creation operation that creates a 778 Subscription Object associated with this Delivery Method, AND 780 2.an Event associated with the new Job occurs immediately after 781 the Subscription Object is created, AND 783 3.the same client or some other client performs a Get- 784 Notifications operation N seconds after the Job Creation 785 operation. 787 Then, if N is less than the value of this attribute, the client 788 performing the Get-Notifications operations can expect not to miss 789 any Event-Notifications, barring some unforeseen lack of memory space 790 in the Printer. 792 8 New Status Codes 794 The following status codes are defined as extensions for this 795 Delivery Method and are returned as the status code of the Get- 796 Notifications operation. 798 8.1 redirection-other-site (0x300) 800 This status code means that the Printer doesn't perform that Get- 801 Notifications operation and that the "notify-ippget-redirect" 802 Operation Attribute in the response contains the uri that the 803 Notification Recipient MUST use for performing the Get-Notifications 804 operation. 806 9 The IPPGET URL Scheme 808 This section defines the 'ippget' URL and the conformance 809 requirements for using it. 811 9.1 The IPPGET URL Scheme Applicability and Intended Usage 813 This section is intended for use in registering the 'ippget' URL 814 scheme with IANA and fully conforms to the requirements in [RFC2717]. 815 This document defines the 'ippget'" URL (Uniform Resource Locator) 816 scheme for specifying a unique identifier for an IPP Client which 817 implements the IPP Get-Notifications operation specified in this 818 document (see section 5). 820 The intended usage of the 'ippget' URL scheme is COMMON. 822 9.2 The IPPGET URL Scheme Associated Port 824 None. 826 An 'ippget' URL behaves as a unique identifier for IPP Clients and is 827 NOT used to initiate any over-the-wire protocol associations. 829 See: IANA Port Numbers Registry [IANA-PORTREG]. 831 9.3 The IPPGET URL Scheme Associated MIME Type 833 All IPP Get-Notifications operations (requests and responses) MUST be 834 conveyed in an 'application/ipp' MIME media type as registered in 835 [IANA-MIMEREG]. An 'ippget' URL MUST uniquely identify an IPP Client 836 that support this 'application/ipp' MIME media type. 838 See: IANA MIME Media Types Registry [IANA-MIMEREG]. 840 9.4 The IPPGET URL Scheme Character Encoding 842 The 'ippget' URL scheme defined in this document is based on the ABNF 843 for the URI Generic Syntax [RFC2396] and further updated by [RFC2732] 844 and [RFC2373] (for IPv6 addresses in URLs). The 'ippget' URL scheme 845 is case-insensitive in the scheme and 'authority' part; however, the 846 'abs_path' part is case-sensitive, as in [RFC2396]. Code points 847 outside [US-ASCII] MUST be hex escaped by the mechanism specified in 848 [RFC2396]. 850 9.5 The IPPGET URL Scheme Syntax in ABNF 852 This document is intended for use in registering the 'ippget' URL 853 scheme with IANA and fully conforms to the requirements in [RFC2717]. 854 This document defines the 'ippget' URL (Uniform Resource Locator) 855 scheme for specifying a unique identifier for an IPP Client which 856 implements IPP 'Get-Notifications' operation specified in this 857 document. 859 The intended usage of the 'ippget' URL scheme is COMMON. 861 The IPP protocol places a limit of 1023 octets (NOT characters) on 862 the length of a URI (see section 4.1.5 'uri' in [RFC2911]). An IPP 863 Printer MUST return the 'client-error-request-value-too-long' status 864 code (see section 13.1.4.10 in [RFC2911]) when a URI received in a 865 request is too long. 867 Note: IPP Clients and IPP Printers ought to be cautious about 868 depending on URI lengths above 255 bytes, because some older client 869 or proxy implementations might not properly support these lengths. 871 An 'ippget' URL MUST be represented in absolute form. Absolute URLs 872 always begin with a scheme name followed by a colon. For definitive 873 information on URL syntax and semantics, see "Uniform Resource 874 Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This 875 specification adopts the definitions of "authority", "abs_path", 876 "query", "reg_name", "server", "userinfo", and "hostport" from 877 [RFC2396], as updated by [RFC2732] and [RFC2373] (for IPv6 addresses 878 in URLs). 880 The 'ippget' URL scheme syntax in ABNF is as follows: 882 ippget_URL = "ippget:" "//" authority [ abs_path [ "?" query ]] 883 authority = server | reg_name 884 reg_name = 1*( unreserved | escaped | "$" | "," | 885 ";" | ":" | "@" | "&" | "=" | "+" ) 886 server = [ [ userinfo "@" ] hostport ] 887 userinfo = *( unreserved | escaped | 888 ";" | ":" | "&" | "=" | "+" | "$" | "," ) 890 hostport = host [ ":" port ] 891 abs_path = "/" path_segments 893 If the port is empty or not given, then no port is assumed. The 894 semantics are that the 'ippget' URL is a unique identifier for an IPP 895 Client that will retrieve IPP event notifications via the IPP Get- 896 Notifications operation. 898 Note: The use of IP addresses in URLs SHOULD be avoided whenever 899 possible (see [RFC1900]). 901 9.5.1 IPPGET URL Examples 903 The following are examples of valid 'ippget' URLs for IPP Clients 904 (using DNS host names): 906 ippget://abc.com 907 ippget://abc.com/listener 908 ippget://bob@abc.com/listener/1232 910 Note: The use of IP addresses in URLs SHOULD be avoided whenever 911 possible (see [RFC1900]). 913 The IPP Client that creates the Subscription object and the 914 Notification Recipient have to agree on a unique IPPGET URL value in 915 order for the Get-Notifications operations to retrieve the proper 916 Event Notifications. Therefore, the choice of 'userinfo@hostport' 917 versus the simpler 'hostport' production in an 'ippget' URL may be 918 influenced by the intended usage. 920 If a given IPP Client creates an IPP Subscription object for event 921 notifications intended for retrieval by the same IPP Client, then the 922 simple 'hostport' production may be most appropriate. In this case, 923 the IPP Client and the Notification Recipient both know the 924 'hostport' of the client. 926 On the other hand, if a given IPP Client creates an IPP Subscription 927 object for event notifications intended for retrieval by a different 928 IPP Client, then the 'userinfo@hostport' production (using, for 929 example, the right-hand side of a 'mailto:' URL, see [RFC2368]) may 930 be most appropriate. For this case, a mail address serves as the 931 prior agreement on the IPPGET URL value between the IPP Client and 932 the Notification Recipient. 934 9.5.2 IPPGET URL Comparisons 936 When comparing two 'ippget' URLs to decide if they match or not, 937 an IPP Client or IPP Printer MUST use the same rules as those 938 defined for HTTP URI comparisons in [RFC2616]. 940 10 Encoding 942 This notification delivery method uses the IPP transport and encoding 943 [RFC2910] for the Get-Notifications operation with one extension 944 allocated in [ipp-ntfy]: 946 Table 7 - The "event-notification-attributes-tag" value 948 Tag Value (Hex) Meaning 950 0x07 "event-notification-attributes-tag" 952 11 Conformance Requirements 954 11.1 Conformance for IPP Printers 956 IPP Printers that conform to this specification: 958 1. MUST meet the conformance requirements defined in [ipp-ntfy]; 960 2. MUST support the Get-Notifications operation defined in section 961 5; 963 3. MUST support the Subscription object attributes as defined in 964 section 6; 966 4. MUST support the additional values for IPP/1.1 Printer 967 Description attributes defined in section 7.2; 969 5. MUST support the "begin-to-expire-time-interval" Printer 970 Description attribute defined in section 7.3; 972 6. MUST support the "redirection-other-site" status code defined 973 8.1; 975 7. SHOULD reject received 'ippget' URLs in 'application/ipp' 976 request bodies (e.g., in the "notify-recipient-uri" attribute in 977 a Get-Notifications request) that do not conform to the ABNF for 978 'ippget' URLs specified in section 9.5 of this document; 980 8. MUST listen for the IPP Get-Notifications operation requests on 981 IANA-assigned well-known port 631, unless explicitly configured 982 by system administrators or site policies; 984 9. SHOULD NOT listen for IPP Get-Notifications operation requests 985 on any other port, unless explicitly configured by system 986 administrators or site policies. 988 11.2 Conformance for IPP Clients 990 IPP Clients that conform to this specification: 992 1.MUST create unambiguously unique 'ippget' URLs in all cases; 994 2.MUST send 'ippget' URLs (e.g., in the "notify-recipient-uri" 995 attribute in a Get-Notifications request) that conform to the 996 ABNF specified in section 9.5 of this document; 998 3.MUST send IPP Get-Notifications operation requests via the port 999 specified in the associated 'ipp' URL (if present) or otherwise 1000 via IANA assigned well-known port 631; 1002 4.MUST convert the associated 'ipp' URLs for use in IPP Get- 1003 Notifications operation to their corresponding 'http' URL forms 1004 for use in the HTTP layer according to the rules in section 5 1005 "IPP URL Scheme" in [RFC2910]. 1007 Note: The use of ambiguous 'ippget' URLs is NOT an optional feature 1008 for IPP Clients; it is a non-conformant implementation error. 1010 12 IANA Considerations 1012 IANA is requested to register the 'ippget' URL scheme as defined in 1013 section 9 according to the procedures of [RFC2717]. 1015 The rest of this section contains the exact information for 1016 additional IPP entities for IANA to add to the IPP Registries 1017 according to the procedures defined in RFC 2911 [RFC2911] section 6. 1019 Note to RFC Editors: Replace RFC NNNN below with the RFC number 1020 for this document, so that it accurately reflects the content of 1021 the information for the IANA Registry. 1023 12.1 Operation Registrations 1025 The operations defined in this document will be published by IANA 1026 according to the procedures in RFC 2911 [RFC2911] section 6.4 with 1027 the following path: 1029 ftp.isi.edu/iana/assignments/ipp/operations/ 1031 The registry entry will contain the following information: 1033 Operations: Ref. Section: 1034 Get-Notifications operation RFC NNNN 5 1036 12.2 Additional values of existing attributes 1038 12.2.1 Additional values for the "notify-schemes-supported" Printer 1039 attribute 1041 The "notify-schemes-supported" 'uriScheme' attribute value defined in 1042 this document will be published by IANA according to the procedures 1043 in RFC 2911 [RFC2911] section 6.1 with the following path: 1045 ftp.isi.edu/iana/assignments/ipp/attribute-values/notify-schemes- 1046 supported/ 1048 The registry entry will contain the following information: 1050 Ref. Section: 1051 ippget RFC NNNN 7.2.1 1053 12.2.2 Additional values for the "operations-supported" Printer 1054 attribute 1056 The "operations-supported" type2 enum attribute value defined in this 1057 document will be published by IANA according to the procedures in RFC 1058 2911 [RFC2911] section 6.1 with the following path: 1060 ftp.isi.edu/iana/assignments/ipp/attribute-values/operations- 1061 supported/ 1063 The registry entry will contain the following information: 1065 Value Ref. Section: 1066 Get-Notifications 0x001C RFC NNNN 7.2.2 1068 12.3 Attribute Registrations 1070 The attributes defined in this document will be published by IANA 1071 according to the procedures in RFC 2911 [RFC2911] section 6.2 with 1072 the following path: 1074 ftp.isi.edu/iana/assignments/ipp/attributes/ 1076 The registry entry will contain the following information: 1078 Printer Description attributes: Ref. Section: 1079 begin-to-expire-time-interval (integer(0:MAX)) RFC NNNN 7.3 1081 12.4 Status code Registrations 1083 The status codes defined in this document will be published by IANA 1084 according to the procedures in RFC 2911 [RFC2911] section 6.6 with 1085 the following path: 1087 ftp.isi.edu/iana/assignments/ipp/status-codes/ 1089 The registry entry will contain the following information: 1091 Status codes: Ref. Section: 1092 redirection-other-site (0x300) RFC NNNN 8.1 1094 13 Internationalization Considerations 1096 The IPP Printer MUST localize the "notify-text" attribute as 1097 specified in section 14 of [ipp-ntfy]. 1099 In addition, when the client receives the Get-Notifications response, 1100 it is expected to localize the attributes that have the 'keyword' 1101 attribute syntax according to the charset and natural language 1102 requested in the Get-Notifications request. 1104 14 Security Considerations 1106 The IPP Model and Semantics document [RFC2911] discusses high-level 1107 security requirements (Client Authentication, Server Authentication 1108 and Operation Privacy). Client Authentication is the mechanism by 1109 which the client proves its identity to the server in a secure 1110 manner. Server Authentication is the mechanism by which the server 1111 proves its identity to the client in a secure manner. Operation 1112 Privacy is defined as a mechanism for protecting operations from 1113 eavesdropping. 1115 Unlike other Event Notification delivery methods in which the IPP 1116 Printer initiates the Event Notification, with the method defined in 1117 this document, the Notification Recipient is the client who s the 1118 Get-Notifications operation. Therefore, there is no chance of "spam" 1119 notifications with this method. Furthermore, such a client can close 1120 down the HTTP channel at any time, and so can avoid future unwanted 1121 Event Notifications at any time. 1123 15 References 1125 [ipp-iig] 1126 Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P., 1127 "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers- 1128 guide-v11-02.txt, work in progress, January 25, 2001 1130 [ipp-ntfy] 1131 R. Herriot, Hastings, T., Isaacson, S., Martin, J., deBry, R., 1132 Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP 1133 Event Notification Specification", , February 24, 2001. 1136 [RFC1900] 1137 B. Carpenter, Y. Rekhter. Renumbering Needs Work, RFC 1900, 1138 February 1996. 1140 [RFC2026] 1141 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 1142 2026, October 1996. 1144 [RFC2119] 1145 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1146 Levels", RFC 2119 , March 1997 1148 [RFC2368] 1149 P. Hoffman, L. Masinter, J. Zawinski. The "mailto" URL Scheme, RFC 1150 2368, July 1998. 1152 [RFC2373] 1153 R. Hinden, S. Deering. IP Version 6 Addressing Architecture, RFC 1154 2373, July 1998. 1156 [RFC2396] 1157 Berners-Lee, T. et al. Uniform Resource Identifiers (URI): Generic 1158 Syntax, RFC 2396, August 1998 1160 [RFC2565] 1161 Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet 1162 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1163 1999. 1165 [RFC2566] 1166 R. deBry, T. Hastings, R. Herriot, S. Isaacson, and P. Powell, 1167 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1168 April 1999. 1170 [RFC2567] 1171 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1172 2567, April 1999. 1174 [RFC2568] 1175 Zilles, S., "Rationale for the Structure and Model and Protocol for 1176 the Internet Printing Protocol", RFC 2568, April 1999. 1178 [RFC2569] 1179 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1180 LPD and IPP Protocols", RFC 2569, April 1999. 1182 [RFC2567] 1183 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1184 2567, April 1999. 1186 [RFC2568] 1187 Zilles, S., "Rationale for the Structure and Model and Protocol for 1188 the Internet Printing Protocol", RFC 2568, April 1999. 1190 [RFC2569] 1191 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1192 LPD and IPP Protocols", RFC 2569, April 1999. 1194 [RFC2616] 1195 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1196 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1197 RFC 2616, June 1999. 1199 [RFC2717] 1200 R. Petke and I. King, "Registration Procedures for URL Scheme 1201 Names", RFC 2717, November 1999. 1203 [RFC2732] 1204 R. Hinden, B. Carpenter, L. Masinter. Format for Literal IPv6 1205 Addresses in URL's, RFC 2732, December 1999. 1207 [RFC2910] 1208 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1209 Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 1211 [RFC2911] 1212 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1213 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 1214 September 2000. 1216 16 Authors' Addresses 1218 Robert Herriot 1219 Xerox Corp. 1220 3400 Hill View Ave, Building 1 1221 Palo Alto, CA 94304 1223 Phone: 650-813-7696 1224 Fax: 650-813-6860 1225 e-mail: robert.herriot@pahv.xerox.com 1227 Carl Kugler 1228 IBM 1229 P.O. Box 1900 1230 Boulder, CO 80301-9191 1232 Phone: 1233 Fax: 1234 e-mail: kugler@us.ibm.com 1236 Harry Lewis 1237 IBM 1238 P.O. Box 1900 1239 Boulder, CO 80301-9191 1241 Phone: 303-924-5337 1242 FAX: 1243 e-mail: harryl@us.ibm.com 1245 17 Description of Base IPP documents 1246 The base set of IPP documents includes: 1248 Design Goals for an Internet Printing Protocol [RFC2567] 1249 Rationale for the Structure and Model and Protocol for the Internet 1250 Printing Protocol [RFC2568] 1251 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 1252 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 1253 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 1254 Mapping between LPD and IPP Protocols [RFC2569] 1255 Internet Printing Protocol (IPP): IPP Event Notification 1256 Specification [ipp-ntfy] 1258 The "Design Goals for an Internet Printing Protocol" document takes a 1259 broad look at distributed printing functionality, and it enumerates 1260 real-life scenarios that help to clarify the features that need to be 1261 included in a printing protocol for the Internet. It identifies 1262 requirements for three types of users: end users, operators, and 1263 administrators. It calls out a subset of end user requirements that 1264 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 1265 been added to IPP/1.1. 1267 The "Rationale for the Structure and Model and Protocol for the 1268 Internet Printing Protocol" document describes IPP from a high level 1269 view, defines a roadmap for the various documents that form the suite 1270 of IPP specification documents, and gives background and rationale 1271 for the IETF working group's major decisions. 1273 The "Internet Printing Protocol/1.1: Model and Semantics" document 1274 describes a simplified model with abstract objects, their attributes, 1275 and their operations that are independent of encoding and transport. 1276 It introduces a Printer and a Job object. The Job object optionally 1277 supports multiple documents per Job. It also addresses security, 1278 internationalization, and directory issues. 1280 The "Internet Printing Protocol/1.1: Encoding and Transport" document 1281 is a formal mapping of the abstract operations and attributes defined 1282 in the model document onto HTTP/1.1 [RFC2616]. It defines the 1283 encoding rules for a new Internet MIME media type called 1284 "application/ipp". This document also defines the rules for 1285 transporting over HTTP a message body whose Content-Type is 1286 "application/ipp". This document defines the 'ippget' scheme for 1287 identifying IPP printers and jobs. 1289 The "Internet Printing Protocol/1.1: Implementer's Guide" document 1290 gives insight and advice to implementers of IPP clients and IPP 1291 objects. It is intended to help them understand IPP/1.1 and some of 1292 the considerations that may assist them in the design of their client 1293 and/or IPP object implementations. For example, a typical order of 1294 processing requests is given, including error checking. Motivation 1295 for some of the specification decisions is also included. 1297 The "Mapping between LPD and IPP Protocols" document gives some 1298 advice to implementers of gateways between IPP and LPD (Line Printer 1299 Daemon) implementations. 1301 The "IPP Event Notification Specification" document defines an 1302 extension to IPP/1.0 [RFC2566, RFC2565] and IPP/1.1 [RFC2911, 1303 RFC2910]. This extension allows a client to subscribe to printing 1304 related Events and defines the semantics for delivering asynchronous 1305 Event Notifications to the specified Notification Recipient via a 1306 specified Delivery Method (i.e., protocols) defined in (separate) 1307 Delivery Method documents. 1309 18 Full Copyright Statement 1311 Copyright (C) The Internet Society (2001). All Rights Reserved. 1313 This document and translations of it may be copied and furnished to 1314 others, and derivative works that comment on or otherwise explain it 1315 or assist in its implementation may be prepared, copied, published 1316 and distributed, in whole or in part, without restriction of any 1317 kind, provided that the above copyright notice and this paragraph are 1318 included on all such copies and derivative works. However, this 1319 document itself may not be modified in any way, such as by removing 1320 the copyright notice or references to the Internet Society or other 1321 Internet organizations, except as needed for the purpose of 1322 developing Internet standards in which case the procedures for 1323 copyrights defined in the Internet Standards process must be 1324 followed, or as required to translate it into languages other than 1325 English. 1327 The limited permissions granted above are perpetual and will not be 1328 revoked by the Internet Society or its successors or assigns. 1330 This document and the information contained herein is provided on an 1331 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1332 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1333 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1334 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1335 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1337 Acknowledgement 1339 Funding for the RFC Editor function is currently provided by the 1340 Internet Society.