idnits 2.17.1 draft-ietf-ipp-notify-poll-01.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? ** 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 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 194: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 195: '...Y, NEED NOT, and OPTIONAL, have specia...' RFC 2119 keyword, line 219: '...client MUST choose a value for the add...' RFC 2119 keyword, line 223: '...urs, the Printer MUST generate an Even...' (70 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 693 has weird spacing: '...ent who s th...' == Line 776 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 (July 7, 2000) is 8693 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 198, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 8 errors (**), 0 flaws (~~), 8 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 July 7, 2000 11 Internet Printing Protocol (IPP): 12 The 'ipp-get' Delivery 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 ...............................................7 140 4 Get-Notifications operation .......................................8 141 4.1 GET-NOTIFICATIONS REQUEST.......................................11 142 4.2 GET-NOTIFICATIONS RESPONSE......................................11 144 5 Extensions to Print-Job, Print-URI, Create-Job, Create-Printer- 145 Subscription and Create-Printer-Subscription.........................16 146 5.1 RESPONSE........................................................16 148 6 Encoding .........................................................17 150 7 IANA Considerations ..............................................17 152 8 Internationalization Considerations ..............................17 154 9 Security Considerations ..........................................17 156 10 References .......................................................18 158 11 Authors' Addresses ...............................................18 160 12 Full Copyright Statement .........................................19 161 1 Introduction 163 The notification extension document [ipp-ntfy] defines operations that a 164 client can perform in order to create Subscription Objects in a Printer 165 and carry out other operations on them. A Subscription Object represents 166 a Subscription abstraction. The Subscription Object specifies that when 167 one of the specified Events occurs, the Printer sends an asynchronous 168 Event Notification to the specified Notification Recipient via the 169 specified Delivery Method (i.e., protocol). 171 The notification extension document [ipp-ntfy] specifies that each 172 Delivery Method is defined in another document. This document is one 173 such document, and it specifies the 'ipp-get' delivery method. 175 The 'ipp-get' Delivery Method is a 'pull' Delivery Method. That is, the 176 Printer saves Event Notification for a period of time and expects the 177 Notification Recipient to fetch the Event Notifications. 179 When a Printer supports this Delivery Method, it holds each Event 180 Notification for an amount of time, called the Event Notification Lease 181 Time. 183 When a Notification Recipient wants to receive Event Notifications, it 184 performs an IPP operation called 'Get-Notifications', which this 185 document defines. This operation causes the Printer to return all Event 186 Notifications held for the Notification Recipient along with information 187 that tells the client when to perform this operation again. 189 2 Terminology 191 This section defines the following terms that are used throughout this 192 document: 194 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 195 MAY, NEED NOT, and OPTIONAL, have special meaning relating to 196 conformance to this specification. These terms are defined in [ipp-mod 197 section 13.1 on conformance terminology, most of which is taken from RFC 198 2119 [RFC2119]. 200 Event Notification Lease: The lease that is associated with an Event 201 Notification. When the lease expires, the Printer discards the 202 associated Event Notification. 204 Event Notification Lease Time: The expiration time assigned to a lease 205 that is associated with an Event Notification. 207 Event Notification Attributes Group: The attributes group in a response 208 that contains attributes that are part of an Event Notification. 210 For other capitalized terms that appear in this document, see [ipp- 211 ntfy]. 213 3 Model and Operation 215 In a Subscription Creation Operation, when the value of the "notify- 216 recipient-uri" attributes has the scheme "ipp-get", the client is 217 requesting that the Printer use the 'ipp-get' Delivery Method for the 218 Event Notifications associated with the new Subscription Object. The 219 client MUST choose a value for the address part of the "notify- 220 recipient-uri" attribute that uniquely identifies the Notification 221 Recipient. 223 When an Event occurs, the Printer MUST generate an Event Notification 224 and MUST assign it an Event Notification Lease Time. The Printer MUST 225 hold an Event Notification for its assigned Event Notification Lease 226 Time and MUST discard it when its Event Notification Lease Time expires. 227 The Printer MAY assign the same Event Notification Lease Time to each 228 Event Notification or it MAY assign a different time. 230 When a Notification Recipient wants to receive Event Notifications, it 231 performs the Get-Notifications operation, which causes the Printer to 232 return all unexpired Event Notifications held for the Notification 233 Recipient along with two time-intervals. 235 The first returned time-interval is the suggested time a Notification 236 Recipient should wait before performing the Get-Notifications operation 237 again. The second time-interval is the time that Event Notification 238 Leases begin to expire for Event Notifications created after the Get- 239 Notifications operation. A Notification Recipient SHOULD perform this 240 operation at the suggested time and somewhat before the Event 241 Notification Leases begin to expire. 243 The Notification Recipient identifies its own Event Notifications with a 244 "notify-recipient-uri" Operation attribute in the request. It matches 245 any Event Notifications associated with a Subscription Object whose 246 "notify-recipient-uri" attribute has the same value as the "notify- 247 recipient-uri" Operation attribute of the request. To avoid getting 248 Event Notification that belong to another Notification Recipient, a 249 client SHOULD pick values for the "notify-recipient-uri" attribute that 250 are unique, e.g. the client's host address. 252 If a Notification Recipient performs the Get-Notifications operation 253 twice in quick succession, it will receive nearly the same Event 254 Notification both times. There are two possible differences. Some old 255 Event Notifications may not be present in the second response because 256 their Event Notification Leases have expired. Some new Event 257 Notifications may be present in the second response but not the first 258 response. 260 The Printer may keep the channel open if the suggested time-interval is 261 sufficiently short, but in any case the client performs a new Get- 262 Notifications operation each time it wants more Event Notifications. 263 Since the time interval between consecutive client requests is normally 264 less than the Event Notification Lease Time, consecutive responses will 265 normally contain some events that are identical. The youngest ones in 266 the previous response will become the oldest in the next response. The 267 client is expected to filter out these duplicates, which is easy to do 268 because of the sequence number in each Event Notification. The reason 269 for not removing the Event Notifications from the Printer with every 270 Get-Notifications request, is so that multiple Notification Recipients 271 can be polling the same Subscription Object and so the Get-Notification 272 operation satisfies the rule of idempotency. The former is useful if 273 someone is logged in to several desktops at the same time and wants to 274 see the same events at both places. The latter is useful if the network 275 loses the response. 277 4 General Information 279 According to the notification extension document [ipp-ntfy], this 280 document MUST contain the following information: 282 1.The URL scheme name for the Delivery Method is: 'ipp-get' 284 2.Printer support for this delivery method is OPTIONAL. 286 3.For Event Notification content, a Printer MUST IPP with one new 287 operation. 289 4.Several Event Notifications MAY be combined into a compound Event 290 Notification. See section 5. 292 5.The Notification Recipient MUST initiate the Delivery Method 294 6.The Delivery Method sends Machine Consumable Event Notifications. 296 7.The representation and encoding for each value MUST be the same as 297 for IPP (see section 5). 299 8.In the Event Notification content, a Printer MUST send all attributes 300 specified in section 5. 302 9.Frequently occurring Events NEED NOT be moderated because the 303 Delivery Method is a 'pull' Delivery Method. An implementation of the 304 Get-Notifications operation SHOULD consider how often it recommends a 305 Notification Recipient to poll again. 307 10. This Delivery Method has the same latency and reliability as the 308 underlying HTTP transport. 310 11. This Delivery Method has the same security aspects as the 311 underlying HTTP transport. 313 12. This Delivery Method has no content length restrictions. 315 13. There are no additional values that a Printer MUST send in a 316 Notification content. 318 14. There are no additional Subscription Template and/or Subscription 319 Description attributes. 321 15. There are no additional Printer Description attributes. 323 5 Get-Notifications operation 325 This operation causes the Printer to return all Event Notifications held 326 for the Notification Recipient along with information about when to 327 perform this operation again. 329 A Printer MUST support this operation. 331 When a Printer performs this operation, it MUST return all and only 332 those Event Notifications: 334 a)Whose associated Subscription Object's "notify-recipient-uri" 335 attribute equals the "notify-recipient-uri" Operation attribute 336 AND 338 b)Whose associated Subscription Object's "notify-recipient-uri" 339 attribute has a scheme value of 'ipp-get' AND 341 c)Whose Event Notification Lease Time has not yet expired AND 343 d)Where the Notification Recipient is the owner of or has read- 344 access rights to the associated Subscription Object. 346 When a Printer performs this operation, it MUST also return two time- 347 intervals: 349 a)the suggested time for a Notification Recipient to perform the 350 Get-Notifications operation again. 352 b)the time at which the Printer will begin to discard Event 353 Notifications that occur after this operation. This may be the 354 Event Notification Lease Time (see section 5.2 for details). 356 Note: the Subscription Creation Operations also return these two time- 357 intervals (see section 6). 359 The Printer MUST respond to this operation immediately with whatever 360 Event Notifications it currently holds. It MUST NOT wait for additional 361 Events to occur before sending a response. 363 The Printer MUST accept the request in any state (see [ipp-mod] 364 "printer-state" and "printer-state-reasons" attributes) and MUST remain 365 in the same state with the same "printer-state-reasons". 367 Access Rights: If the policy of the Printer is to allow all users to 368 access all Event Notifications, then the Printer MUST accept this 369 operation from any user. Otherwise, the authenticated user (see [ipp- 370 mod] section 8.3) performing this operation MUST either be the owner of 371 each Subscription Object identified by the "notify-recipient-uri" 372 Operation attribute (as determined during a Subscription Creation 373 Operation) or an operator or administrator of the Printer (see [ipp-mod] 374 Sections 1 and 8.5). Otherwise, the IPP object MUST reject the 375 operation and return: 'client-error-forbidden', 'client-error-not- 376 authenticated', or 'client-error-not-authorized' as appropriate. 378 5.1 Get-Notifications Request 380 The following groups of attributes are part of the Get-Notifications 381 Request: 383 Group 1: Operation Attributes 385 Natural Language and Character Set: 386 The "attributes-charset" and "attributes-natural-language" 387 attributes as described in [ipp-mod] section 3.1.4.1. 389 Target: 390 The "printer-uri" (uri) operation attribute which is the target for 391 this operation as described in [ipp-mod] section 3.1.5. 393 Requesting User Name: 394 The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied 395 by the client as described in [ipp-mod] section 8.3. 397 "notify-recipient-uri" (url): 398 The client MUST supply this attribute. The Printer object MUST 399 support this attribute. The Printer matches the value of this 400 attribute (byte for byte with no case conversion) against the value 401 of the "notify-recipient-uri" in each Subscription Object in the 402 Printer. If there are no matches, the IPP Printer MUST return the 403 'client-error-not-found' status code. For each matched 404 Subscription Object, the IPP Printer MUST return all unexpired 405 Event Notifications associated with it. 407 Note: this attribute allows a subscribing client to pick URLs that 408 are unique, e.g. the client's own URL or a friend's URL, which in 409 both cases is likely the URL of the person's host. An application 410 could make a URL unique for each application. 412 5.2 Get-Notifications Response 414 The following groups of attributes are part of the Get-Notifications 415 Response: 417 Group 1: Operation Attributes 419 Status Message: 420 In addition to the REQUIRED status code returned in every response, 421 the response OPTIONALLY includes a "status-message" (text(255)) 422 and/or a "detailed-status-message" (text(MAX)) operation attribute 423 as described in [ipp-mod] sections 13 and 3.1.6. 425 The Printer can return any status codes defined in [ipp-mod]. The 426 following is a description of the important status codes: 428 successful-ok: the response contains all Event Notification 429 associated with the specified "notify-recipient-uri". If the 430 specified Subscription Objects have no associated Event 431 Notification, the response MUST contain zero Event 432 Notifications. 433 client-error-not-found: The Printer has no Subscription Object's 434 whose "notify-recipient-uri" attribute equals the "notify- 435 recipient-uri" Operation attribute. 437 Natural Language and Character Set: 438 The "attributes-charset" and "attributes-natural-language" 439 attributes as described in [ipp-mod] section 3.1.4.2. 441 The Printer MUST use the values of "notify-charset" and "notify- 442 natural-language", respectively, from one Subscription Object 443 associated with the Event Notifications in this response. 445 Normally, there is only one matched Subscription Object, or the 446 value of the "notify-charset" and "notify-natural-language" 447 attributes is the same in all Subscription Objects. If not, the 448 Printer MUST pick one Subscription Object from which to obtain the 449 value of these attributes. The algorithm for picking the 450 Subscription Object is implementation dependent. The choice of 451 natural language is not critical because 'text' and 'name' values 452 can override the "attributes-natural-language" Operation attribute. 453 The Printer's choice of charset is critical because a bad choice 454 may leave it unable to send some 'text' and 'name' values 455 accurately. 457 "suggested-ask-again-time-interval" (integer(0:MAX)): 458 The value of this attribute is the suggested number of seconds that 459 SHOULD elapse before the client performs the Get-Notifications 460 operation again for these Subscription Objects. A client MAY 461 perform the Get-Notifications operation at any time, and a Printer 462 MUST respond with all unexpired Event Notifications. A Notification 463 Recipient waits until this time interval has elapsed in order to be 464 a "good network citizen". It is RECOMMENDED that the value of this 465 attribute be 80% of the "begin-to-expire-time-interval" (see the 466 next attribute) in order to give a Notification Recipient plenty of 467 time to perform the Get-Notifications operation again before new 468 Event Notifications expire. 470 "begin-to-expire-time-interval" (integer(0:MAX)): 471 The value of this attribute is the minimum number of seconds that 472 MUST elapse before Event Notification Leases begin to expire on 473 Event Notifications produced by matching Subscriptions Objects 474 after the Printer sends the Get-Notifications response. The Printer 475 MUST discard an Event Notification when its Event Notification 476 Lease has expired. That is, if the Printer performs the Get- 477 Notifications operation before the time specified by the "begin-to- 478 expire-time-interval" attribute returned in the previous operation, 479 the Printer MUST still have all of the Event Notifications that 480 have occurred since the previous operation. If the Printer assigns 481 the same Event Notification Lease Time to all Event Notifications, 482 the value of this attribute MUST equal the Event Notification Lease 483 Time. If a Notification Recipient waits until after this time or 484 even slightly less than this time, the Notification Recipient MUST 485 expect to lose some Event Notifications. 487 "printer-up-time" (integer(0:MAX)): 488 The value of this attribute is the Printer's "printer-up-time" 489 attribute at the time the Printer sends this response. Because each 490 Event Notification also contains the value of this attribute when 491 the event occurred, the value of this attribute lets a Notification 492 Recipient know when each Event Notification occurred relative to 493 the time of this response. 495 Group 2: Unsupported Attributes 497 See [ipp-mod] section 3.1.7 for details on returning Unsupported 498 Attributes. 500 If the "subscription-ids" attribute contained subscription-ids that 501 do not exist, the Printer returns them in this group as value of 502 the "subscription-ids" attribute. 504 Group 3 through N: Event Notification Attributes 506 The Printer responds with one Event Notification Attributes Group 507 per matched Event Notification. The matched Event Notifications are 508 all un-expired Event Notification associated with the matched 509 Subscription Objects. Each Event Notification Group MUST start with 510 an 'event-notification-attributes-tag' (see the section "Encodings 511 of Additional Attribute Tags" in [ipp-ntfy]). 513 Each attribute is encoded using the IPP rules for encoding 514 attributes [ipp-pro] and may be encoded in any order. Note: the 515 Get-Jobs response in [ipp-mod] acts as a model for encoding 516 multiple groups of attributes. 518 Each Event Notification Group MUST contain all of attributes 519 specified in section 9.1 ("Content of Machine Consumable Event 520 Notifications") of [ipp-ntfy] with exceptions denoted by asterisks 521 in the tables below. 523 The tables below are copies of the tables in section 9.1 ("Content 524 of Machine Consumable Event Notifications") of [ipp-ntfy] except 525 that each cell in the "Sends" column is a "MUST". 527 For an Event Notification for all Events, the Printer includes the 528 following attributes. 530 Table 1 - Attributes in Event Notification Content 532 Source Value Sends Source Object 534 notify-subscription-id (integer(1:MAX)) MUST Subscription 536 notify-printer-uri (uri) MUST Subscription 538 notify-subscribed-event (type2 keyword) MUST Event 539 Notification 541 printer-up-time (integer(MIN:MAX)) MUST Printer 543 printer-current-time (dateTime)* MUST Printer 545 notify-sequence-number (integer (0:MAX)) MUST Subscription 547 notify-charset (charset) MUST Subscription 549 notify-natural-language (naturalLanguage) MUST Subscription 551 notify-user-data (octetString(63)) ** MUST Subscription 553 notify-text (text) MUST Event 554 Notification 556 attributes from the "notify-attributes" MUST Printer 557 attribute *** 559 attributes from the "notify-attributes" MUST Job 560 attribute *** 562 attributes from the "notify-attributes" MUST Subscription 563 attribute *** 565 * The Printer MUST send "printer-current-time" if and only if it 566 supports the "printer-current-time" attribute on the Printer 567 object. 569 ** If the associated Subscription Object does not contain a 570 "notify-user-data" attribute, the Printer MUST send an octet-string 571 of length 0. 573 *** If the "notify-attributes" attribute is present on the 574 Subscription Object, the Printer MUST send all attributes specified 575 by the "notify-attributes" attribute. Note: if the Printer doesn't 576 support the "notify-attributes" attribute, it is not present on the 577 associated Subscription Object. 579 For Event Notifications for Job Events, the Printer includes the 580 following additional attributes. 582 Table 2 - Additional Attributes in Event Notification Content for 583 Job Events 585 Source Value Sends Source Object 587 job-id (integer(1:MAX)) MUST Job 589 job-state (type1 enum) MUST Job 591 job-state-reasons (1setOf type2 keyword) MUST Job 593 job-impressions-completed MUST Job 594 (integer(0:MAX)) * 596 * The Printer MUST send the "job-impressions-completed" attribute 597 in an Event Notification only for the combinations of Events and 598 Subscribed Events shown in Table 3. 600 Table 3 - Combinations of Events and Subscribed Events for "job- 601 impressions-completed" 603 Job Event Subscribed Job Event 605 'job-progress' 'job-progress' 607 'job-completed' 'job-completed' 609 'job-completed' 'job-state-changed' 610 For Event Notification for Printer Events, the Printer includes the 611 following additional attributes. 613 Table 4 - Additional Attributes in Event Notification Content for 614 Printer Events 616 Source Value Sends Source Object 618 printer-state (type1 enum) MUST Printer 620 printer-state-reasons (1setOf type2 MUST Printer 621 keyword) 623 printer-is-accepting-jobs (boolean) MUST Printer 625 6 Extensions to Subscription Creation Operations 627 6.1 Response 629 When a Subscription Creation Operation contains a "notify-recipient-uri" 630 attribute and the scheme in its value is 'ipp-get', the response MUST 631 contain two additional Operation Attributes that pertain to this 632 Delivery Method. Note: Subscription Creation Operations include: Print- 633 Job, Print-URI, Create-Job, Create-Job-Subscriptions and Create-Printer- 634 Subscriptions. 636 Group 1: Operation Attributes 638 "suggested-ask-again-time-interval" (integer(0:MAX)): 639 This attribute has the same meaning as the "suggested-ask-again- 640 time-interval" attribute in the Get-Notifications operation except 641 that it suggests when to perform the Get-Notifications operation 642 for the first time on all Subscription Objects in the response 643 whose "notify-recipient-uri" scheme is 'ipp-get'. 645 "begin-to-expire-time-interval" (integer(0:MAX)): 646 This attribute has the same meaning as the "begin-to-expire-time- 647 interval" attribute in the Get-Notifications operation except that 648 it indicates when the Event Notification Lease begins to expire for 649 all Subscription Objects in the response whose "notify-recipient- 650 uri" scheme is 'ipp-get'. 652 7 Encoding 654 The operation-id assigned for the Get-Notifications operation is: 656 0x001C 658 and should be added to the next version of [ipp-mod] section 4.4.15 659 "operations-supported". 661 This notification delivery method uses the IPP transport and encoding 662 [ipp-pro] for the Get-Notifications operation with one extension: 664 notification-attributes-tag = %x07 ; tag of 665 7 667 8 IANA Considerations 669 There is nothing to register. 671 9 Internationalization Considerations 673 The IPP Printer MUST localize the "notify-text" attribute as specified 674 in section 14 of [ipp-ntfy]. 676 In addition, when the client receives the Get-Notifications response, it 677 is expected to localize the attributes that have the 'keyword' attribute 678 syntax according to the charset and natural language requested in the 679 Get-Notifications request. 681 10 Security Considerations 683 The IPP Model and Semantics document [ipp-mod] discusses high-level 684 security requirements (Client Authentication, Server Authentication and 685 Operation Privacy). Client Authentication is the mechanism by which the 686 client proves its identity to the server in a secure manner. Server 687 Authentication is the mechanism by which the server proves its identity 688 to the client in a secure manner. Operation Privacy is defined as a 689 mechanism for protecting operations from eavesdropping. 691 Unlike other Event Notification delivery methods in which the IPP 692 Printer initiates the Event Notification, with the method defined in 693 this document, the Notification Recipient is the client who s the Get- 694 Notifications operation. Therefore, there is no chance of "spam" 695 notifications with this method. Furthermore, such a client can close 696 down the HTTP channel at any time, and so can avoid future unwanted 697 Event Notifications at any time. 699 11 References 701 [ipp-mod] 702 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 703 "Internet Printing Protocol/1.1: Model and Semantics", , March 1, 2000. 706 [ipp-ntfy] 707 R. Herriot, Hastings, T., Isaacson, S., Martin, J., deBry, R., 708 Shepherd, M., Bergman, R., "Internet Printing Protocol/1.1: IPP 709 Event Notification Specification", , June 30, 2000. 712 [ipp-pro] 713 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 714 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 715 05.txt, March 1, 2000. 717 [rfc2026] 718 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 719 2026, October 1996. 721 [RFC2616] 722 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 723 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 724 RFC 2616, June 1999. 726 12 Authors' Addresses 728 Robert Herriot 729 Xerox Corp. 730 3400 Hill View Ave, Building 1 731 Palo Alto, CA 94304 733 Phone: 650-813-7696 734 Fax: 650-813-6860 735 e-mail: robert.herriot@pahv.xerox.com 737 Tom Hastings 738 Xerox Corporation 739 737 Hawaii St. ESAE 231 740 El Segundo, CA 90245 742 Phone: 310-333-6413 743 Fax: 310-333-5514 744 e-mail: hastings@cp10.es.xerox.com 746 Carl-Uno Manros 747 Xerox Corporation 748 701 Aviation Blvd. 749 El Segundo, CA 90245 751 Phone: 310-333- 752 Fax: 310-333-5514 753 e-mail: manros@cp10.es.xerox.com 755 Harry Lewis 756 IBM 757 P.O. Box 1900 758 Boulder, CO 80301-9191 760 Phone: (303) 924-5337 761 FAX: 762 e-mail: harryl@us.ibm.com 764 13 Full Copyright Statement 766 Copyright (C) The Internet Society (2000). All Rights Reserved. 768 This document and translations of it may be copied and furnished to 769 others, and derivative works that comment on or otherwise explain it or 770 assist in its implementation may be prepared, copied, published and 771 distributed, in whole or in part, without restriction of any kind, 772 provided that the above copyright notice and this paragraph are included 773 on all such copies and derivative works. However, this document itself 774 may not be modified in any way, such as by removing the copyright notice 775 or references to the Internet Society or other Internet organizations, 776 except as needed for the purpose of developing Internet standards in 777 which case the procedures for copyrights defined in the Internet 778 Standards process must be followed, or as required to translate it into 779 languages other than English. 781 The limited permissions granted above are perpetual and will not be 782 revoked by the Internet Society or its successors or assigns. 784 This document and the information contained herein is provided on an "AS 785 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 786 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 787 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 788 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 789 FITNESS FOR A PARTICULAR PURPOSE.