idnits 2.17.1 draft-ietf-ipp-notify-get-04.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. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2911, but the abstract doesn't seem to directly say this. It does mention RFC2911 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 296 has weird spacing: '... by the is a ...' == Line 867 has weird spacing: '... object immed...' == Line 1294 has weird spacing: '...ent who s th...' == Line 1504 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in '[Target category: standards track]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC2911, updated by this document, for RFC5378 checks: 1999-02-22) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 17, 2001) is 8317 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 933, but not defined == Missing Reference: 'IANA-MIMEREG' is mentioned on line 942, but not defined == Missing Reference: 'US-ASCII' is mentioned on line 951, but not defined == Unused Reference: 'RFC2026' is defined on line 1317, 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: 20 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Printing Protocol WG Robert Herriot (editor) 3 INTERNET-DRAFT Xerox Corp. 4 Carl Kugler 5 Updates: RFC 2911 Harry Lewis 6 [Target category: standards track] IBM, Corp. 7 Expires: January 17, 2002 July 17, 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 Notifications and Subscriptions" specification [ipp-ntfy]. 39 When IPP Notification [ipp-ntfy] is supported, the Delivery Method 40 defined in this document is one of the RECOMMENDED Delivery Methods 41 for Printers to support. 43 The 'ippget' Delivery Method is a 'pull' Delivery Method with aspects 44 of a 'push' method as well. That is, when an Event occurs, the 45 Printer saves the Event Notification for a period of time called the 46 Event Notification Lease Time. The Notification Recipient fetches 47 (pulls) Event Notifications using the Get-Notifications operation. 48 If the Notification Recipient has selected the option to wait for 49 additional Event Notifications, the Printer continues to return 51 #@# this page exceeds 58 lines: 59 52 (similar to push) Event Notifications to the Notification Recipient 53 as Get-Notification responses as Events occur. This push aspect is 54 not a true 'push', since the Printer does not open the connect, but 55 rather continues to return responses as Events occur using the 56 connection originated by the Notification Recipient. 58 Table of Contents 60 1 Introduction.....................................................5 62 2 Terminology......................................................5 64 3 Model and Operation..............................................6 66 4 General Information..............................................8 68 5 Get-Notifications operation......................................9 69 5.1 Get-Notifications Request.....................................11 70 5.2 Get-Notifications Response....................................13 72 6 Subscription Template Attributes................................18 73 6.1 Subscription Template Attribute Conformance...................18 74 6.2 Additional Information about Subscription Template Attributes.18 75 6.2.1 notify-recipient-uri (uri)..................................18 76 6.3 Subscription Description Attribute Conformance................19 78 7 Attributes only in Event Notifications..........................19 79 7.1 "notify-get-interval" (integer(0:MAX))........................19 81 8 Additional Printer Description Attributes.......................20 82 8.1 ippget-event-time-to-live (integer(0:MAX))....................20 84 9 New Values for Existing Printer Description Attributes..........21 85 9.1 notify-schemes-supported (1setOf uriScheme)...................21 86 9.2 operations-supported (1setOf type2 enum)......................21 88 10 New Status Codes...............................................21 89 10.1 redirection-other-site (0x0300)..............................21 91 11 The IPPGET URL Scheme..........................................22 92 11.1 The IPPGET URL Scheme Applicability and Intended Usage.......22 93 11.2 The IPPGET URL Scheme Associated Port........................22 94 11.3 The IPPGET URL Scheme Associated MIME Type...................22 95 11.4 The IPPGET URL Scheme Character Encoding.....................22 96 11.5 The IPPGET URL Scheme Syntax in ABNF.........................23 97 11.5.1 IPPGET URL Examples........................................24 98 11.5.2 IPPGET URL Comparisons.....................................24 100 12 Encoding and Transport.........................................25 102 13 Conformance Requirements.......................................26 103 13.1 Conformance for IPP Printers.................................26 104 13.2 Conformance for IPP Clients..................................27 106 14 IANA Considerations............................................28 107 14.1 Operation Registrations......................................28 108 14.2 Additional attribute value registrations for existing attributes 109 28 110 14.2.1 Additional values for the "notify-schemes-supported" Printer 111 attribute..............................................28 112 14.2.2 Additional values for the "operations-supported" Printer 113 attribute..............................................29 114 14.3 Attribute Registrations......................................29 115 14.4 Status code Registrations....................................29 117 15 Internationalization Considerations............................30 119 16 Security Considerations........................................30 121 17 References.....................................................30 123 18 Authors' Addresses.............................................32 125 19 Description of Base IPP documents..............................33 127 20 Full Copyright Statement.......................................35 129 Table of Tables 131 Table 1 " Information about the Delivery Method....................8 132 Table 2 " Attributes in Event Notification Content................16 133 Table 3 " Additional Attributes in Event Notification Content for Job 134 Events........................................................17 135 Table 4 " Combinations of Events and Subscribed Events for "job- 136 impressions-completed"........................................17 137 Table 5 " Additional Attributes in Event Notification Content for 138 Printer Events................................................18 139 Table 6 " Operation-id assignments................................21 140 Table 7 " The "event-notification-attributes-tag" value...........26 142 1 Introduction 144 The "IPP Event Notifications and Subscriptions" document [ipp-ntfy] 145 defines an OPTIONAL extension to Internet Printing Protocol/1.0 (IPP) 146 [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. For a description 147 of the base IPP documents, see section 19. The [ipp-ntfy] extension 148 defines operations that a client can perform in order to create 149 Subscription Objects in a Printer and carry out other operations on 150 them. A Subscription Object represents a Subscription abstraction. 151 A client associates Subscription Objects with a particular Job by 152 performing the Create-Job-Subscriptions operation or by submitting a 153 Job with subscription information. A client associates Subscription 154 Objects with the Printer by performing a Create-Printer-Subscriptions 155 operation. Four other operations are defined for Subscription 156 Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew- 157 Subscription, and Cancel-Subscription. The Subscription Object 158 specifies that when one of the specified Events occurs, the Printer 159 sends an asynchronous Event Notification to the specified 160 Notification Recipient via the specified Delivery Method (i.e., 161 protocol). 163 The "IPP Event Notifications and Subscriptions" document [ipp-ntfy] 164 specifies that each Delivery Method is defined in another document. 165 This document is one such document, and it specifies the 'ippget' 166 delivery method. When IPP Notification [ipp-ntfy] is supported, the 167 Delivery Method defined in this document is one of the RECOMMENDED 168 Delivery Methods for Printers to support. 170 The 'ippget' Delivery Method is a 'pull' Delivery Method with aspects 171 of a 'push' method as well. That is, when an Event occurs, the 172 Printer saves the Event Notification for a period of time called the 173 Event Notification Lease Time. The Notification Recipient fetches 174 (pulls) the Event Notifications using the Get-Notifications 175 operation. This operation causes the Printer to return all Event 176 Notifications held for the Notification Recipient. If the 177 Notification Recipient has selected the option to wait for additional 178 Event Notifications, the Printer continues to return (similar to 179 push) Event Notifications to the Notification Recipient as Get- 180 Notification responses as Events occur. This push aspect is not a 181 true 'push', since the Printer does not open the connect, but rather 182 continues to return responses as Events occur using the connection 183 originated by the Notification Recipient. 185 2 Terminology 187 This section defines the following terms that are used throughout 188 this document: 190 This document uses the same terminology as [RFC2911], such as 191 "client", "Printer", "Job", "attribute", "attribute value", 192 "keyword", "operation", "request", "response", and "support". 194 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 195 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 196 conformance as defined in RFC 2119 [RFC2119] and [RFC2911] section 197 12.1. If an implementation supports the extension defined in this 198 document, then these terms apply; otherwise, they do not. These 199 terms define conformance to this document only; they do not affect 200 conformance to other documents, unless explicitly stated otherwise. 202 Event Notification Lease: The lease that is associated with an Event 203 Notification. When the lease expires, the Printer discards the 204 associated Event Notification. 206 Event Notification Lease Time: The expiration time assigned to a 207 lease that is associated with an Event Notification. 209 Event Notification Attributes Group: The attributes group in a 210 response that contains attributes that are part of an Event 211 Notification. 213 Event Wait Mode: The mode requested by a Notification Recipient 214 client in its Get-Notifications Request and granted by a Printer to 215 keep the connection open where the Printer sends subsequent Event 216 Notifications to the Notification Recipient as they occur as 217 additional Get-Notification Responses. 219 Other capitalized terms, such as Notification Recipient, Event 220 Notification, Compound Event Notification, Printer, etc., are 221 defined in [ipp-ntfy], have the same meanings, and are not reproduced 222 here. 224 3 Model and Operation 226 In a Subscription Creation Operation, when the value of the "notify- 227 recipient-uri" attribute has the scheme 'ippget', the client is 228 requesting that the Printer use the 'ippget' Delivery Method for the 229 Event Notifications associated with the new Subscription Object. The 230 client SHOULD choose a value for the address part of the "notify- 231 recipient-uri" attribute that uniquely identifies the Notification 232 Recipient. 234 When an Event occurs, the Printer MUST generate an Event Notification 235 and MUST assign it the Event Notification Lease Time. The Printer 236 MUST hold an Event Notification for its assigned Event Notification 237 Lease Time. The Printer MUST assign the same Event Notification 238 Lease Time to each Event Notification. 240 When a Notification Recipient wants to receive Event Notifications, 241 it performs the Get-Notifications operation, which causes the Printer 242 to return all un-expired Event Notifications held for the 243 Notification Recipient. If the Notification Recipient has selected 244 the Event Wait Mode option to wait for additional Event 245 Notifications, the response to the Get-Notifications request 246 continues indefinitely as the Printer continues to send Event 247 Notifications in the response as Events occur. For the Get- 248 Notification operation, the Printer sends only those Event 249 Notifications that are generated from Subscription Objects whose 250 "notify-recipient-uri" attribute value equals the value of the 251 "notify-recipient-uri" Operation Attribute in the Get-Notifications 252 operation. 254 If a Notification Recipient performs the Get-Notifications operation 255 twice in quick succession, it will receive nearly the same Event 256 Notification both times because most of the Event Notifications are 257 those that the Printer saves for a few seconds after the Event 258 occurs. There are two possible differences. Some old Event 259 Notifications may not be present in the second response because their 260 Event Notification Leases have expired. Some new Event Notifications 261 may be present in the second response but not the first response, 262 because they occurred after the first response. 264 When the Notification Recipient requests Event Notifications for per- 265 Job Subscription Objects, the Notification Recipient typically 266 performs the Get-Notifications operation within a second of 267 performing the Subscription Creation operation. Because the Printer 268 is likely to save Event Notifications for several seconds, the 269 Notification Recipient is unlikely to miss any Event Notifications 270 that occur between the Subscription Creation and the Get- 271 Notifications operation. 273 4 General Information 275 If a Printer supports this Delivery Method, the following are its 276 characteristics. 278 Table 1 " Information about the Delivery Method 280 Document Method Conformance Requirement Delivery Method 281 Realization 283 1. What is the URL scheme name for the ippget 284 Delivery Method? 285 2. Is the Delivery Method REQUIRED, RECOMMENDED 286 RECOMMENDED or OPTIONAL for an IPP 287 Printer to support? 288 3. What transport and delivery protocols IPP with one new 289 does the Printer use to deliver the Event operation. 290 Notification Content, i.e., what is the 291 entire network stack? 292 4. Can several Event Notifications be Yes. 293 combined into a Compound Event 294 Notification? 295 5. Is the Delivery Method initiated by the This Delivery Method 296 Notification Recipient (pull), or by the is a pull method 297 Printer (push)? with aspects of a 298 push method, though 299 the Printer does not 300 initiate the 301 connection. 302 6. Is the Event Notification content Machine Machine Consumable 303 Consumable or Human Consumable? 304 7. What section in this document answers the Section 5 305 following question? For a Machine 306 Consumable Event Notification, what is 307 the representation and encoding of values 308 defined in section 9.1 of [ipp-ntfy] and 309 the conformance requirements thereof? For 310 a Human Consumable Event Notification, 311 what is the representation and encoding 312 of pieces of information defined in 313 section 9.2 of [ipp-ntfy] and the 314 conformance requirements thereof? 315 8. What are the latency and reliability of Same as IPP and the 316 the transport and delivery protocol? underlying HTTP 317 transport 318 9. What are the security aspects of the Same as IPP and the 319 transport and delivery protocol, e.g., underlying HTTP 320 how it is handled in firewalls? transport 321 10. What are the content length restrictions? None 322 11. What are the additional values or pieces None 323 of information that a Printer sends in an 324 Event Notification content and the 325 conformance requirements thereof? 326 12. What are the additional Subscription None 327 Template and/or Subscription Description 328 attributes and the conformance 329 requirements thereof? 330 13. What are the additional Printer None 331 Description attributes and the 332 conformance requirements thereof? 334 5 Get-Notifications operation 336 This operation is issued by a client acting in the role of a 337 Notification Recipient and causes the Printer to return all Event 338 Notifications held for the Notification Recipient. 340 A Printer MUST support this operation. 342 When a Printer performs this operation, it MUST return all and only 343 those Event Notifications: 345 1. Whose associated Subscription Object's "notify-subscription-id" 346 attribute equals the "notify-subscription-id" Operation 347 attribute if supplied AND 349 2. Whose associated Subscription Object's "notify-recipient-uri" 350 attribute equals the "notify-recipient-uri" Operation attribute 351 AND 353 3. Whose associated Subscription Object's "notify-recipient-uri" 354 attribute matches the scheme value of 'ippget' using the 355 matching rules in section 11.5.2 AND 357 4. Whose Event Notification Lease Time has not yet expired AND 359 5. Where the Notification Recipient is the owner of or has read- 360 access rights to the associated Subscription Object. 362 The Printer has the following options for responding to a Get- 363 Notifications Request: 365 #@# next line is > 72 characters: 73 366 1. The Printer can reject the request and return the 'server-error- 367 busy' status code, if the Printer is too busy to accept this 368 operation at this time. In this case, the Printer MUST return 369 the "get-notify-interval" attribute to indicate when the client 370 should try again. 372 2. If the Notification Recipient did not request Event Wait Mode, 373 the Printer MUST respond to this operation immediately with 374 whatever Event Notifications it currently holds and return the 375 "notify-get-interval" attribute with number of seconds from now 376 at which the Notification Recipient MAY repeat the Get- 377 Notifications Request to get future Event Notifications. 379 3. If the Notification Recipient requested Event Wait Mode, the 380 Printer MUST respond to this operation immediately with whatever 381 Event Notifications it currently holds MUST continue to send 382 Event Notifications as they occur until all of the associated 383 Subscription Objects are cancelled. A Subscription Object is 384 cancelled either via the Cancel-Subscription operation or by the 385 Printer (e.g., the Subscription Object is cancelled when the 386 associated Job completes and is no longer in the Job Retention 387 or Job History phase - see the "ippget-event-time-to-live 388 (integer(0:MAX))" attribute discussion in section 8.1). 389 However, the Printer MAY decide to terminate Event Wait Mode at 390 any time, including in the first response. In this case the 391 Printer MUST return an additional Event Notification Attributes 392 Group that contains the single "notify-get-interval" attribute. 393 This attribute indicates that the Printer wishes to leave Event 394 Wait Mode and the number of seconds in the future that the 395 Notification Recipient SHOULD try the Get-Notifications 396 operation again. The Notification Recipient MUST accept this 397 response and MUST disconnect. If the Notification Recipient 398 does not disconnect, the Printer SHOULD do so. 400 If the Notification Recipient wishes to terminate the Get- 401 Notifications operation, it can close the connection. See section 12 402 for the encoding and transport rules for the Get-Notifications 403 Response for the Event Wait Mode. 405 The Printer MUST accept the request in any state (see [RFC2911] 406 "printer-state" and "printer-state-reasons" attributes) and MUST 407 remain in the same state with the same "printer-state-reasons" 408 values. 410 Access Rights: If the policy of the Printer is to allow all users to 411 access all Event Notifications, then the Printer MUST accept this 412 operation from any user. Otherwise, the authenticated user (see 413 [RFC2911] section 8.3) performing this operation MUST either be the 414 owner of each Subscription Object identified by the "notify- 415 recipient-uri" Operation attribute (as determined during a 416 Subscription Creation Operation) or an operator or administrator of 417 the Printer (see [RFC2911] Sections 1 and 8.5). Otherwise, the IPP 418 object MUST reject the operation and return: 'client-error- 419 forbidden', 'client-error-not-authenticated', or 'client-error-not- 420 authorized' status code as appropriate. 422 5.1 Get-Notifications Request 424 The following groups of attributes are part of the Get-Notifications 425 Request: 427 Group 1: Operation Attributes 429 Natural Language and Character Set: 430 The "attributes-charset" and "attributes-natural-language" 431 attributes as described in [RFC2911] section 3.1.4.1. 433 Target: 434 The "printer-uri" (uri) operation attribute which is the target 435 for this operation as described in [RFC2911] section 3.1.5. 437 Requesting User Name: 438 The "requesting-user-name" (name(MAX)) attribute SHOULD be 439 supplied by the client as described in [RFC2911] section 8.3. 441 "notify-subscription-id" (integer(1:MAX)): 442 The client SHOULD supply this attribute, if known, and the 443 client is only monitoring a single Subscription object. The 444 Printer object MUST support this attribute. If supplied, but 445 no Subscription Object exists with this identifier, the Printer 446 MUST return the 'client-error-not-found' status code. 448 If supplied and the identified Subscription Object exists, the 449 Printer MUST check that the Subscription Object's "notify- 450 recipients-uri" attribute scheme is 'ippget' (case insensitive- 451 match - see section 11.5.2). If the scheme does not match 452 'ippget', the Printer MUST reject the request and return the 453 'client-error-uri-scheme-not-supported' status code. 455 Note: If Notification Recipients supplies this attribute, if 456 known, then the Event Notifications will be sent in time stamp 457 order since only one Subscription object is involved (see 458 "Event Notification Ordering" requirements in [ipp-ntfy] 459 section 9). Supplying this attribute also reduces the Event 460 processing time on the Printer since the Printer doesn't have 461 to search all of the Subscription Objects in order to match the 462 "notify-recipient-uri" operation attribute (see next 463 attribute). 465 "notify-recipient-uri" (uri(255)): 466 The client MAY supply this attribute whether or not it also 467 supplies the "notify-subscription-id" operation attribute. The 468 Printer object MUST support this attribute. If the client 469 supplies neither the "notify-subscription-id" nor the "notify- 470 recipient-uri", the Printer MUST reject the request and return 471 the 'client-error-bad-request' status code. 473 If the supplied scheme is not ippget (case insensitive-match - 474 see section 11.5.2), the Printer MUST reject the request and 475 return the 'client-error-uri-scheme-not-supported' status code. 477 If the client also supplied the "notify-subscription-id" 478 attribute, then the value of this attribute MUST match the 479 "notify-recipient-uri" Subscription Description attribute for 480 the identified Subscription object. If they do not match, the 481 Printer MUST return the 'client-error-not-found' status code. 483 If the client did not supply the "notify-subscription-id" 484 operation attribute, the Printer matches the value of this 485 "notify-recipient-uri" attribute against the value of the 486 "notify-recipient-uri" Subscription Description attribute in 487 each Subscription Object in the Printer using the URI matching 488 rules specified in section 11.5.2. If there are no matches, the 489 IPP Printer MUST return the 'client-error-not-found' status 490 code. 492 The value of this attribute is defined to be shorter (255 493 octets) than the 'uri' attribute syntax (1023 octets) in 494 [RFC2911], since this uri is used for identification, not for 495 locating a network resource. 497 The [ipp-ntfy] specification REQUIRES that Subscription 498 Object's "notify-recipient-uri" attribute be returned in any 499 operation with the identical representation as supplied by the 500 original Subscribing Client in the Subscription Creation 501 Request. Therefore the Printer implementation MUST use other 502 means to perform the URI match than changing the Subscription 503 Object's original "notify-recipient-uri" value to a canonical 504 form. 506 Note: this attribute allows a subscribing client to pick URLs 507 that are unique, e.g. the client's own URL or a friend's URL, 508 which in both cases is likely the URL of the person's host. An 509 application could make a URL unique for each application. 511 "notify-wait" (boolean): 512 The client MAY supply this attribute. The Printer object MUST 513 support both values of this attribute. If the value is 'true', 514 the client is requesting Event Wait Mode. See the beginning of 515 section 5 for the rules for Event Wait Mode. 517 5.2 Get-Notifications Response 519 The following groups of attributes are part of the Get-Notifications 520 Response: 522 Group 1: Operation Attributes 524 Status Message: 525 In addition to the REQUIRED status code returned in every 526 response, the response OPTIONALLY includes a "status-message" 527 (text(255)) and/or a "detailed-status-message" (text(MAX)) 528 operation attribute as described in [RFC2911] sections 13 and 529 3.1.6. 531 The Printer can return any status codes defined in [RFC2911]. 532 If the status code is not 'successful-xxx', the Printer MUST 533 NOT return any Event Notification Attribute groups. The 534 following is a description of the important status codes: 536 successful-ok: the response contains all Event Notification 537 associated with the specified "notify-recipient-uri". If 538 the specified Subscription Objects have no associated 539 Event Notification, the response MUST contain zero Event 540 Notifications. 541 client-error-not-found: The Printer has no Subscription 542 Object's whose "notify-recipient-uri" attribute equals 543 the "notify-recipient-uri" Operation attribute, if 544 supplied or whose "notify-subscription-id" attribute 545 equals the "notify-subscription-id" Operation attribute, 546 if supplied. 547 server-error-busy: The Printer is too busy to accept this 548 operation. If the "notify-get-interval" operation 549 attribute is present in the Operation Attributes of the 550 response, then the Notification Recipient SHOULD wait for 551 the number of seconds specified by the "notify-get- 552 interval" attribute before performing this operation 553 again. If the "notify-get-interval" Operation Attribute 554 is not present, the Notification Recipient SHOULD use the 555 normal network back-off algorithms for determining when 556 to perform this operation again. 557 redirection-other-site: The Printer does not handle this 558 operation and requests the Notification Recipient to 559 perform the operation again with the uri specified by the 560 "redirect-uri" Operation Attribute in the response. 562 Natural Language and Character Set: 563 The "attributes-charset" and "attributes-natural-language" 564 attributes as described in [RFC2911] section 3.1.4.2. 566 The Printer MUST use the values of "notify-charset" and 567 "notify-natural-language", respectively, from one Subscription 568 Object associated with the Event Notifications in this 569 response. 571 Normally, there is only one matched Subscription Object, or the 572 value of the "notify-charset" and "notify-natural-language" 573 attributes is the same in all Subscription Objects. If not, the 574 Printer MUST pick one Subscription Object from which to obtain 575 the value of these attributes. The algorithm for picking the 576 Subscription Object is implementation dependent. The choice of 577 natural language is not critical because 'text' and 'name' 578 values can override the "attributes-natural-language" Operation 579 attribute. The Printer's choice of charset is critical because 580 a bad choice may leave it unable to send some 'text' and 'name' 581 values accurately. 583 "printer-up-time" (integer(1:MAX)): 584 The value of this attribute is the Printer's "printer-up-time" 585 attribute at the time the Printer sends this response. Because 586 each Event Notification also contains the value of this 587 attribute when the event occurred, the value of this attribute 588 lets a Notification Recipient know when each Event Notification 589 occurred relative to the time of this response. 591 "redirect-uri" (uri): 592 The value of this attribute is the uri that the Notification 593 Recipient MUST use for a subsequent Get-Notifications 594 operation. This attribute is returned in the Operation 595 Attributes Group if and only if the status code has the value 596 'redirection-other-site'. 598 Group 2: Unsupported Attributes 600 See [RFC2911] section 3.1.7 for details on returning 601 Unsupported Attributes. 603 Group 3 through N: Event Notification Attributes 605 The Printer responds with one Event Notification Attributes 606 Group per matched Event Notification. The entire response is 607 considered a single Compound Event Notification (see [ipp- 608 ntfy]). The last Event Notification Attributes Group MAY 609 contain a single "notify-get-interval" (see section 7.1 and 610 12), in which case the Printer will return no future responses. 611 The initial matched Event Notifications are all un-expired 612 Event Notification associated with the matched Subscription 613 Objects and MUST follow the "Event Notification Ordering" 614 requirements for Event Notifications within a Compound Event 615 Notification specified in [ipp-ntfy] section 9. 617 If the Notification Recipient has selected the Event Wait Mode 618 option to wait for additional Event Notifications (the "notify- 619 wait" attribute was set to 'true'), the Printer sends 620 subsequent Event Notifications in the response each time it 621 processes additional Events. Each time the Printer sends such 622 Event Notifications, their ordering MUST follow the "Event 623 Notification Ordering" requirements in [ipp-ntfy] section 9. 625 Note: If a Notification Recipient performs two consecutive Get- 626 Notifications operations, the time stamp of the first Event 627 Notification in the second Get-Notifications Response may be 628 less than the time stamp of the last Event Notification in the 629 first Get-Notification Response. This happens because the 630 Printer sends all unexpired Event Notification according to the 631 ordering specified in [ipp-ntfy] and some Event Notifications 632 from the first Get-Notifications operation may not have expired 633 by the time the second Get-Notifications operation occurs. 635 From the Notification Recipient's view, the response appears as 636 an initial burst of data, which includes the Operation 637 Attributes Group and one Event Notification Attributes Group 638 per Event Notification that the Printer is holding. After the 639 initial burst of data, if the Notification Recipient has 640 selected the Event Wait Mode option to wait for additional 641 Event Notifications, the Notification Recipient receives 642 occasional Event Notification Attribute Groups. Proxy servers 643 may delay some Event Notifications or cause time-outs to occur. 644 The client MUST be prepared to perform the Get-Notifications 645 operation again when time-outs occur. 647 Each attribute is encoded using the IPP rules for encoding 648 attributes [RFC2910] and MAY be encoded in any order. Note: 650 the Get-Jobs response in [RFC2911] acts as a model for encoding 651 multiple groups of attributes. See section 12 for the encoding 652 and transport rules. 654 Each Event Notification Group MUST contain all of attributes 655 specified in section 9.1 ("Content of Machine Consumable Event 656 Notifications") of [ipp-ntfy] with exceptions denoted by 657 asterisks in the tables below. 659 The tables below are copies of the tables in section 9.1 660 ("Content of Machine Consumable Event Notifications") of [ipp- 661 ntfy] except that each cell in the "Sends" column is a "MUST". 663 For an Event Notification for all Events, the Printer includes 664 the attributes shown in Table 2. 666 Table 2 " Attributes in Event Notification Content 668 Source Value Sends Source Object 670 notify-subscription-id (integer(1:MAX)) MUST Subscription 671 notify-printer-uri (uri) MUST Subscription 672 notify-subscribed-event (type2 keyword) MUST Event 673 Notification 674 printer-up-time (integer(1:MAX)) MUST Printer 675 printer-current-time (dateTime) MUST * Printer 676 notify-sequence-number (integer (0:MAX)) MUST Subscription 677 notify-charset (charset) MUST Subscription 678 notify-natural-language (naturalLanguage) MUST Subscription 679 notify-user-data (octetString(63)) MUST ** Subscription 680 notify-text (text) MUST Event 681 Notification 682 attributes from the "notify-attributes" MUST *** Printer 683 attribute 684 attributes from the "notify-attributes" MUST *** Job 685 attribute 686 attributes from the "notify-attributes" MUST *** Subscription 687 attribute 689 * The Printer MUST send the "printer-current-time" attribute if 690 and only if it supports the "printer-current-time" attribute on 691 the Printer object. 693 ** If the associated Subscription Object does not contain a 694 "notify-user-data" attribute, the Printer MUST send an octet- 695 string of length 0. 697 *** If the "notify-attributes" attribute is present on the 698 Subscription Object, the Printer MUST send all attributes 699 specified by the "notify-attributes" attribute. Note: if the 700 Printer doesn't support the "notify-attributes" attribute, it 701 is not present on the associated Subscription Object. 703 For Event Notifications for Job Events, the Printer includes 704 the additional attributes shown in Table 3. 706 Table 3 " Additional Attributes in Event Notification Content for 707 Job Events 709 Source Value Sends Source 710 Object 712 job-id (integer(1:MAX)) MUST Job 713 job-state (type1 enum) MUST Job 714 job-state-reasons (1setOf type2 keyword) MUST Job 715 job-impressions-completed (integer(0:MAX)) MUST * Job 717 * The Printer MUST send the "job-impressions-completed" 718 attribute in an Event Notification only for the combinations of 719 Events and Subscribed Events shown in Table 4. 721 Table 4 " Combinations of Events and Subscribed Events for "job- 722 impressions-completed" 724 Job Event Subscribed Job Event 726 'job-progress' 'job-progress' 727 'job-completed' 'job-completed' 728 'job-completed' 'job-state-changed' 730 For Event Notification for Printer Events, the Printer includes 731 the additional attributes shown in Table 5. 733 Table 5 " Additional Attributes in Event Notification Content for 734 Printer Events 736 Source Value Sends Source 737 Object 739 printer-state (type1 enum) MUST Printer 740 printer-state-reasons (1setOf type2 keyword) MUST Printer 741 printer-is-accepting-jobs (boolean) MUST Printer 743 6 Subscription Template Attributes 745 This section defines the Subscription object conformance requirements 746 for Printers. 748 6.1 Subscription Template Attribute Conformance 750 The 'ippget' Delivery Method has the same conformance requirements 751 for Subscription Template attributes as defined in [ipp-ntfy]. The 752 'ippget' Delivery Method does not define any addition Subscription 753 Template attributes. 755 6.2 Additional Information about Subscription Template Attributes 757 This section defines additional information about Subscription 758 Template attributes defined in [ipp-ntfy]. 760 6.2.1 notify-recipient-uri (uri) 762 This section describes the syntax of the value of this attribute for 763 the 'ippget' Delivery Method. The syntax for values of this 764 attribute for other Delivery Method is defined in other Delivery 765 Method Documents. 767 In order to support the 'ippget' Delivery Method and Protocol, the 768 Printer MUST support the following syntax: 770 The 'ippget://' URI scheme. The remainder of the URI indicates 771 something unique about the Notification Recipient, such as its host 772 name or host address (and optional path) that the Printer uses to 773 match the "notify-recipient-uri" Operation attribute supplied in 774 the Get-Notifications request. See section 11 for a complete 775 definition of the syntax of the IPPGET URL. 777 6.3 Subscription Description Attribute Conformance 779 The 'ippget' Delivery Method has the same conformance requirements 780 for Subscription Description attributes as defined in [ipp-ntfy]. 781 The 'ippget' Delivery Method does not define any addition 782 Subscription Description attributes. 784 7 Attributes only in Event Notifications 786 This section defines attributes that exist only in Event 787 Notifications and do no exist in any IPP-defined objects. 789 7.1 "notify-get-interval" (integer(0:MAX)) 791 The Printer returns this attribute to give the client an indication 792 of when to try another Get-Notifications request in the future. The 793 value of this attribute is the number of seconds that the 794 Notification Recipient SHOULD wait before trying the Get- 795 Notifications operation again. This value is intended to help the 796 client be a good network citizen. 798 The Printer MUST return this attribute by itself in a separate Event 799 Notification Attributes Group. The Printer MUST return this 800 attribute if and only if: 802 1. Printer busy case: the Printer returns the 'server-error-busy' 803 status code OR 805 2. No wait case: the Printer returns the 'successful-ok' status 806 code and the client either (1) supplied the "notify-wait" 807 attribute with a value of 'false' or (2) omitted the attribute 808 entirely OR 810 3. Printer leaves Event Wait Mode: the Printer returns the 811 'successful-ok' status code and the client supplied the "notify- 812 wait" attribute with the 'true value (Event Wait Mode) but the 813 Printer wants the client to disconnect (no wait), instead of 814 staying connected. The client MUST accept this response and 815 MUST disconnect. If the client does not disconnect, the Printer 816 SHOULD do so. The Printer returns this attribute for this case 817 only if the implementation does not want to keep the connection 818 open at this time. If the Printer wants the client to keep the 819 connection open and remain in Event Wait Mode, then the Printer 820 MUST NOT return this attribute in the response. 822 8 Additional Printer Description Attributes 824 This section defines additional Printer Description attributes for 825 use with the 'ippget' Delivery Method. 827 8.1 ippget-event-time-to-live (integer(0:MAX)) 829 This Printer Description attribute specifies the number of seconds 830 that a Printer keeps an Event Notification that is associated with 831 the 'ippget' Delivery Method. 833 The Printer MUST support this attribute if it supports the 'ippget' 834 Delivery Method. 836 The value of this attribute is the minimum number of seconds that 837 MUST elapse between the time the Printer creates an Event 838 Notification object for the 'ippget' Delivery Method and the time the 839 Printer discards the same Event Notification. 841 For example, assume the following: 843 1. a client performs a Job Creation operation that creates a 844 Subscription Object associated with this Delivery Method, AND 846 2. an Event associated with the new Job occurs immediately after 847 the Subscription Object is created, AND 849 3. the same client or some other client performs a Get- 850 Notifications operation N seconds after the Job Creation 851 operation. 853 Then, if N is less than the value of this attribute, the client(s) 854 performing the Get-Notifications operations can expect not to miss 855 any Event-Notifications, barring some unforeseen lack of memory space 856 in the Printer. 858 The value of this attribute also specifies the minimum number of 859 seconds that the Printer, if supporting the ippget Delivery Method, 860 MUST keep 'completed', 'canceled', or 'aborted' Job objects in the 861 Job Retention and/or Job History phases. See [RFC2911] section 862 4.3.7.1 and the discussion in [ipp-ntfy] 'job-completed' event) that 863 explains that a Notification Recipients can query the Job after 864 receiving a 'job-completed' Event Notification in order to find out 865 other information about the job that is completing. However, this 866 attribute has no effect on the Cancel-Subscription operation which 867 deletes the object immediately, whether or not it contain the ippget 868 scheme. Immediately thereafter, subsequent Get-Notifications 869 Responses MUST NOT contain Event Notifications associated with the 870 cancelled Subscription object. 872 9 New Values for Existing Printer Description Attributes 874 This section defines additional values for existing Printer 875 Description attributes define in [ipp-ntfy]. 877 9.1 notify-schemes-supported (1setOf uriScheme) 879 The following value for the "notify-schemes-supported" attribute is 880 added in order to support the new Delivery Method defined in this 881 document: 883 'ippget' - The IPP Notification Delivery Method defined in this 884 document. 886 9.2 operations-supported (1setOf type2 enum) 888 Table 6 lists the "operation-id" value defined in order to support 889 the new Get-Notifications operation defined in this document. 891 Table 6 " Operation-id assignments 893 Value Operation Name 895 0x001C Get-Notifications 897 10 New Status Codes 899 The following status codes are defined as extensions for this 900 Delivery Method and are returned as the status code of the Get- 901 Notifications operation. 903 10.1 redirection-other-site (0x0300) 905 This status code means that the Printer doesn't perform that Get- 906 Notifications operation and that the "redirect-uri" Operation 907 Attribute in the response contains the uri that the Notification 908 Recipient MUST use for performing the Get-Notifications operation. 910 11 The IPPGET URL Scheme 912 This section defines the 'ippget' URL and the conformance 913 requirements for using it. 915 11.1 The IPPGET URL Scheme Applicability and Intended Usage 917 This section is intended for use in registering the 'ippget' URL 918 scheme with IANA and fully conforms to the requirements in [RFC2717]. 919 This document defines the 'ippget'" URL (Uniform Resource Locator) 920 scheme for specifying a unique identifier for an IPP Client which 921 implements the IPP Get-Notifications operation specified in this 922 document (see section 5). 924 The intended usage of the 'ippget' URL scheme is COMMON. 926 11.2 The IPPGET URL Scheme Associated Port 928 None. 930 An 'ippget' URL behaves as a unique identifier for IPP Clients and is 931 NOT used to initiate any over-the-wire protocol associations. 933 See: IANA Port Numbers Registry [IANA-PORTREG]. 935 11.3 The IPPGET URL Scheme Associated MIME Type 937 All IPP Get-Notifications operations (requests and responses) MUST be 938 conveyed in an 'application/ipp' MIME media type as registered in 939 [IANA-MIMEREG]. An 'ippget' URL MUST uniquely identify an IPP Client 940 that support this 'application/ipp' MIME media type. 942 See: IANA MIME Media Types Registry [IANA-MIMEREG]. 944 11.4 The IPPGET URL Scheme Character Encoding 946 The 'ippget' URL scheme defined in this document is based on the ABNF 947 for the URI Generic Syntax [RFC2396] and further updated by [RFC2732] 948 and [RFC2373] (for IPv6 addresses in URLs). The 'ippget' URL scheme 949 is case-insensitive in the scheme and 'authority' part; however, the 950 'abs_path' part is case-sensitive, as in [RFC2396]. Code points 951 outside [US-ASCII] MUST be hex escaped by the mechanism specified in 952 [RFC2396]. 954 11.5 The IPPGET URL Scheme Syntax in ABNF 956 This document is intended for use in registering the 'ippget' URL 957 scheme with IANA and fully conforms to the requirements in [RFC2717]. 958 This document defines the 'ippget' URL (Uniform Resource Locator) 959 scheme for specifying a unique identifier for an IPP Client which 960 implements IPP 'Get-Notifications' operation specified in this 961 document. 963 The intended usage of the 'ippget' URL scheme is COMMON. 965 The IPP protocol places a limit of 1023 octets (NOT characters) on 966 the length of a URI (see section 4.1.5 'uri' in [RFC2911]). An IPP 967 Printer MUST return the 'client-error-request-value-too-long' status 968 code (see section 13.1.4.10 in [RFC2911]) when a URI received in a 969 request is too long. 971 Note: IPP Clients and IPP Printers ought to be cautious about 972 depending on URI lengths above 255 bytes, because some older client 973 or proxy implementations might not properly support these lengths. 975 An 'ippget' URL MUST be represented in absolute form. Absolute URLs 976 always begin with a scheme name followed by a colon. For definitive 977 information on URL syntax and semantics, see "Uniform Resource 978 Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This 979 specification adopts the definitions of "authority", "abs_path", 980 "query", "reg_name", "server", "userinfo", and "hostport" from 981 [RFC2396], as updated by [RFC2732] and [RFC2373] (for IPv6 addresses 982 in URLs). 984 The 'ippget' URL scheme syntax in ABNF is as follows: 986 ippget_URL = "ippget:" "//" authority [ abs_path [ "?" query ]] 987 authority = server | reg_name 988 reg_name = 1*( unreserved | escaped | "$" | "," | 989 ";" | ":" | "@" | "&" | "=" | "+" ) 990 server = [ [ userinfo "@" ] hostport ] 991 userinfo = *( unreserved | escaped | 992 ";" | ":" | "&" | "=" | "+" | "$" | "," ) 993 hostport = host [ ":" port ] 994 abs_path = "/" path_segments 996 If the port is empty or not given, then no port is assumed. The 997 semantics are that the 'ippget' URL is a unique identifier for an IPP 998 Client that will retrieve IPP event notifications via the IPP Get- 999 Notifications operation. 1001 Note: The use of IP addresses in URLs SHOULD be avoided whenever 1002 possible (see [RFC1900]). 1004 11.5.1 IPPGET URL Examples 1006 The following are examples of valid 'ippget' URLs for IPP Clients 1007 (using DNS host names): 1009 ippget://abc.com 1010 ippget://abc.com/listener 1011 ippget://bob@abc.com/listener/1232 1013 Note: The use of IP addresses in URLs SHOULD be avoided whenever 1014 possible (see [RFC1900]). 1016 The IPP Client that creates the Subscription object and the 1017 Notification Recipient have to agree on a unique IPPGET URL value in 1018 order for the Get-Notifications operations to retrieve the proper 1019 Event Notifications. Therefore, the choice of 'userinfo@hostport' 1020 versus the simpler 'hostport' production in an 'ippget' URL may be 1021 influenced by the intended usage. 1023 If a given IPP Client creates an IPP Subscription object for event 1024 notifications intended for retrieval by the same IPP Client, then the 1025 simple 'hostport' production may be most appropriate. In this case, 1026 the IPP Client and the Notification Recipient both know the 1027 'hostport' of the client. 1029 On the other hand, if a given IPP Client creates an IPP Subscription 1030 object for event notifications intended for retrieval by a different 1031 IPP Client, then the 'userinfo@hostport' production (using, for 1032 example, the right-hand side of a 'mailto:' URL, see [RFC2368]) may 1033 be most appropriate. For this case, a mail address serves as the 1034 prior agreement on the IPPGET URL value between the IPP Client and 1035 the Notification Recipient. 1037 11.5.2 IPPGET URL Comparisons 1039 When comparing two 'ippget' URLs to decide if they match or not, 1040 an IPP Client or IPP Printer MUST use the same rules as those 1041 defined for HTTP URI comparisons in [RFC2616]. 1043 12 Encoding and Transport 1045 This section defines the encoding and transport considerations for 1046 this Delivery Method based on [RFC2910]. 1048 The encoding of a Get-Notifications Response is modeled the Get-Jobs 1049 Response (see [RFC2911]). In a Get-Notifications Response, each 1050 Event Notification Attributes Group MUST start with an 'event- 1051 notification-attributes-tag' (see the section "Encodings of 1052 Additional Attribute Tags" in [ipp-ntfy]), but only the last group 1053 ends with an 'end-of-attributes-tag'. In addition, for Event Wait 1054 Mode the multi-part/related is used to separate each multiple 1055 response (in time) to a single Get-Notifications Request. 1057 The Printer returns Get-Notification Response as follows: 1059 1. If the Notification Recipient client did not request Event Wait 1060 Mode ("notify-wait" = 'false' or omitted), the Printer ends the 1061 response with an 'end-of-attributes-tag' (see [RFC2911] Get-Jobs 1062 encoding) as with any operation response. The Notification 1063 Recipient is expected to close the connection. 1065 2. If the Notification Recipient client requests Event Wait Mode 1066 ("notify-wait" = 'true') and the Printer wishes to honor the 1067 request, the Printer ends the Response without an 'end-of- 1068 attributes-tag' and MUST return the response as an 1069 application/ipp part inside a multi-part/related MIME media 1070 type. Neither the Notification Recipient nor the Printer close 1071 the connection. When one or more additional Events occur, the 1072 Printer returns each as an additional Event Notification Group 1073 using a separate application/ipp part under the multi- 1074 part/related type. 1076 3. If the client requested Event Wait Mode ("notify-wait" = 1077 'true'), but the Printer does not wish to honor the request in 1078 the initial response but wants the client to disconnect, the 1079 Printer MUST return the "notify-get-interval" attribute (see 1080 section 7.1) as the last Event Notifications Attributes Group - 1081 see section 5.2), the Printer ends the Response with an 'end-of- 1082 attributes-tag'. The Printer returns the response as an 1083 application/ipp part which MAY be inside an multi-part/related 1084 type. The client MUST accept this response and MUST disconnect. 1085 If the client does not disconnect, the Printer SHOULD do so. 1087 4. If the client requested Event Wait Mode ("notify-wait" = 1088 'true'), and the Printer initially honored the request, but 1089 later wishes to leave Event Wait Mode, the Printer MUST return 1090 the "notify-get-interval" attribute (see section 7.1) as the 1091 last Event Notifications Attributes Group - see section 5.2), 1092 the Printer ends the Response with an 'end-of-attributes-tag'. 1093 The Printer returns the response as an application/ipp part 1094 which MUST be inside an multi-part/related type. 1096 ISSUE: Should we use application/multiplexed (draft-herriot- 1097 application-multiplexed-03.txt) which can chunk mime types using 1098 content lengths, instead of multi-part/related, which uses boundary 1099 strings? 1101 Note: either the Notification Recipient or the Printer can abnormally 1102 terminate by closing the connection. However, if the Printer closes 1103 the connection too soon after returning the response, the client may 1104 not receive the response. 1106 The Printer MAY chunk the responses, but this has no significance to 1107 the IPP semantics. 1109 This notification delivery method uses the IPP transport and encoding 1110 [RFC2910] for the Get-Notifications operation with one extension 1111 allocated in [ipp-ntfy]: 1113 Table 7 " The "event-notification-attributes-tag" value 1115 Tag Value (Hex) Meaning 1117 0x07 "event-notification-attributes-tag" 1119 13 Conformance Requirements 1121 The 'ippget' Delivery Method is RECOMMEND for Printers to support. 1123 13.1 Conformance for IPP Printers 1125 IPP Printers that conform to this specification: 1127 1. MUST meet the conformance requirements defined in [ipp-ntfy]; 1129 2. MUST support the Get-Notifications operation defined in section 1130 5; 1132 3. MUST support the Subscription object attributes as defined in 1133 section 6; 1135 4. MUST support the additional values for IPP/1.1 Printer 1136 Description attributes defined in section 9; 1138 #@# next line is > 72 characters: 73 1139 5. MUST support the "ippget-event-time-to-live" Printer Description 1140 attribute defined in section 8.1; 1142 6. MUST support the "redirection-other-site" status code defined 1143 10.1, if it redirects Get-Notifications operations; 1145 7. SHOULD reject received 'ippget' URLs in 'application/ipp' 1146 request bodies (e.g., in the "notify-recipient-uri" attribute in 1147 a Get-Notifications request) that do not conform to the ABNF for 1148 'ippget' URLs specified in section 11.5 of this document; 1150 8. MUST listen for the IPP Get-Notifications operation requests on 1151 IANA-assigned well-known port 631, unless explicitly configured 1152 by system administrators or site policies; 1154 9. SHOULD NOT listen for IPP Get-Notifications operation requests 1155 on any other port, unless explicitly configured by system 1156 administrators or site policies. 1158 13.2 Conformance for IPP Clients 1160 IPP Clients that conform to this specification: 1162 1. MUST create unambiguously unique 'ippget' URLs in all cases; 1164 2. MUST send 'ippget' URLs (e.g., in the "notify-recipient-uri" 1165 attribute in a Get-Notifications request) that conform to the 1166 ABNF specified in section 11.5 of this document; 1168 3. MUST send IPP Get-Notifications operation requests via the port 1169 specified in the associated 'ipp' URL (if present) or otherwise 1170 via IANA assigned well-known port 631; 1172 4. MUST convert the associated 'ipp' URLs for use in IPP Get- 1173 Notifications operation to their corresponding 'http' URL forms 1174 for use in the HTTP layer according to the rules in section 5 1175 "IPP URL Scheme" in [RFC2910]. 1177 Note: The use of ambiguous 'ippget' URLs is NOT an optional feature 1178 for IPP Clients; it is a non-conformant implementation error. 1180 14 IANA Considerations 1182 IANA shall register the 'ippget' URL scheme as defined in section 11 1183 according to the procedures of [RFC2717]. 1185 The rest of this section contains the exact information for IANA to 1186 add to the IPP Registries according to the procedures defined in RFC 1187 2911 [RFC2911] section 6. 1189 Note to RFC Editors: Replace RFC NNNN below with the RFC number 1190 for this document, so that it accurately reflects the content of 1191 the information for the IANA Registry. 1193 14.1 Operation Registrations 1195 The following table lists the operation defined in this document. 1196 This is to be registered according to the procedures in RFC 2911 1197 [RFC2911] section 6.4. 1199 Operations: Ref. Section: 1200 Get-Notifications operation RFC NNNN 5 1202 The resulting operation registration will be published in the 1203 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/operations/ 1204 area. 1206 14.2 Additional attribute value registrations for existing attributes 1208 This section lists additional attribute value registrations for use 1209 with existing attributes defined in other documents. 1211 14.2.1 Additional values for the "notify-schemes-supported" Printer 1212 attribute 1214 The following table lists the uriScheme value defined in this 1215 document as an additional uriScheme value for use with the "notify- 1216 schemes-supported" Printer attribute defined in [ipp-ntfy]. This 1217 is to be registered according to the procedures in RFC 2911 [RFC2911] 1218 section 6.1. 1220 uriScheme Attribute Values: Ref. Section: 1221 ippget RFC NNNN 9.1 1222 The resulting URI scheme attribute value registrations will be 1223 published in the 1224 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute- 1225 values/notify-schemes-supported/ 1226 area. 1228 14.2.2 Additional values for the "operations-supported" Printer 1229 attribute 1231 The following table lists the enum attribute value defined in this 1232 document as an additional type2 enum value for use with the 1233 "operations-supported" Printer attribute defined in [RFC2911]. This 1234 is to be registered according to the procedures in RFC 2911 [RFC2911] 1235 section 6.1. 1237 type2 enum Attribute Values: Value Ref. Section: 1238 Get-Notifications 0x001C RFC NNNN 9.2 1240 The resulting enum attribute value registration will be published in 1241 the 1242 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute- 1243 values/operations-supported/ 1244 area. 1246 14.3 Attribute Registrations 1248 The following table lists the attribute defined in this document. 1249 This is to be registered according to the procedures in RFC 2911 1250 [RFC2911] section 6.2. 1252 Printer Description attributes: Ref. Section: 1253 ippget-event-time-to-live (integer(0:MAX)) RFC NNNN 8.1 1255 The resulting attribute registration will be published in the 1256 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attributes/ 1257 area. 1259 14.4 Status code Registrations 1261 The following table lists the status code defined in this document. 1262 This is to be registered according to the procedures in RFC 2911 1263 [RFC2911] section 6.6. 1265 Status codes: Ref. Section: 1266 redirection-other-site (0x0300) RFC NNNN 10.1 1267 The resulting status code registration will be published in the 1268 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/status-codes/ 1269 area. 1271 15 Internationalization Considerations 1273 The IPP Printer MUST localize the "notify-text" attribute as 1274 specified in section 14 of [ipp-ntfy]. 1276 In addition, when the client receives the Get-Notifications response, 1277 it is expected to localize the attributes that have the 'keyword' 1278 attribute syntax according to the charset and natural language 1279 requested in the Get-Notifications request. 1281 16 Security Considerations 1283 The IPP Model and Semantics document [RFC2911] discusses high-level 1284 security requirements (Client Authentication, Server Authentication 1285 and Operation Privacy). Client Authentication is the mechanism by 1286 which the client proves its identity to the server in a secure 1287 manner. Server Authentication is the mechanism by which the server 1288 proves its identity to the client in a secure manner. Operation 1289 Privacy is defined as a mechanism for protecting operations from 1290 eavesdropping. 1292 Unlike other Event Notification delivery methods in which the IPP 1293 Printer initiates the Event Notification, with the method defined in 1294 this document, the Notification Recipient is the client who s the 1295 Get-Notifications operation. Therefore, there is no chance of "spam" 1296 notifications with this method. Furthermore, such a client can close 1297 down the HTTP channel at any time, and so can avoid future unwanted 1298 Event Notifications at any time. 1300 17 References 1302 [ipp-iig] 1303 Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P., 1304 "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers- 1305 guide-v11-03.txt, work in progress, July 17, 2001 1307 [ipp-ntfy] 1308 R. Herriot, Hastings, T., Isaacson, S., Martin, J., deBry, R., 1309 Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP 1310 Event Notifications and Subscriptions", , July 17, 2001. 1313 [RFC1900] 1314 B. Carpenter, Y. Rekhter. Renumbering Needs Work, RFC 1900, 1315 February 1996. 1317 [RFC2026] 1318 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 1319 2026, October 1996. 1321 [RFC2119] 1322 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1323 Levels", RFC 2119 , March 1997 1325 [RFC2368] 1326 P. Hoffman, L. Masinter, J. Zawinski. The "mailto" URL Scheme, RFC 1327 2368, July 1998. 1329 [RFC2373] 1330 R. Hinden, S. Deering. IP Version 6 Addressing Architecture, RFC 1331 2373, July 1998. 1333 [RFC2396] 1334 Berners-Lee, T. et al. Uniform Resource Identifiers (URI): Generic 1335 Syntax, RFC 2396, August 1998 1337 [RFC2565] 1338 Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet 1339 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1340 1999. 1342 [RFC2566] 1343 R. deBry, T. Hastings, R. Herriot, S. Isaacson, and P. Powell, 1344 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1345 April 1999. 1347 [RFC2567] 1348 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1349 2567, April 1999. 1351 [RFC2568] 1352 Zilles, S., "Rationale for the Structure and Model and Protocol for 1353 the Internet Printing Protocol", RFC 2568, April 1999. 1355 [RFC2569] 1356 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1357 LPD and IPP Protocols", RFC 2569, April 1999. 1359 [RFC2616] 1360 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1361 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1362 RFC 2616, June 1999. 1364 [RFC2717] 1365 R. Petke and I. King, "Registration Procedures for URL Scheme 1366 Names", RFC 2717, November 1999. 1368 [RFC2732] 1369 R. Hinden, B. Carpenter, L. Masinter. Format for Literal IPv6 1370 Addresses in URL's, RFC 2732, December 1999. 1372 [RFC2910] 1373 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1374 Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 1376 [RFC2911] 1377 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1378 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 1379 September 2000. 1381 18 Authors' Addresses 1383 Robert Herriot 1384 Xerox Corp. 1385 3400 Hill View Ave, Building 1 1386 Palo Alto, CA 94304 1388 Phone: 650-813-7696 1389 Fax: 650-813-6860 1390 e-mail: robert.herriot@pahv.xerox.com 1392 Carl Kugler 1393 IBM 1394 P.O. Box 1900 1395 Boulder, CO 80301-9191 1397 Phone: 1398 Fax: 1399 e-mail: kugler@us.ibm.com 1400 Harry Lewis 1401 IBM 1402 P.O. Box 1900 1403 Boulder, CO 80301-9191 1405 Phone: 303-924-5337 1406 FAX: 1407 e-mail: harryl@us.ibm.com 1409 IPP Web Page: http://www.pwg.org/ipp/ 1410 IPP Mailing List: ipp@pwg.org 1412 To subscribe to the ipp mailing list, send the following email: 1413 1) send it to majordomo@pwg.org 1414 2) leave the subject line blank 1415 3) put the following two lines in the message body: 1416 subscribe ipp 1417 end 1419 Implementers of this specification document are encouraged to join 1420 the IPP Mailing List in order to participate in any discussions of 1421 clarification issues and review of registration proposals for 1422 additional attributes and values. In order to reduce spam the 1423 mailing list rejects mail from non-subscribers, so you must subscribe 1424 to the mailing list in order to send a question or comment to the 1425 mailing list. 1427 19 Description of Base IPP documents 1429 The base set of IPP documents includes: 1431 Design Goals for an Internet Printing Protocol [RFC2567] 1432 Rationale for the Structure and Model and Protocol for the Internet 1433 Printing Protocol [RFC2568] 1434 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 1435 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 1436 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 1437 Mapping between LPD and IPP Protocols [RFC2569] 1438 Internet Printing Protocol (IPP): IPP Event Notifications and 1439 Subscriptions [ipp-ntfy] 1441 The "Design Goals for an Internet Printing Protocol" document takes a 1442 broad look at distributed printing functionality, and it enumerates 1443 real-life scenarios that help to clarify the features that need to be 1444 included in a printing protocol for the Internet. It identifies 1445 requirements for three types of users: end users, operators, and 1446 administrators. It calls out a subset of end user requirements that 1447 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 1448 been added to IPP/1.1. 1450 The "Rationale for the Structure and Model and Protocol for the 1451 Internet Printing Protocol" document describes IPP from a high level 1452 view, defines a roadmap for the various documents that form the suite 1453 of IPP specification documents, and gives background and rationale 1454 for the IETF working group's major decisions. 1456 The "Internet Printing Protocol/1.1: Model and Semantics" document 1457 describes a simplified model with abstract objects, their attributes, 1458 and their operations that are independent of encoding and transport. 1459 It introduces a Printer and a Job object. The Job object optionally 1460 supports multiple documents per Job. It also addresses security, 1461 internationalization, and directory issues. 1463 The "Internet Printing Protocol/1.1: Encoding and Transport" document 1464 is a formal mapping of the abstract operations and attributes defined 1465 in the model document onto HTTP/1.1 [RFC2616]. It defines the 1466 encoding rules for a new Internet MIME media type called 1467 "application/ipp". This document also defines the rules for 1468 transporting over HTTP a message body whose Content-Type is 1469 "application/ipp". This document defines the 'ippget' scheme for 1470 identifying IPP printers and jobs. 1472 The "Internet Printing Protocol/1.1: Implementer's Guide" document 1473 gives insight and advice to implementers of IPP clients and IPP 1474 objects. It is intended to help them understand IPP/1.1 and some of 1475 the considerations that may assist them in the design of their client 1476 and/or IPP object implementations. For example, a typical order of 1477 processing requests is given, including error checking. Motivation 1478 for some of the specification decisions is also included. 1480 The "Mapping between LPD and IPP Protocols" document gives some 1481 advice to implementers of gateways between IPP and LPD (Line Printer 1482 Daemon) implementations. 1484 The "IPP Event Notifications and Subscriptions" document defines an 1485 extension to IPP/1.0 [RFC2566, RFC2565] and IPP/1.1 [RFC2911, 1486 RFC2910]. This extension allows a client to subscribe to printing 1487 related Events and defines the semantics for delivering asynchronous 1488 Event Notifications to the specified Notification Recipient via a 1489 specified Delivery Method (i.e., protocols) defined in (separate) 1490 Delivery Method documents. 1492 20 Full Copyright Statement 1494 Copyright (C) The Internet Society (2001). All Rights Reserved. 1496 This document and translations of it may be copied and furnished to 1497 others, and derivative works that comment on or otherwise explain it 1498 or assist in its implementation may be prepared, copied, published 1499 and distributed, in whole or in part, without restriction of any 1500 kind, provided that the above copyright notice and this paragraph are 1501 included on all such copies and derivative works. However, this 1502 document itself may not be modified in any way, such as by removing 1503 the copyright notice or references to the Internet Society or other 1504 Internet organizations, except as needed for the purpose of 1505 developing Internet standards in which case the procedures for 1506 copyrights defined in the Internet Standards process must be 1507 followed, or as required to translate it into languages other than 1508 English. 1510 The limited permissions granted above are perpetual and will not be 1511 revoked by the Internet Society or its successors or assigns. 1513 This document and the information contained herein is provided on an 1514 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1515 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1516 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1517 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1518 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1520 Acknowledgement 1522 Funding for the RFC Editor function is currently provided by the 1523 Internet Society.