idnits 2.17.1 draft-ietf-ipp-notify-poll-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 8) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 81: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 195: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 196: '...Y, NEED NOT, and OPTIONAL, have specia...' RFC 2119 keyword, line 220: '...client MUST choose a value for the add...' RFC 2119 keyword, line 224: '...urs, the Printer MUST generate an Even...' (68 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 696 has weird spacing: '...ent who s th...' == Line 779 has weird spacing: '...for the purpo...' -- 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 (August 15, 2000) is 8652 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: 'RFC2567' is mentioned on line 65, but not defined == Missing Reference: 'RFC2568' is mentioned on line 67, but not defined == Missing Reference: 'RFC2569' is mentioned on line 71, but not defined == Missing Reference: 'RFC2119' is mentioned on line 199, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Robert Herriot 3 Xerox Corp. 4 Tom Hastings 5 Xerox Corp. 6 Carl-Uno Manros 7 Xerox Corp. 8 Harry Lewis 9 IBM, Corp. 10 August 15, 2000 11 Internet Printing Protocol (IPP): 12 The 'ipp-get' Notification Polling Method 14 Copyright (C) The Internet Society (2000). All Rights Reserved. 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of [rfc2026]. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed as 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The notification extension document [ipp-ntfy] defines operations that a 38 client can perform in order to create Subscription Objects in a Printer 39 and carry out other operations on them. A Subscription Object represents 40 a Subscription abstraction. The Subscription Object specifies that when 41 one of the specified Events occurs, the Printer sends an asynchronous 42 Event Notification to the specified Notification Recipient via the 43 specified Delivery Method (i.e., protocol). 45 The notification extension document [ipp-ntfy] specifies that each 46 Delivery Method is defined in another document. This document is one 47 such document, and it specifies the 'ipp-get' delivery method. 49 The 'ipp-get' Delivery Method is a 'pull' Delivery Method. That is, the 50 Printer saves Event Notification for a period of time and expects the 51 Notification Recipient to fetch the Event Notifications. 53 When a Printer supports this Delivery Method, it holds each Event 54 Notification for an amount of time, called the Event Notification Lease 55 Time. 57 When a Notification Recipient wants to receive Event Notifications, it 58 performs an IPP operation called 'Get-Notifications', which this 59 document defines. This operation causes the Printer to return all Event 60 Notifications held for the Notification Recipient along with information 61 that tells the client when to perform this operation again. 63 The full set of IPP documents includes: 65 Design Goals for an Internet Printing Protocol [RFC2567] 66 Rationale for the Structure and Model and Protocol for the Internet 67 Printing Protocol [RFC2568] 68 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 69 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 70 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 71 Mapping between LPD and IPP Protocols [RFC2569] 72 Internet Printing Protocol/1.0 & 1.1: IPP Event Notification 73 Specification [ipp-ntfy] 75 The "Design Goals for an Internet Printing Protocol" document takes a 76 broad look at distributed printing functionality, and it enumerates 77 real-life scenarios that help to clarify the features that need to be 78 included in a printing protocol for the Internet. It identifies 79 requirements for three types of users: end users, operators, and 80 administrators. It calls out a subset of end user requirements that are 81 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 82 added to IPP/1.1. 84 The "Rationale for the Structure and Model and Protocol for the Internet 85 Printing Protocol" document describes IPP from a high level view, 86 defines a roadmap for the various documents that form the suite of IPP 87 specification documents, and gives background and rationale for the IETF 88 working group's major decisions. 90 The "Internet Printing Protocol/1.1: Model and Semantics" document 91 describes a simplified model with abstract objects, their attributes, 92 and their operations that are independent of encoding and transport. It 93 introduces a Printer and a Job object. The Job object optionally 94 supports multiple documents per Job. It also addresses security, 95 internationalization, and directory issues. 97 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 98 a formal mapping of the abstract operations and attributes defined in 99 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 100 rules for a new Internet MIME media type called "application/ipp". This 101 document also defines the rules for transporting over HTTP a message 102 body whose Content-Type is "application/ipp". This document defines a 103 new scheme named 'ipp-get' for identifying IPP printers and jobs. 105 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 106 insight and advice to implementers of IPP clients and IPP objects. It 107 is intended to help them understand IPP/1.1 and some of the 108 considerations that may assist them in the design of their client and/or 109 IPP object implementations. For example, a typical order of processing 110 requests is given, including error checking. Motivation for some of the 111 specification decisions is also included. 113 The "Mapping between LPD and IPP Protocols" document gives some advice 114 to implementers of gateways between IPP and LPD (Line Printer Daemon) 115 implementations. 117 The "Event Notification Specification" document describes an extension 118 to the IPP/1.0, IPP/1.1, and future versions. This extension allows a 119 client to subscribe to printing related Events. Subscriptions are 120 modeled as Subscription Objects. The Subscription Object specifies that 121 when one of the specified Event occurs, the Printer sends an 122 asynchronous Event Notification to the specified Notification Recipient 123 via the specified Delivery Method (i.e., protocol). A client associates 124 Subscription Objects with a particular Job by performing the Create-Job- 125 Subscriptions operation or by submitting a Job with subscription 126 information. A client associates Subscription Objects with the Printer 127 by performing a Create-Printer-Subscriptions operation. Four other 128 operations are defined for Subscription Objects: Get-Subscriptions- 129 Attributes, Get-Subscriptions, Renew-Subscription, and Cancel- 130 Subscription. 132 Table of Contents 134 1 Introduction......................................................6 136 2 Terminology.......................................................6 138 3 Model and Operation...............................................6 140 4 General Information...............................................8 142 5 Get-Notifications operation.......................................8 143 5.1 GET-NOTIFICATIONS REQUEST......................................9 144 5.2 GET-NOTIFICATIONS RESPONSE....................................10 146 6 Extensions to Subscription Creation Operations...................14 147 6.1 RESPONSE......................................................14 149 7 Encoding.........................................................14 151 8 IANA Considerations..............................................15 153 9 Internationalization Considerations..............................15 155 10 Security Considerations..........................................15 157 11 References.......................................................15 159 12 Authors' Addresses...............................................16 161 13 Full Copyright Statement.........................................16 162 1 Introduction 164 The notification extension document [ipp-ntfy] defines operations that a 165 client can perform in order to create Subscription Objects in a Printer 166 and carry out other operations on them. A Subscription Object represents 167 a Subscription abstraction. The Subscription Object specifies that when 168 one of the specified Events occurs, the Printer sends an asynchronous 169 Event Notification to the specified Notification Recipient via the 170 specified Delivery Method (i.e., protocol). 172 The notification extension document [ipp-ntfy] specifies that each 173 Delivery Method is defined in another document. This document is one 174 such document, and it specifies the 'ipp-get' delivery method. 176 The 'ipp-get' Delivery Method is a 'pull' Delivery Method. That is, the 177 Printer saves Event Notification for a period of time and expects the 178 Notification Recipient to fetch the Event Notifications. 180 When a Printer supports this Delivery Method, it holds each Event 181 Notification for an amount of time, called the Event Notification Lease 182 Time. 184 When a Notification Recipient wants to receive Event Notifications, it 185 performs an IPP operation called 'Get-Notifications', which this 186 document defines. This operation causes the Printer to return all Event 187 Notifications held for the Notification Recipient along with information 188 that tells the client when to perform this operation again. 190 2 Terminology 192 This section defines the following terms that are used throughout this 193 document: 195 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 196 MAY, NEED NOT, and OPTIONAL, have special meaning relating to 197 conformance to this specification. These terms are defined in [ipp-mod 198 section 13.1 on conformance terminology, most of which is taken from RFC 199 2119 [RFC2119]. 201 Event Notification Lease: The lease that is associated with an Event 202 Notification. When the lease expires, the Printer discards the 203 associated Event Notification. 205 Event Notification Lease Time: The expiration time assigned to a lease 206 that is associated with an Event Notification. 208 Event Notification Attributes Group: The attributes group in a response 209 that contains attributes that are part of an Event Notification. 211 For other capitalized terms that appear in this document, see [ipp- 212 ntfy]. 214 3 Model and Operation 216 In a Subscription Creation Operation, when the value of the "notify- 217 recipient-uri" attributes has the scheme "ipp-get", the client is 218 requesting that the Printer use the 'ipp-get' Delivery Method for the 219 Event Notifications associated with the new Subscription Object. The 220 client MUST choose a value for the address part of the "notify- 221 recipient-uri" attribute that uniquely identifies the Notification 222 Recipient. 224 When an Event occurs, the Printer MUST generate an Event Notification 225 and MUST assign it an Event Notification Lease Time. The Printer MUST 226 hold an Event Notification for its assigned Event Notification Lease 227 Time and MUST discard it when its Event Notification Lease Time expires. 228 The Printer MAY assign the same Event Notification Lease Time to each 229 Event Notification or it MAY assign a different time. 231 When a Notification Recipient wants to receive Event Notifications, it 232 performs the Get-Notifications operation, which causes the Printer to 233 return all unexpired Event Notifications held for the Notification 234 Recipient along with two time-intervals. 236 The first returned time-interval is the suggested time a Notification 237 Recipient should wait before performing the Get-Notifications operation 238 again. The second time-interval is the time that Event Notification 239 Leases begin to expire for Event Notifications created after the Get- 240 Notifications operation. A Notification Recipient SHOULD perform this 241 operation at the suggested time and somewhat before the Event 242 Notification Leases begin to expire. 244 The Notification Recipient identifies its own Event Notifications with a 245 "notify-recipient-uri" Operation attribute in the request. It matches 246 any Event Notifications associated with a Subscription Object whose 247 "notify-recipient-uri" attribute has the same value as the "notify- 248 recipient-uri" Operation attribute of the request. To avoid getting 249 Event Notification that belong to another Notification Recipient, a 250 client SHOULD pick values for the "notify-recipient-uri" attribute that 251 are unique, e.g. the client's host address. 253 If a Notification Recipient performs the Get-Notifications operation 254 twice in quick succession, it will receive nearly the same Event 255 Notification both times. There are two possible differences. Some old 256 Event Notifications may not be present in the second response because 257 their Event Notification Leases have expired. Some new Event 258 Notifications may be present in the second response but not the first 259 response. 261 The Printer may keep the channel open if the suggested time-interval is 262 sufficiently short, but in any case the client performs a new Get- 263 Notifications operation each time it wants more Event Notifications. 264 Since the time interval between consecutive client requests is normally 265 less than the Event Notification Lease Time, consecutive responses will 266 normally contain some events that are identical. The youngest ones in 267 the previous response will become the oldest in the next response. The 268 client is expected to filter out these duplicates, which is easy to do 269 because of the sequence number in each Event Notification. The reason 270 for not removing the Event Notifications from the Printer with every 271 Get-Notifications request, is so that multiple Notification Recipients 272 can be polling the same Subscription Object and so the Get-Notification 273 operation satisfies the rule of idempotency. The former is useful if 274 someone is logged in to several desktops at the same time and wants to 275 see the same events at both places. The latter is useful if the network 276 loses the response. 278 4 General Information 280 According to the notification extension document [ipp-ntfy], this 281 document MUST contain the following information: 283 1.The URL scheme name for the Delivery Method is: 'ipp-get' 285 2.Printer support for this delivery method is OPTIONAL. 287 3.For Event Notification content, a Printer MUST use the following 288 transport and delivery protocol, i.e., entire network stack: IPP 289 with one new operation. 291 4.Several Event Notifications can be combined into a compound Event 292 Notification. See section 5. 294 5.The Notification Recipient MUST initiate the Delivery Method 296 6.The Delivery Method is Machine Consumable. 298 7.The representation and encoding for each value is the same as for IPP 299 (see section 5). 301 8.In the Event Notification content, a Printer MUST send all attributes 302 specified in section 5. 304 9.Frequently occurring Events NEED NOT be moderated because the 305 Delivery Method is a 'pull' Delivery Method. An implementation of the 306 Get-Notifications operation SHOULD consider how often it recommends a 307 Notification Recipient to poll again. 309 10. This Delivery Method has the same latency and reliability as the 310 underlying HTTP transport. 312 11. This Delivery Method has the same security aspects as the 313 underlying HTTP transport. 315 12. This Delivery Method has no content length restrictions. 317 13. There are no additional values that a Printer MUST send in a 318 Notification content. 320 14. There are no additional Subscription Template and/or Subscription 321 Description attributes. 323 15. There are no additional Printer Description attributes. 325 5 Get-Notifications operation 327 This operation causes the Printer to return all Event Notifications held 328 for the Notification Recipient along with information about when to 329 perform this operation again. 331 A Printer MUST support this operation. 333 When a Printer performs this operation, it MUST return all and only 334 those Event Notifications: 336 a)Whose associated Subscription Object's "notify-recipient-uri" 337 attribute equals the "notify-recipient-uri" Operation attribute 338 AND 340 b)Whose associated Subscription Object's "notify-recipient-uri" 341 attribute has a scheme value of 'ipp-get' AND 343 c)Whose Event Notification Lease Time has not yet expired AND 345 d)Where the Notification Recipient is the owner of or has read- 346 access rights to the associated Subscription Object. 348 When a Printer performs this operation, it MUST also return two time- 349 intervals: 351 a)the suggested time for a Notification Recipient to perform the 352 Get-Notifications operation again. 354 b)the time at which the Printer will begin to discard Event 355 Notifications that occur after this operation. This may be the 356 Event Notification Lease Time (see section 5.2 for details). 358 Note: the Subscription Creation Operations also return these two time- 359 intervals (see section 6). 361 The Printer MUST respond to this operation immediately with whatever 362 Event Notifications it currently holds. It MUST NOT wait for additional 363 Events to occur before sending a response. 365 The Printer MUST accept the request in any state (see [ipp-mod] 366 "printer-state" and "printer-state-reasons" attributes) and MUST remain 367 in the same state with the same "printer-state-reasons". 369 Access Rights: If the policy of the Printer is to allow all users to 370 access all Event Notifications, then the Printer MUST accept this 371 operation from any user. Otherwise, the authenticated user (see [ipp- 372 mod] section 8.3) performing this operation MUST either be the owner of 373 each Subscription Object identified by the "notify-recipient-uri" 374 Operation attribute (as determined during a Subscription Creation 375 Operation) or an operator or administrator of the Printer (see [ipp-mod] 376 Sections 1 and 8.5). Otherwise, the IPP object MUST reject the 377 operation and return: 'client-error-forbidden', 'client-error-not- 378 authenticated', or 'client-error-not-authorized' as appropriate. 380 5.1 Get-Notifications Request 382 The following groups of attributes are part of the Get-Notifications 383 Request: 385 Group 1: Operation Attributes 387 Natural Language and Character Set: 388 The "attributes-charset" and "attributes-natural-language" 389 attributes as described in [ipp-mod] section 3.1.4.1. 391 Target: 392 The "printer-uri" (uri) operation attribute which is the target for 393 this operation as described in [ipp-mod] section 3.1.5. 395 Requesting User Name: 396 The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied 397 by the client as described in [ipp-mod] section 8.3. 399 "notify-recipient-uri" (url): 400 The client MUST supply this attribute. The Printer object MUST 401 support this attribute. The Printer matches the value of this 402 attribute (byte for byte with no case conversion) against the value 403 of the "notify-recipient-uri" in each Subscription Object in the 404 Printer. If there are no matches, the IPP Printer MUST return the 405 'client-error-not-found' status code. For each matched 406 Subscription Object, the IPP Printer MUST return all unexpired 407 Event Notifications associated with it. 409 Note: this attribute allows a subscribing client to pick URLs that 410 are unique, e.g. the client's own URL or a friend's URL, which in 411 both cases is likely the URL of the person's host. An application 412 could make a URL unique for each application. 414 5.2 Get-Notifications Response 416 The following groups of attributes are part of the Get-Notifications 417 Response: 419 Group 1: Operation Attributes 421 Status Message: 422 In addition to the REQUIRED status code returned in every response, 423 the response OPTIONALLY includes a "status-message" (text(255)) 424 and/or a "detailed-status-message" (text(MAX)) operation attribute 425 as described in [ipp-mod] sections 13 and 3.1.6. 427 The Printer can return any status codes defined in [ipp-mod]. The 428 following is a description of the important status codes: 430 successful-ok: the response contains all Event Notification 431 associated with the specified "notify-recipient-uri". If the 432 specified Subscription Objects have no associated Event 433 Notification, the response MUST contain zero Event 434 Notifications. 435 client-error-not-found: The Printer has no Subscription Object's 436 whose "notify-recipient-uri" attribute equals the "notify- 437 recipient-uri" Operation attribute. 439 Natural Language and Character Set: 440 The "attributes-charset" and "attributes-natural-language" 441 attributes as described in [ipp-mod] section 3.1.4.2. 443 The Printer MUST use the values of "notify-charset" and "notify- 444 natural-language", respectively, from one Subscription Object 445 associated with the Event Notifications in this response. 447 Normally, there is only one matched Subscription Object, or the 448 value of the "notify-charset" and "notify-natural-language" 449 attributes is the same in all Subscription Objects. If not, the 450 Printer MUST pick one Subscription Object from which to obtain the 451 value of these attributes. The algorithm for picking the 452 Subscription Object is implementation dependent. The choice of 453 natural language is not critical because 'text' and 'name' values 454 can override the "attributes-natural-language" Operation attribute. 455 The Printer's choice of charset is critical because a bad choice 456 may leave it unable to send some 'text' and 'name' values 457 accurately. 459 "suggested-ask-again-time-interval" (integer(0:MAX)): 460 The value of this attribute is the suggested number of seconds that 461 SHOULD elapse before the client performs the Get-Notifications 462 operation again for these Subscription Objects. A client MAY 463 perform the Get-Notifications operation at any time, and a Printer 464 MUST respond with all unexpired Event Notifications. A Notification 465 Recipient waits until this time interval has elapsed in order to be 466 a "good network citizen". It is RECOMMENDED that the value of this 467 attribute be 80% of the "begin-to-expire-time-interval" (see the 468 next attribute) in order to give a Notification Recipient plenty of 469 time to perform the Get-Notifications operation again before new 470 Event Notifications expire. 472 "begin-to-expire-time-interval" (integer(0:MAX)): 473 The value of this attribute is the minimum number of seconds that 474 MUST elapse before Event Notification Leases begin to expire on 475 Event Notifications produced by matching Subscriptions Objects 476 after the Printer sends the Get-Notifications response. The Printer 477 MUST discard an Event Notification when its Event Notification 478 Lease has expired. That is, if the Printer performs the Get- 479 Notifications operation before the time specified by the "begin-to- 480 expire-time-interval" attribute returned in the previous operation, 481 the Printer MUST still have all of the Event Notifications that 482 have occurred since the previous operation. If the Printer assigns 483 the same Event Notification Lease Time to all Event Notifications, 484 the value of this attribute MUST equal the Event Notification Lease 485 Time. If a Notification Recipient waits until after this time or 486 even slightly less than this time, the Notification Recipient MUST 487 expect to lose some Event Notifications. 489 "printer-up-time" (integer(0:MAX)): 490 The value of this attribute is the Printer's "printer-up-time" 491 attribute at the time the Printer sends this response. Because each 492 Event Notification also contains the value of this attribute when 493 the event occurred, the value of this attribute lets a Notification 494 Recipient know when each Event Notification occurred relative to 495 the time of this response. 497 Group 2: Unsupported Attributes 499 See [ipp-mod] section 3.1.7 for details on returning Unsupported 500 Attributes. 502 If the "subscription-ids" attribute contained subscription-ids that 503 do not exist, the Printer returns them in this group as value of 504 the "subscription-ids" attribute. 506 Group 3 through N: Event Notification Attributes 507 The Printer responds with one Event Notification Attributes Group 508 per matched Event Notification. The matched Event Notifications are 509 all un-expired Event Notification associated with the matched 510 Subscription Objects. Each Event Notification Group MUST start with 511 an 'event-notification-attributes-tag' (see the section "Encodings 512 of Additional Attribute Tags" in [ipp-ntfy]). 514 Each attribute is encoded using the IPP rules for encoding 515 attributes [ipp-pro] and may be encoded in any order. Note: the 516 Get-Jobs response in [ipp-mod] acts as a model for encoding 517 multiple groups of attributes. 519 Each Event Notification Group MUST contain all of attributes 520 specified in section 9.1 ("Content of Machine Consumable Event 521 Notifications") of [ipp-ntfy] with exceptions denoted by asterisks 522 in the tables below. 524 The tables below are copies of the tables in section 9.1 ("Content 525 of Machine Consumable Event Notifications") of [ipp-ntfy] except 526 that each cell in the "Sends" column is a "MUST". 528 For an Event Notification for all Events, the Printer includes the 529 following attributes. 531 Table 1 . Attributes in Event Notification Content 533 Source Value Sends Source Object 535 notify-subscription-id (integer(1:MAX)) MUST Subscription 537 notify-printer-uri (uri) MUST Subscription 539 notify-subscribed-event (type2 keyword) MUST Event 540 Notification 542 printer-up-time (integer(MIN:MAX)) MUST Printer 544 printer-current-time (dateTime)* MUST Printer 546 notify-sequence-number (integer (0:MAX)) MUST Subscription 548 notify-charset (charset) MUST Subscription 550 notify-natural-language (naturalLanguage) MUST Subscription 552 notify-user-data (octetString(63)) ** MUST Subscription 554 notify-text (text) MUST Event 555 Notification 557 attributes from the "notify-attributes" MUST Printer 558 attribute *** 560 attributes from the "notify-attributes" MUST Job 561 attribute *** 562 Source Value Sends Source Object 564 attribute *** 566 attributes from the "notify-attributes" MUST Subscription 567 attribute *** 569 * The Printer MUST send "printer-current-time" if and only if it 570 supports the "printer-current-time" attribute on the Printer 571 object. 573 ** If the associated Subscription Object does not contain a 574 "notify-user-data" attribute, the Printer MUST send an octet-string 575 of length 0. 577 *** If the "notify-attributes" attribute is present on the 578 Subscription Object, the Printer MUST send all attributes specified 579 by the "notify-attributes" attribute. Note: if the Printer doesn't 580 support the "notify-attributes" attribute, it is not present on the 581 associated Subscription Object. 583 For Event Notifications for Job Events, the Printer includes the 584 following additional attributes. 586 Table 2 . Additional Attributes in Event Notification Content for 587 Job Events 589 Source Value Sends Source Object 591 job-id (integer(1:MAX)) MUST Job 593 job-state (type1 enum) MUST Job 595 job-state-reasons (1setOf type2 keyword) MUST Job 597 job-impressions-completed MUST Job 598 (integer(0:MAX)) * 600 * The Printer MUST send the "job-impressions-completed" attribute 601 in an Event Notification only for the combinations of Events and 602 Subscribed Events shown in Table 3. 604 Table 3 . Combinations of Events and Subscribed Events for "job- 605 impressions-completed" 607 Job Event Subscribed Job Event 609 'job-progress' 'job-progress' 611 'job-completed' 'job-completed' 613 'job-completed' 'job-state-changed' 614 For Event Notification for Printer Events, the Printer includes the 615 following additional attributes. 617 Table 4 . Additional Attributes in Event Notification Content for 618 Printer Events 620 Source Value Sends Source Object 622 printer-state (type1 enum) MUST Printer 624 printer-state-reasons (1setOf type2 MUST Printer 625 keyword) 627 printer-is-accepting-jobs (boolean) MUST Printer 629 6 Extensions to Subscription Creation Operations 631 6.1 Response 633 When a Subscription Creation Operation contains a "notify-recipient-uri" 634 attribute and the scheme in its value is 'ipp-get', the response MUST 635 contain two additional Operation Attributes that pertain to this 636 Delivery Method. Note: Subscription Creation Operations include: Print- 637 Job, Print-URI, Create-Job, Create-Job-Subscriptions and Create-Printer- 638 Subscriptions. 640 Group 1: Operation Attributes 642 "suggested-ask-again-time-interval" (integer(0:MAX)): 643 This attribute has the same meaning as the "suggested-ask-again- 644 time-interval" attribute in the Get-Notifications operation except 645 that it suggests when to perform the Get-Notifications operation 646 for the first time on all Subscription Objects in the response 647 whose "notify-recipient-uri" scheme is 'ipp-get'. 649 "begin-to-expire-time-interval" (integer(0:MAX)): 650 This attribute has the same meaning as the "begin-to-expire-time- 651 interval" attribute in the Get-Notifications operation except that 652 it indicates when the Event Notification Lease begins to expire for 653 all Subscription Objects in the response whose "notify-recipient- 654 uri" scheme is 'ipp-get'. 656 7 Encoding 658 The operation-id assigned for the Get-Notifications operation is: 660 0x001C 662 and should be added to the next version of [ipp-mod] section 4.4.15 663 "operations-supported". 665 This notification delivery method uses the IPP transport and encoding 666 [ipp-pro] for the Get-Notifications operation with one extension: 668 notification-attributes-tag = %x07; tag of 7 670 8 IANA Considerations 672 There is nothing to register. 674 9 Internationalization Considerations 676 The IPP Printer MUST localize the "notify-text" attribute as specified 677 in section 14 of [ipp-ntfy]. 679 In addition, when the client receives the Get-Notifications response, it 680 is expected to localize the attributes that have the 'keyword' attribute 681 syntax according to the charset and natural language requested in the 682 Get-Notifications request. 684 10 Security Considerations 686 The IPP Model and Semantics document [ipp-mod] discusses high-level 687 security requirements (Client Authentication, Server Authentication and 688 Operation Privacy). Client Authentication is the mechanism by which the 689 client proves its identity to the server in a secure manner. Server 690 Authentication is the mechanism by which the server proves its identity 691 to the client in a secure manner. Operation Privacy is defined as a 692 mechanism for protecting operations from eavesdropping. 694 Unlike other Event Notification delivery methods in which the IPP 695 Printer initiates the Event Notification, with the method defined in 696 this document, the Notification Recipient is the client who s the Get- 697 Notifications operation. Therefore, there is no chance of "spam" 698 notifications with this method. Furthermore, such a client can close 699 down the HTTP channel at any time, and so can avoid future unwanted 700 Event Notifications at any time. 702 11 References 704 [ipp-mod] 705 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 706 "Internet Printing Protocol/1.1: Model and Semantics", , May 22, 2000. 709 [ipp-ntfy] 710 R. Herriot, Hastings, T., Isaacson, S., Martin, J., deBry, R., 711 Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP 712 Event Notification Specification", , July 13, 2000. 715 [ipp-pro] 716 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 717 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 718 06.txt, May 30, 2000. 720 [rfc2026] 721 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 722 2026, October 1996. 724 [RFC2616] 725 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 726 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 727 RFC 2616, June 1999. 729 12 Authors' Addresses 731 Robert Herriot 732 Xerox Corp. 733 3400 Hill View Ave, Building 1 734 Palo Alto, CA 94304 736 Phone: 650-813-7696 737 Fax: 650-813-6860 738 e-mail: robert.herriot@pahv.xerox.com 740 Tom Hastings 741 Xerox Corporation 742 737 Hawaii St. ESAE 231 743 El Segundo, CA 90245 745 Phone: 310-333-6413 746 Fax: 310-333-5514 747 e-mail: hastings@cp10.es.xerox.com 749 Carl-Uno Manros 750 Xerox Corporation 751 701 Aviation Blvd. 752 El Segundo, CA 90245 754 Phone: 310-333-8273 755 Fax: 310-333-5514 756 e-mail: manros@cp10.es.xerox.com 758 Harry Lewis 759 IBM 760 P.O. Box 1900 761 Boulder, CO 80301-9191 763 Phone: (303) 924-5337 764 FAX: 765 e-mail: harryl@us.ibm.com 767 13 Full Copyright Statement 769 Copyright (C) The Internet Society (2000). All Rights Reserved. 771 This document and translations of it may be copied and furnished to 772 others, and derivative works that comment on or otherwise explain it or 773 assist in its implementation may be prepared, copied, published and 774 distributed, in whole or in part, without restriction of any kind, 775 provided that the above copyright notice and this paragraph are included 776 on all such copies and derivative works. However, this document itself 777 may not be modified in any way, such as by removing the copyright notice 778 or references to the Internet Society or other Internet organizations, 779 except as needed for the purpose of developing Internet standards in 780 which case the procedures for copyrights defined in the Internet 781 Standards process must be followed, or as required to translate it into 782 languages other than English. 784 The limited permissions granted above are perpetual and will not be 785 revoked by the Internet Society or its successors or assigns. 787 This document and the information contained herein is provided on an "AS 788 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 789 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 790 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 791 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 792 FITNESS FOR A PARTICULAR PURPOSE.