idnits 2.17.1 draft-ietf-ipp-notify-get-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: ---------------------------------------------------------------------------- ** 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 ([RFC2568], [RFC2616], [RFC2569], [RFC2910], [RFC2911], [RFC2567]), 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 343 has weird spacing: '...me name ipp...' == Line 364 has weird spacing: '...ication and a...' == Line 1214 has weird spacing: '...ent who s th...' == Line 1332 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 (February 28, 2001) is 8457 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 916, but not defined == Missing Reference: 'IANA-MIMEREG' is mentioned on line 925, but not defined == Missing Reference: 'US-ASCII' is mentioned on line 934, but not defined == Unused Reference: 'RFC2026' is defined on line 1237, 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) ** 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: 17 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 February 28, 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 The notification extension document [ipp-ntfy] defines operations 36 that a client can perform in order to create Subscription Objects in 37 a Printer and carry out other operations on them. A Subscription 38 Object represents a Subscription abstraction. The Subscription Object 39 specifies that when one of the specified Events occurs, the Printer 40 sends an asynchronous Event Notification to the specified 41 Notification Recipient via the specified Delivery Method (i.e., 42 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 'ippget' delivery method. 48 The 'ippget' Delivery Method is a 'pull and push' Delivery Method. 49 That is, the Printer saves Event Notification for a period of time 50 and expects the Notification Recipient to fetch the Event 51 Notifications (the pull part). The Printer continues to send Event 52 Notifications to the Notification Recipient as Events occur (the push 53 part) if the client has selected the option to wait for additional 54 Event Notifications. 56 When a Printer supports this Delivery Method, it holds each Event 57 Notification for an amount of time, called the Event Notification 58 Lease Time. 60 When a Notification Recipient wants to receive Event Notifications, 61 it performs an IPP operation called 'Get-Notifications', which this 62 document defines. This operation causes the Printer to return all 63 Event Notifications held for the Notification Recipient. If the 64 Notification Recipient has selected the option to wait for additional 65 Event Notifications, the Printer continues sending Event 66 Notifications to the Notification Recipient as additional Events 67 occur. 69 The basic set of IPP documents includes: 71 Design Goals for an Internet Printing Protocol [RFC2567] 72 Rationale for the Structure and Model and Protocol for the Internet 73 Printing Protocol [RFC2568] 74 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 75 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 76 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 77 Mapping between LPD and IPP Protocols [RFC2569] 78 Internet Printing Protocol/1.0 & 1.1: IPP Event Notification 79 Specification [ipp-ntfy] 81 The "Design Goals for an Internet Printing Protocol" document takes a 82 broad look at distributed printing functionality, and it enumerates 83 real-life scenarios that help to clarify the features that need to be 84 included in a printing protocol for the Internet. It identifies 85 requirements for three types of users: end users, operators, and 86 administrators. It calls out a subset of end user requirements that 87 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 88 been added to IPP/1.1. 90 The "Rationale for the Structure and Model and Protocol for the 91 Internet Printing Protocol" document describes IPP from a high level 92 view, defines a roadmap for the various documents that form the suite 93 of IPP specification documents, and gives background and rationale 94 for the IETF working group's major decisions. 96 The "Internet Printing Protocol/1.1: Model and Semantics" document 97 describes a simplified model with abstract objects, their attributes, 98 and their operations that are independent of encoding and transport. 99 It introduces a Printer and a Job object. The Job object optionally 100 supports multiple documents per Job. It also addresses security, 101 internationalization, and directory issues. 103 The "Internet Printing Protocol/1.1: Encoding and Transport" document 104 is a formal mapping of the abstract operations and attributes defined 105 in the model document onto HTTP/1.1 [RFC2616]. It defines the 106 encoding rules for a new Internet MIME media type called 107 "application/ipp". This document also defines the rules for 108 transporting over HTTP a message body whose Content-Type is 109 "application/ipp". This document defines a new scheme named 'ippget' 110 for identifying IPP printers and jobs. 112 The "Internet Printing Protocol/1.1: Implementer's Guide" document 113 gives insight and advice to implementers of IPP clients and IPP 114 objects. It is intended to help them understand IPP/1.1 and some of 115 the considerations that may assist them in the design of their client 116 and/or IPP object implementations. For example, a typical order of 117 processing requests is given, including error checking. Motivation 118 for some of the specification decisions is also included. 120 The "Mapping between LPD and IPP Protocols" document gives some 121 advice to implementers of gateways between IPP and LPD (Line Printer 122 Daemon) implementations. 124 The "Event Notification Specification" document describes an 125 extension to the IPP/1.0, IPP/1.1, and future versions. This 126 extension allows a client to subscribe to printing related Events. 127 Subscriptions are modeled as Subscription Objects. The Subscription 128 Object specifies that when one of the specified Event occurs, the 129 Printer sends an asynchronous Event Notification to the specified 130 Notification Recipient via the specified Delivery Method (i.e., 131 protocol). A client associates Subscription Objects with a 132 particular Job by performing the Create-Job-Subscriptions operation 133 or by submitting a Job with subscription information. A client 134 associates Subscription Objects with the Printer by performing a 135 Create-Printer-Subscriptions operation. Four other operations are 136 defined for Subscription Objects: Get-Subscriptions-Attributes, Get- 137 Subscriptions, Renew-Subscription, and Cancel-Subscription. 139 Table of Contents 141 1 Introduction....................................................6 143 2 Terminology.....................................................6 145 3 Model and Operation.............................................7 147 4 General Information.............................................8 149 5 Get-Notifications operation....................................10 150 5.1 Get-Notifications Request...................................12 151 5.2 Get-Notifications Response..................................13 153 6 Subscription Template Attributes...............................18 154 6.1 Subscription Template Attribute Conformance.................18 155 6.2 Additional Information about Subscription Template Attributes18 156 6.2.1 notify-recipient-uri (uri)................................18 157 6.3 Subscription Description Attribute Conformance..............19 159 7 Additional Printer Description Attributes......................19 160 7.1 Printer Description Attribute Conformance...................19 161 7.2 New Values for Existing Printer Description Attributes......19 162 7.2.1 notify-schemes-supported (1setOf uriScheme)...............19 163 7.2.2 operations-supported (1setOf type2 enum)..................19 164 7.3 begin-to-expire-time-interval (integer(0:MAX))..............20 166 8 New Status Codes...............................................20 167 8.1 redirection-other-site (0x300)..............................21 169 9 The IPPGET URL Scheme..........................................21 170 9.1 The IPPGET URL Scheme Applicability and Intended Usage......21 171 9.2 The IPPGET URL Scheme Associated Port.......................21 172 9.3 The IPPGET URL Scheme Associated MIME Type..................21 173 9.4 The IPPGET URL Scheme Character Encoding....................22 174 9.5 The IPPGET URL Scheme Syntax in ABNF........................22 175 9.5.1 IPPGET URL Examples.......................................23 176 9.5.2 IPPGET URL Comparisons....................................23 178 10 Encoding.......................................................24 180 11 Conformance Requirements.......................................24 181 11.1 Conformance for IPP Printers................................24 182 11.2 Conformance for IPP Clients.................................25 184 12 IANA Considerations............................................25 185 12.1 Operation Registrations.....................................26 186 12.2 Additional values of existing attributes....................26 187 12.2.1 Additional values for the "notify-schemes-supported" Printer 188 attribute..............................................26 189 12.2.2 Additional values for the "operations-supported" Printer 190 attribute..............................................26 191 12.3 Attribute Registrations.....................................27 192 12.4 Status code Registrations...................................27 194 13 Internationalization Considerations............................27 196 14 Security Considerations........................................27 198 15 References.....................................................28 200 16 Authors' Addresses.............................................29 202 17 Full Copyright Statement.......................................30 204 Table of Tables 206 Table 1 - Information about the Delivery Method....................9 208 Table 2 - Attributes in Event Notification Content................16 210 Table 3 - Additional Attributes in Event Notification Content for Job 212 Events ........................................................17 214 Table 4 - Combinations of Events and Subscribed Events for "job- 216 impressions-completed" ........................................17 218 Table 5 - Additional Attributes in Event Notification Content for 220 Printer Events ................................................18 222 Table 6 - Operation-id assignments................................20 224 Table 7 - The "event-notification-attributes-tag" value...........24 226 1 Introduction 228 The notification extension document [ipp-ntfy] defines operations 229 that a client can perform in order to create Subscription Objects in 230 a Printer and carry out other operations on them. A Subscription 231 Object represents a Subscription abstraction. The Subscription Object 232 specifies that when one of the specified Events occurs, the Printer 233 sends an asynchronous Event Notification to the specified 234 Notification Recipient via the specified Delivery Method (i.e., 235 protocol). 237 The notification extension document [ipp-ntfy] specifies that each 238 Delivery Method is defined in another document. This document is one 239 such document, and it specifies the 'ippget' delivery method. 241 The 'ippget' Delivery Method is a 'pull and push' Delivery Method. 242 That is, the Printer saves Event Notification for a period of time 243 and expects the Notification Recipient to fetch the Event 244 Notifications (the pull part). The Printer continues to send Event 245 Notifications to the Notification Recipient as Events occur (the push 246 part) if the client has selected the option to wait for additional 247 Event Notifications. 249 When a Printer supports this Delivery Method, it holds each Event 250 Notification for an amount of time, called the Event Notification 251 Lease Time. 253 When a Notification Recipient wants to receive Event Notifications, 254 it performs an IPP operation called 'Get-Notifications', which this 255 document defines. This operation causes the Printer to return all 256 Event Notifications held for the Notification Recipient. If the 257 Notification Recipient has selected the option to wait for additional 258 Event Notifications, the Printer the Printer continues to send Event 259 Notifications to the Notification Recipient as Events occur. 261 2 Terminology 263 This section defines the following terms that are used throughout 264 this document: 266 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 267 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 268 conformance to this specification. These terms are defined in 269 [RFC2911 section 13.1 on conformance terminology, most of which is 270 taken from RFC 2119 [RFC2119]. 272 Event Notification Lease: The lease that is associated with an Event 273 Notification. When the lease expires, the Printer discards the 274 associated Event Notification. 276 Event Notification Lease Time: The expiration time assigned to a 277 lease that is associated with an Event Notification. 279 Event Notification Attributes Group: The attributes group in a 280 response that contains attributes that are part of an Event 281 Notification. 283 For other capitalized terms that appear in this document, see [ipp- 284 ntfy]. 286 3 Model and Operation 288 In a Subscription Creation Operation, when the value of the "notify- 289 recipient-uri" attribute has the scheme 'ippget', the client is 290 requesting that the Printer use the 'ippget' Delivery Method for the 291 Event Notifications associated with the new Subscription Object. The 292 client SHOULD choose a value for the address part of the "notify- 293 recipient-uri" attribute that uniquely identifies the Notification 294 Recipient. 296 When an Event occurs, the Printer MUST generate an Event Notification 297 and MUST assign it the Event Notification Lease Time. The Printer 298 MUST hold an Event Notification for its assigned Event Notification 299 Lease Time. The Printer MUST assign the same Event Notification 300 Lease Time to each Event Notification. 302 When a Notification Recipient wants to receive Event Notifications, 303 it performs the Get-Notifications operation, which causes the Printer 304 to return all un-expired Event Notifications held for the 305 Notification Recipient. If the Notification Recipient has selected 306 the option to wait for additional Event Notifications, the response 307 to the Get-Notifications request continues indefinitely as the 308 Printer continues to send Event Notifications in the response as 309 Events occur. For the Get-Notification operation, the Printer sends 310 only those Event Notifications that are generated from Subscription 311 Objects whose "notify-recipient-uri" attribute value equals the value 312 of the "notify-recipient-uri" Operation Attribute in the Get- 313 Notifications operation. 315 If a Notification Recipient performs the Get-Notifications operation 316 twice in quick succession, it will receive nearly the same Event 317 Notification both times because most of the Event Notifications are 318 those that the Printer saves for a few seconds after the Event 319 occurs. There are two possible differences. Some old Event 320 Notifications may not be present in the second response because their 321 Event Notification Leases have expired. Some new Event Notifications 322 may be present in the second response but not the first response. 324 When the Notification Recipient requests Event Notifications for per- 325 Job Subscription Objects, the Notification Recipient typically 326 performs the Get-Notifications operation within a second of 327 performing the Subscription Creation operation. Because the Printer 328 is likely to save Event Notifications for several seconds, the 329 Notification Recipient is unlikely to miss any Event Notifications 330 that occur between the Subscription Creation and the Get- 331 Notifications operation. 333 4 General Information 335 If a Printer supports this Delivery Method, the following are its 336 characteristics. 338 Table 1 - Information about the Delivery Method 340 Document Method Conformance Delivery Method Realization 341 Requirement 343 1. What is the URL scheme name ippget 344 for the Delivery Method? 346 2. Is the Delivery Method RECOMMENDED 347 REQUIRED, RECOMMENDED or 348 OPTIONAL for an IPP Printer 349 to support? 351 3. What transport and delivery 352 protocols does the Printer 353 use to deliver the Event 354 Notification Content, i.e., 355 what is the entire network IPP with one new operation. 356 stack? 358 4. Can several Event Yes. 359 Notifications be combined 360 into a Compound Event 361 Notification? 363 5. Is the Delivery Method This Delivery Method is a pull 364 initiated by the Notification and a push. 365 Recipient (pull), or by the 366 Printer (push)? 368 6. Is the Event Notification Machine Consumable 369 content Machine Consumable or 370 Human Consumable? 372 7. What section in this document Section 5 373 answers the following 374 question? For a Machine 375 Consumable Event 376 Notification, what is the 377 representation and encoding 378 of values defined in section 379 9.1 of [ipp-ntfy] and the 380 conformance requirements 381 thereof? For a Human 382 Consumable Event 383 Notification, what is the 384 representation and encoding 385 of pieces of information 386 defined in section 9.2 of 387 [ipp-ntfy] and the 388 conformance requirements 389 thereof? 391 8. What are the latency and Same as IPP and the underlying 392 reliability of the transport HTTP transport 393 and delivery protocol? 395 9. What are the security aspects Same as IPP and the underlying 396 of the transport and delivery HTTP transport 397 protocol, e.g., how it is 398 handled in firewalls? 400 10. What are the content length None 401 restrictions? 403 11. What are the additional None 404 values or pieces of 405 information that a Printer 406 sends in an Event 407 Notification content and the 408 conformance requirements 409 thereof? 411 12. What are the additional None 412 Subscription Template and/or 413 Subscription Description 414 attributes and the 415 conformance requirements 416 thereof? 418 13. What are the additional None 419 Printer Description 420 attributes and the 421 conformance requirements 422 thereof? 424 5 Get-Notifications operation 426 This operation causes the Printer to return all Event Notifications 427 held for the Notification Recipient. 429 A Printer MUST support this operation. 431 When a Printer performs this operation, it MUST return all and only 432 those Event Notifications: 434 1. Whose associated Subscription Object's "notify-recipient-uri" 435 attribute equals the "notify-recipient-uri" Operation attribute 436 AND 438 2. Whose associated Subscription Object's "notify-recipient-uri" 439 attribute has a scheme value of 'ippget' AND 441 3. Whose Event Notification Lease Time has not yet expired AND 443 4. Where the Notification Recipient is the owner of or has read- 444 access rights to the associated Subscription Object. 446 The Printer MUST respond to this operation immediately with whatever 447 Event Notifications it currently holds. If the Notification Recipient 448 has selected the option to wait for additional Event Notifications, 449 the Printer MUST continue to send Event Notifications as they occur 450 until all of the associated Subscription Objects are cancelled. A 451 Subscription Object is cancelled either via the Cancel-Subscription 452 operation or by the Printer (e.g. the Subscription Object is 453 cancelled when the associated Job completes). 455 Note, the Printer terminates the operation in the same way that it 456 normally terminates IPP operations. For example, if the Printer is 457 sending chunked data, it can send a 0 length chunk to denote the end 458 of the operation or it can close the connection. If the Notification 459 Recipient wishes to terminate the Get-Notifications operation, it can 460 close the connection. 462 The Printer MUST accept the request in any state (see [RFC2911] 463 "printer-state" and "printer-state-reasons" attributes) and MUST 464 remain in the same state with the same "printer-state-reasons" 465 values. 467 Access Rights: If the policy of the Printer is to allow all users to 468 access all Event Notifications, then the Printer MUST accept this 469 operation from any user. Otherwise, the authenticated user (see 470 [RFC2911] section 8.3) performing this operation MUST either be the 471 owner of each Subscription Object identified by the "notify- 472 recipient-uri" Operation attribute (as determined during a 473 Subscription Creation Operation) or an operator or administrator of 474 the Printer (see [RFC2911] Sections 1 and 8.5). Otherwise, the IPP 475 object MUST reject the operation and return: 'client-error- 476 forbidden', 'client-error-not-authenticated', or 'client-error-not- 477 authorized' status code as appropriate. 479 5.1 Get-Notifications Request 481 The following groups of attributes are part of the Get-Notifications 482 Request: 484 Group 1: Operation Attributes 486 Natural Language and Character Set: 487 The "attributes-charset" and "attributes-natural-language" 488 attributes as described in [RFC2911] section 3.1.4.1. 490 Target: 491 The "printer-uri" (uri) operation attribute which is the target 492 for this operation as described in [RFC2911] section 3.1.5. 494 Requesting User Name: 495 The "requesting-user-name" (name(MAX)) attribute SHOULD be 496 supplied by the client as described in [RFC2911] section 8.3. 498 "notify-recipient-uri" (url): 499 The client MUST supply this attribute. The Printer object MUST 500 support this attribute. The Printer matches the value of this 501 attribute (byte for byte with no case conversion) against the 502 value of the "notify-recipient-uri" in each Subscription Object 503 in the Printer. If there are no matches, the IPP Printer MUST 504 return the 'client-error-not-found' status code. For each 505 matched Subscription Object, the IPP Printer MUST return all 506 unexpired Event Notifications associated with it. The Printer 507 MUST send additional Event Notifications as Events occur if and 508 only if the value of the "notify-no-wait" attribute is 'false' 509 or not supplied by the client (see the next attribute below). 511 Note: this attribute allows a subscribing client to pick URLs 512 that are unique, e.g. the client's own URL or a friend's URL, 513 which in both cases is likely the URL of the person's host. An 514 application could make a URL unique for each application. 516 "notify-no-wait" (boolean): 517 The client MAY supply this attribute. The Printer object MUST 518 support this attribute. If the value of this attribute is 519 'false', the Printer MUST send all un-expired Event 520 Notifications (as defined in the previous attribute) and it 521 MUST continue to send responses for as long as the Subscription 522 Objects associated with the specified "notify-recipient-uri" 523 continue to exist. If the value of this attribute is 'true', 524 the Printer MUST send all un-expired Event Notifications (as 525 defined in the previous attribute) and the Printer MUST 526 conclude the operation without waiting for any additional 527 Events to occur. If the client doesn't supply this attribute, 528 the Printer MUST behave as if the client had supplied this 529 attribute with the value of 'false'. 531 5.2 Get-Notifications Response 533 The following groups of attributes are part of the Get-Notifications 534 Response: 536 Group 1: Operation Attributes 538 Status Message: 539 In addition to the REQUIRED status code returned in every 540 response, the response OPTIONALLY includes a "status-message" 541 (text(255)) and/or a "detailed-status-message" (text(MAX)) 542 operation attribute as described in [RFC2911] sections 13 and 543 3.1.6. 545 The Printer can return any status codes defined in [RFC2911]. 546 If the status code is not 'successful-', the Printer MUST NOT 547 return any Event Notification Attribute groups. The following 548 is a description of the important status codes: 550 successful-ok: the response contains all Event Notification 551 associated with the specified "notify-recipient-uri". If 552 the specified Subscription Objects have no associated 553 Event Notification, the response MUST contain zero Event 554 Notifications. 555 client-error-not-found: The Printer has no Subscription 556 Object's whose "notify-recipient-uri" attribute equals 557 the "notify-recipient-uri" Operation attribute. 558 server-error-busy: The Printer is too busy to accept this 559 operation. If the "suggested-ask-again-time-interval" 560 operation attribute is present in the Operation 561 Attributes of the response, then the Notification 562 Recipient SHOULD wait for the number of seconds specified 563 by the "suggested-ask-again-time-interval" attribute 564 before performing this operation again. If the 565 "suggested-ask-again-time-interval" Operation Attribute 566 is not present, the Notification Recipient should use the 567 normal network back-off algorithms for determining when 568 to perform this operation again. 569 redirection-other-site: The Printer does not handle this 570 operation and requests the Notification Recipient to 571 perform the operation with the uri specified by the 572 "notify-ippget-redirect" Operation Attribute in the 573 response. 575 Natural Language and Character Set: 576 The "attributes-charset" and "attributes-natural-language" 577 attributes as described in [RFC2911] section 3.1.4.2. 579 The Printer MUST use the values of "notify-charset" and 580 "notify-natural-language", respectively, from one Subscription 581 Object associated with the Event Notifications in this 582 response. 584 Normally, there is only one matched Subscription Object, or the 585 value of the "notify-charset" and "notify-natural-language" 586 attributes is the same in all Subscription Objects. If not, the 587 Printer MUST pick one Subscription Object from which to obtain 588 the value of these attributes. The algorithm for picking the 589 Subscription Object is implementation dependent. The choice of 590 natural language is not critical because 'text' and 'name' 591 values can override the "attributes-natural-language" Operation 592 attribute. The Printer's choice of charset is critical because 593 a bad choice may leave it unable to send some 'text' and 'name' 594 values accurately. 596 "printer-up-time" (integer(0:MAX)): 597 The value of this attribute is the Printer's "printer-up-time" 598 attribute at the time the Printer sends this response. Because 599 each Event Notification also contains the value of this 600 attribute when the event occurred, the value of this attribute 601 lets a Notification Recipient know when each Event Notification 602 occurred relative to the time of this response. 604 "suggested-ask-again-time-interval" (integer(0:MAX)): 605 The value of this attribute is the number of seconds that the 606 Notification Recipient SHOULD wait before trying this operation 607 again when 608 a) the Printer returns the 'server-error-busy' status code 609 OR 610 b) the Printer returns the 'successful-ok' status code and 611 the client supplied the "notify-no-wait" attribute with a 612 value of 'true'. 613 This value is intended to help the client be a good network 614 citizen. 616 "notify-ippget-redirect" (uri): 617 The value of this attribute is uri that the Notification 618 Recipient MUST use for the Get-Notifications operation. This 619 attribute is present in the Operation Attributes if and only if 620 the status code has the value 'redirection-other-site'. 622 Group 2: Unsupported Attributes 624 See [RFC2911] section 3.1.7 for details on returning 625 Unsupported Attributes. 627 If the "subscription-ids" attribute contained subscription-ids 628 that do not exist, the Printer returns them in this group as 629 value of the "subscription-ids" attribute. 631 Group 3 through N: Event Notification Attributes 633 The Printer responds with one Event Notification Attributes 634 Group per matched Event Notification. The initial matched Event 635 Notifications are all un-expired Event Notification associated 636 with the matched Subscription Objects. If the Notification 637 Recipient has selected the option to wait for additional Event 638 Notifications, the Printer the subsequent Event Notifications 639 in the response are Event Notifications associated with the 640 matched Subscription Objects as the corresponding Event occurs. 642 From the Notification Recipient's view, the response appears as 643 an initial burst of data, which includes the Operation 644 Attributes Group and one Event Notification Attributes Groups 645 per Event Notification that the Printer is holding. After the 646 initial burst of data, if the Notification Recipient has 647 selected the option to wait for additional Event Notifications, 648 the Notification Recipient receives occasional Event 649 Notification Attribute Groups. Proxy servers may delay some 650 Event Notifications or cause time-outs to occur. The client 651 MUST be prepared to perform the Get-Notifications operation 652 again when time-outs occur. 654 Each Event Notification Group MUST start with an 'event- 655 notification-attributes-tag' (see the section "Encodings of 656 Additional Attribute Tags" in [ipp-ntfy]). 658 Each attribute is encoded using the IPP rules for encoding 659 attributes [RFC2910] and may be encoded in any order. Note: 660 the Get-Jobs response in [RFC2911] acts as a model for encoding 661 multiple groups of attributes. 663 Each Event Notification Group MUST contain all of attributes 664 specified in section 9.1 ("Content of Machine Consumable Event 665 Notifications") of [ipp-ntfy] with exceptions denoted by 666 asterisks in the tables below. 668 The tables below are copies of the tables in section 9.1 669 ("Content of Machine Consumable Event Notifications") of [ipp- 670 ntfy] except that each cell in the "Sends" column is a "MUST". 672 For an Event Notification for all Events, the Printer includes 673 the attributes shown in Table 2. 675 Table 2 - Attributes in Event Notification Content 677 Source Value Sends Source Object 679 notify-subscription-id (integer(1:MAX)) MUST Subscription 681 notify-printer-uri (uri) MUST Subscription 683 notify-subscribed-event (type2 keyword) MUST Event 684 Notification 686 printer-up-time (integer(MIN:MAX)) MUST Printer 688 printer-current-time (dateTime) * MUST * Printer 690 notify-sequence-number (integer (0:MAX)) MUST Subscription 692 notify-charset (charset) MUST Subscription 694 notify-natural-language (naturalLanguage) MUST Subscription 696 notify-user-data (octetString(63)) ** MUST Subscription 698 notify-text (text) MUST Event 699 Notification 701 attributes from the "notify-attributes" MUST Printer 702 attribute *** 704 attributes from the "notify-attributes" MUST Job 705 attribute *** 707 attributes from the "notify-attributes" MUST Subscription 708 attribute *** 710 * The Printer MUST send the "printer-current-time" attribute if 711 and only if it supports the "printer-current-time" attribute on 712 the Printer object. 714 ** If the associated Subscription Object does not contain a 715 "notify-user-data" attribute, the Printer MUST send an octet- 716 string of length 0. 718 *** If the "notify-attributes" attribute is present on the 719 Subscription Object, the Printer MUST send all attributes 720 specified by the "notify-attributes" attribute. Note: if the 721 Printer doesn't support the "notify-attributes" attribute, it 722 is not present on the associated Subscription Object. 724 For Event Notifications for Job Events, the Printer includes 725 the additional attributes shown in Table 3. 727 Table 3 - Additional Attributes in Event Notification Content for 728 Job Events 730 Source Value Sends Source 731 Object 733 job-id (integer(1:MAX)) MUST Job 735 job-state (type1 enum) MUST Job 737 job-state-reasons (1setOf type2 keyword) MUST Job 739 job-impressions-completed (integer(0:MAX)) * MUST Job 741 * The Printer MUST send the "job-impressions-completed" 742 attribute in an Event Notification only for the combinations of 743 Events and Subscribed Events shown in Table 4. 745 Table 4 - Combinations of Events and Subscribed Events for "job- 746 impressions-completed" 748 Job Event Subscribed Job Event 750 'job-progress' 'job-progress' 752 'job-completed' 'job-completed' 754 'job-completed' 'job-state-changed' 756 For Event Notification for Printer Events, the Printer includes 757 the additional attributes shown in Table 5. 759 Table 5 - Additional Attributes in Event Notification Content for 760 Printer Events 762 Source Value Sends Source 763 Object 765 printer-state (type1 enum) MUST Printer 767 printer-state-reasons (1setOf type2 keyword) MUST Printer 769 printer-is-accepting-jobs (boolean) MUST Printer 771 6 Subscription Template Attributes 773 This section defines the Subscription object conformance requirements 774 for Printers. 776 6.1 Subscription Template Attribute Conformance 778 The 'ippget' Delivery Method has the same conformance requirements 779 for Subscription Template attributes as defined in [ipp-ntfy]. The 780 'ippget' Delivery Method does not define any addition Subscription 781 Template attributes. 783 6.2 Additional Information about Subscription Template Attributes 785 This section defines additional information about Subscription 786 Template attributes defined in [ipp-ntfy]. 788 6.2.1 notify-recipient-uri (uri) 790 This section describes the syntax of the value of this attribute for 791 the 'ippget' Delivery Method. The syntax for values of this 792 attribute for other Delivery Method is defined in other Delivery 793 Method Documents. 795 In order to support the 'ippget' Delivery Method and Protocol, the 796 Printer MUST support the following syntax: 798 The 'ippget://' URI scheme. The remainder of the URI indicates 799 something unique about the Notification Recipient, such as its host 800 name or host address (and optional path) that the Printer uses to 801 match the "notify-recipient-uri" Operation attribute supplied in 802 the Get-Notifications request. 804 6.3 Subscription Description Attribute Conformance 806 The 'ippget' Delivery Method has the same conformance requirements 807 for Subscription Description attributes as defined in [ipp-ntfy]. 808 The 'ippget' Delivery Method does not define any addition 809 Subscription Description attributes. 811 7 Additional Printer Description Attributes 813 This section defines the Printer Description Attributes conformance 814 requirements for Printers. 816 7.1 Printer Description Attribute Conformance 818 The 'ippget' Delivery Method has the same conformance requirements 819 for Printer Description attributes as defined in [ipp-ntfy]. The 820 'ippget' Delivery Method does not define any addition Printer 821 Description attributes. 823 7.2 New Values for Existing Printer Description Attributes 825 This section defines additional values for existing Printer 826 Description attributes. 828 7.2.1 notify-schemes-supported (1setOf uriScheme) 830 The following value for the "notify-schemes-supported" attribute is 831 added in order to support the new Delivery Method defined in this 832 document: 834 'ippget' - The IPP Notification Delivery Method defined in this 835 document. 837 7.2.2 operations-supported (1setOf type2 enum) 839 Table 6 lists the "operation-id" value defined in order to support 840 the new Get-Notifications operation defined in this document. 842 Table 6 - Operation-id assignments 844 Value Operation Name 846 0x001C Get-Notifications 848 7.3 begin-to-expire-time-interval (integer(0:MAX)) 850 This Printer Description attribute specifies the number of seconds 851 that a Printer keeps an Event Notification that is associated with 852 the 'ippget' Delivery Method. 854 The Printer MUST support this attribute if it supports the 'ippget' 855 Delivery Method. 857 The value of this attribute is the minimum number of seconds that 858 MUST elapse between the time the Printer creates an Event 859 Notification object for the 'ippget' Delivery Method and the time the 860 Printer discards the same Event Notification. 862 For example, assume the following: 864 1.a client performs a Job Creation operation that creates a 865 Subscription Object associated with this Delivery Method, AND 867 2.an Event associated with the new Job occurs immediately after 868 the Subscription Object is created, AND 870 3.the same client or some other client performs a Get- 871 Notifications operation N seconds after the Job Creation 872 operation. 874 Then, if N is less than the value of this attribute, the client 875 performing the Get-Notifications operations can expect not miss any 876 Event-Notifications, barring some unforeseen lack of memory space in 877 the Printer. 879 8 New Status Codes 881 The following status codes are defined as extensions for this 882 Delivery Method and are returned as the status code of the Get- 883 Notifications operation. 885 8.1 redirection-other-site (0x300) 887 This status code means that the Printer doesn't perform that Get- 888 Notifications operation and that the "notify-ippget-redirect" 889 Operation Attribute in the response contains the uri that the 890 Notification Recipient MUST use for performing the Get-Notifications 891 operation. 893 9 The IPPGET URL Scheme 895 This section defines the 'ippget' URL and the conformance 896 requirements for using it. 898 9.1 The IPPGET URL Scheme Applicability and Intended Usage 900 This section is intended for use in registering the 'ippget' URL 901 scheme with IANA and fully conforms to the requirements in [RFC2717]. 902 This document defines the 'ippget'" URL (Uniform Resource Locator) 903 scheme for specifying a unique identifier for an IPP Client which 904 implements the IPP Get-Notifications operation specified in this 905 document (see section 5). 907 The intended usage of the 'ippget' URL scheme is COMMON. 909 9.2 The IPPGET URL Scheme Associated Port 911 None. 913 An 'ippget' URL behaves as a unique identifier for IPP Clients and is 914 NOT used to initiate any over-the-wire protocol associations. 916 See: IANA Port Numbers Registry [IANA-PORTREG]. 918 9.3 The IPPGET URL Scheme Associated MIME Type 920 All IPP Get-Notifications operations (requests and responses) MUST be 921 conveyed in an 'application/ipp' MIME media type as registered in 922 [IANA-MIMEREG]. An 'ippget' URL MUST uniquely identify an IPP Client 923 that support this 'application/ipp' MIME media type. 925 See: IANA MIME Media Types Registry [IANA-MIMEREG]. 927 9.4 The IPPGET URL Scheme Character Encoding 929 The 'ippget' URL scheme defined in this document is based on the ABNF 930 for the URI Generic Syntax [RFC2396] and further updated by [RFC2732] 931 and [RFC2373] (for IPv6 addresses in URLs). The 'ippget' URL scheme 932 is case-insensitive in the host name or host address part; however, 933 the path part is case-sensitive, as in [RFC2396]. Code points 934 outside [US-ASCII] MUST be hex escaped by the mechanism specified in 935 [RFC2396]. 937 9.5 The IPPGET URL Scheme Syntax in ABNF 939 This document is intended for use in registering the 'ippget' URL 940 scheme with IANA and fully conforms to the requirements in [RFC2717]. 941 This document defines the 'ippget' URL (Uniform Resource Locator) 942 scheme for specifying a unique identifier for an IPP Client which 943 implements IPP 'Get-Notifications' operation specified in this 944 document. 946 The intended usage of the 'ippget' URL scheme is COMMON. 948 The IPP protocol places a limit of 1023 octets (NOT characters) on 949 the length of a URI (see section 4.1.5 'uri' in [RFC2911]). An IPP 950 Printer MUST return the 'client-error-request-value-too-long' status 951 code (see section 13.1.4.10 in [RFC2911]) when a URI received in a 952 request is too long. 954 Note: IPP Clients and IPP Printers ought to be cautious about 955 depending on URI lengths above 255 bytes, because some older client 956 or proxy implementations might not properly support these lengths. 958 An 'ippget' URL MUST be represented in absolute form. Absolute URLs 959 always begin with a scheme name followed by a colon. For definitive 960 information on URL syntax and semantics, see "Uniform Resource 961 Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This 962 specification adopts the definitions of "authority", "abs_path", 963 "query", "reg_name", "server", "userinfo", and "hostport" from 964 [RFC2396], as updated by [RFC2732] and [RFC2373] (for IPv6 addresses 965 in URLs). 967 The 'ippget' URL scheme syntax in ABNF is as follows: 969 ippget_URL = "ippget:" "//" authority [ abs_path [ "?" query ]] 970 authority = server | reg_name 971 reg_name = 1*( unreserved | escaped | "$" | "," | 972 ";" | ":" | "@" | "&" | "=" | "+" ) 973 server = [ [ userinfo "@" ] hostport ] 974 userinfo = *( unreserved | escaped | 975 ";" | ":" | "&" | "=" | "+" | "$" | "," ) 977 hostport = host [ ":" port ] 978 abs_path = "/" path_segments 980 If the port is empty or not given, then no port is assumed. The 981 semantics are that the 'ippget' URL is a unique identifier for an IPP 982 Client that will retrieve IPP event notifications via the IPP Get- 983 Notifications operation. 985 Note: The use of IP addresses in URLs SHOULD be avoided whenever 986 possible (see [RFC1900]). 988 9.5.1 IPPGET URL Examples 990 The following are examples of valid 'ippget' URLs for IPP Clients 991 (using DNS host names): 993 ippget://abc.com 994 ippget://abc.com/listener 995 ippget://bob@abc.com/listener/1232 997 Note: The use of IP addresses in URLs SHOULD be avoided whenever 998 possible (see [RFC1900]). 1000 The choice of 'userinfo@hostport' versus the simpler 'hostport' 1001 production in an 'ippget' URL may be influenced by the intended 1002 usage. 1004 If a given IPP Client creates an IPP Subscription object for event 1005 notifications intended for retrieval by the same IPP Client, then the 1006 simple 'hostport' production may be most appropriate. 1008 On the other hand, if a given IPP Client creates an IPP Subscription 1009 object for event notifications intended for retrieval by a different 1010 IPP Client, then the 'userinfo@hostport' production (using, for 1011 example, the right-hand side of a 'mailto:' URL, see [RFC2368]) may 1012 be most appropriate. 1014 9.5.2 IPPGET URL Comparisons 1016 When comparing two 'ippget' URLs to decide if they match or not, an 1017 IPP Client or IPP Printer SHOULD use a case-sensitive octet-by-octet 1018 comparison of the entire URLs, with these exceptions: 1020 - Comparisons of host names MUST be case-insensitive; 1022 - Comparisons of scheme names MUST be case-insensitive; 1024 - An empty 'abs_path' is equivalent to an 'abs_path' of "/". 1026 Characters other than those in the "reserved" and "unsafe" sets (see 1027 [RFC2396] and [RFC2732]) are equivalent to their ""%" HEX HEX" 1028 encoding. 1030 For example, the following three URIs are equivalent: 1032 ippget://abc.com/~smith/listener 1034 ippget://ABC.com/%7Esmith/listener 1036 ippget://ABC.com:/%7esmith/listener 1038 10 Encoding 1040 This notification delivery method uses the IPP transport and encoding 1041 [RFC2910] for the Get-Notifications operation with one extension 1042 allocated in [ipp-ntfy]: 1044 Table 7 - The "event-notification-attributes-tag" value 1046 Tag Value (Hex) Meaning 1048 0x07 "event-notification-attributes-tag" 1050 11 Conformance Requirements 1052 11.1 Conformance for IPP Printers 1054 IPP Printers that conform to this specification: 1056 1. MUST meet the conformance requirements defined in [ipp-ntfy]; 1058 2. MUST support the Get-Notifications operation defined in section 1059 5; 1061 3. MUST support the Subscription object attributes as defined in 1062 section 6; 1064 4. MUST support the additional values for IPP/1.1 Printer 1065 Description attributes defined in section 7.2; 1067 5. MUST support the "begin-to-expire-time-interval" Printer 1068 Description attribute defined in section 7.3; 1070 6. MUST support the "redirection-other-site" status code defined 1071 8.1; 1073 7. SHOULD reject received 'ippget' URLs in 'application/ipp' 1074 request bodies (e.g., in the "notify-recipient-uri" attribute in 1075 a Get-Notifications request) that do not conform to the ABNF for 1076 'ippget' URLs specified in section 9.5 of this document; 1078 8. MUST listen for the IPP Get-Notifications operation requests on 1079 IANA-assigned well-known port 631, unless explicitly configured 1080 by system administrators or site policies; 1082 9. SHOULD NOT listen for IPP Get-Notifications operation requests 1083 on any other port, unless explicitly configured by system 1084 administrators or site policies. 1086 11.2 Conformance for IPP Clients 1088 IPP Clients that conform to this specification: 1090 1.MUST create unambiguously unique 'ippget' URLs in all cases; 1092 2.MUST send 'ippget' URLs (e.g., in the "notify-recipient-uri" 1093 attribute in a Get-Notifications request) that conform to the 1094 ABNF specified in section 9.5 of this document; 1096 3.MUST send IPP Get-Notifications operation requests via the port 1097 specified in the associated 'ipp' URL (if present) or otherwise 1098 via IANA assigned well-known port 631; 1100 4.MUST convert the associated 'ipp' URLs to their corresponding 1101 'http' URL forms according to the rules in section 5 "IPP URL 1102 Scheme" in [RFC2910]. 1104 Note: The use of ambiguous 'ippget' URLs is NOT an optional feature 1105 for IPP Clients; it is a non-conformant implementation error. 1107 12 IANA Considerations 1109 IANA is requested to register the 'ippget' URL scheme as defined in 1110 section 9 according to the procedures of [RFC2717]. 1112 The rest of this section contains the exact information for 1113 additional IPP entities for IANA to add to the IPP Registries 1114 according to the procedures defined in RFC 2911 [RFC2911] section 6. 1116 Note to RFC Editors: Replace RFC NNNN below with the RFC number 1117 for this document, so that it accurately reflects the content of 1118 the information for the IANA Registry. 1120 12.1 Operation Registrations 1122 The operations defined in this document will be published by IANA 1123 according to the procedures in RFC 2911 [RFC2911] section 6.4 with 1124 the following path: 1126 ftp.isi.edu/iana/assignments/ipp/operations/ 1128 The registry entry will contain the following information: 1130 Operations: Ref. Section: 1131 Get-Notifications operation RFC NNNN 5 1133 12.2 Additional values of existing attributes 1135 12.2.1 Additional values for the "notify-schemes-supported" Printer 1136 attribute 1138 The "notify-schemes-supported" 'uriScheme' attribute value defined in 1139 this document will be published by IANA according to the procedures 1140 in RFC 2911 [RFC2911] section 6.1 with the following path: 1142 ftp.isi.edu/iana/assignments/ipp/attribute-values/notify-schemes- 1143 supported/ 1145 The registry entry will contain the following information: 1147 Ref. Section: 1148 ippget RFC NNNN 7.2.1 1150 12.2.2 Additional values for the "operations-supported" Printer 1151 attribute 1153 The "operations-supported" type2 enum attribute value defined in this 1154 document will be published by IANA according to the procedures in RFC 1155 2911 [RFC2911] section 6.1 with the following path: 1157 ftp.isi.edu/iana/assignments/ipp/attribute-values/operations- 1158 supported/ 1160 The registry entry will contain the following information: 1162 Value Ref. Section: 1163 Get-Notifications 0x001C RFC NNNN 7.2.2 1165 12.3 Attribute Registrations 1167 The attributes defined in this document will be published by IANA 1168 according to the procedures in RFC 2911 [RFC2911] section 6.2 with 1169 the following path: 1171 ftp.isi.edu/iana/assignments/ipp/attributes/ 1173 The registry entry will contain the following information: 1175 Printer Description attributes: Ref. Section: 1176 begin-to-expire-time-interval (integer(0:MAX)) RFC NNNN 7.3 1178 12.4 Status code Registrations 1180 The status codes defined in this document will be published by IANA 1181 according to the procedures in RFC 2911 [RFC2911] section 6.6 with 1182 the following path: 1184 ftp.isi.edu/iana/assignments/ipp/status-codes/ 1186 The registry entry will contain the following information: 1188 Status codes: Ref. Section: 1189 redirection-other-site (0x300) RFC NNNN 8.1 1191 13 Internationalization Considerations 1193 The IPP Printer MUST localize the "notify-text" attribute as 1194 specified in section 14 of [ipp-ntfy]. 1196 In addition, when the client receives the Get-Notifications response, 1197 it is expected to localize the attributes that have the 'keyword' 1198 attribute syntax according to the charset and natural language 1199 requested in the Get-Notifications request. 1201 14 Security Considerations 1203 The IPP Model and Semantics document [RFC2911] discusses high-level 1204 security requirements (Client Authentication, Server Authentication 1205 and Operation Privacy). Client Authentication is the mechanism by 1206 which the client proves its identity to the server in a secure 1207 manner. Server Authentication is the mechanism by which the server 1208 proves its identity to the client in a secure manner. Operation 1209 Privacy is defined as a mechanism for protecting operations from 1210 eavesdropping. 1212 Unlike other Event Notification delivery methods in which the IPP 1213 Printer initiates the Event Notification, with the method defined in 1214 this document, the Notification Recipient is the client who s the 1215 Get-Notifications operation. Therefore, there is no chance of "spam" 1216 notifications with this method. Furthermore, such a client can close 1217 down the HTTP channel at any time, and so can avoid future unwanted 1218 Event Notifications at any time. 1220 15 References 1222 [ipp-iig] 1223 Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P., 1224 "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers- 1225 guide-v11-02.txt, work in progress, January 25, 2001 1227 [ipp-ntfy] 1228 R. Herriot, Hastings, T., Isaacson, S., Martin, J., deBry, R., 1229 Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP 1230 Event Notification Specification", , February 24, 2001. 1233 [RFC1900] 1234 B. Carpenter, Y. Rekhter. Renumbering Needs Work, RFC 1900, 1235 February 1996. 1237 [RFC2026] 1238 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 1239 2026, October 1996. 1241 [RFC2119] 1242 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1243 Levels", RFC 2119 , March 1997 1245 [RFC2368] 1246 P. Hoffman, L. Masinter, J. Zawinski. The "mailto" URL Scheme, RFC 1247 2368, July 1998. 1249 [RFC2373] 1250 R. Hinden, S. Deering. IP Version 6 Addressing Architecture, RFC 1251 2373, July 1998. 1253 [RFC2396] 1254 Berners-Lee, T. et al. Uniform Resource Identifiers (URI): Generic 1255 Syntax, RFC 2396, August 1998 1257 [RFC2567] 1258 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1259 2567, April 1999. 1261 [RFC2568] 1262 Zilles, S., "Rationale for the Structure and Model and Protocol for 1263 the Internet Printing Protocol", RFC 2568, April 1999. 1265 [RFC2569] 1266 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1267 LPD and IPP Protocols", RFC 2569, April 1999. 1269 [RFC2616] 1270 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1271 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1272 RFC 2616, June 1999. 1274 [RFC2717] 1275 R. Petke and I. King, "Registration Procedures for URL Scheme 1276 Names", RFC 2717, November 1999. 1278 [RFC2732] 1279 R. Hinden, B. Carpenter, L. Masinter. Format for Literal IPv6 1280 Addresses in URL's, RFC 2732, December 1999. 1282 [RFC2910] 1283 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1284 Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 1286 [RFC2911] 1287 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1288 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 1289 September 2000. 1291 16 Authors' Addresses 1293 Robert Herriot 1294 Xerox Corp. 1295 3400 Hill View Ave, Building 1 1296 Palo Alto, CA 94304 1298 Phone: 650-813-7696 1299 Fax: 650-813-6860 1300 e-mail: robert.herriot@pahv.xerox.com 1302 Carl Kugler 1303 IBM 1304 P.O. Box 1900 1305 Boulder, CO 80301-9191 1307 Phone: 1308 Fax: 1309 e-mail: kugler@us.ibm.com 1311 Harry Lewis 1312 IBM 1313 P.O. Box 1900 1314 Boulder, CO 80301-9191 1316 Phone: 303-924-5337 1317 FAX: 1318 e-mail: harryl@us.ibm.com 1320 17 Full Copyright Statement 1322 Copyright (C) The Internet Society (2001). All Rights Reserved. 1324 This document and translations of it may be copied and furnished to 1325 others, and derivative works that comment on or otherwise explain it 1326 or assist in its implementation may be prepared, copied, published 1327 and distributed, in whole or in part, without restriction of any 1328 kind, provided that the above copyright notice and this paragraph are 1329 included on all such copies and derivative works. However, this 1330 document itself may not be modified in any way, such as by removing 1331 the copyright notice or references to the Internet Society or other 1332 Internet organizations, except as needed for the purpose of 1333 developing Internet standards in which case the procedures for 1334 copyrights defined in the Internet Standards process must be 1335 followed, or as required to translate it into languages other than 1336 English. 1338 The limited permissions granted above are perpetual and will not be 1339 revoked by the Internet Society or its successors or assigns. 1341 This document and the information contained herein is provided on an 1342 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1343 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1344 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1345 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1346 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1348 Acknowledgement 1350 Funding for the RFC Editor function is currently provided by the 1351 Internet Society.