7 Network Working Group R. Herriot
8 Request for Comments: 3995 Global Workflow Solutions
9 Category: Standards Track T. Hastings
10 Updates: 2911, 2910 Xerox Corporation
14 Internet Printing Protocol (IPP):
15 Event Notifications and Subscriptions
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (C) The Internet Society (2005).
31 This document describes an OPTIONAL extension to the Internet
32 Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).
33 This extension allows a client to subscribe to printing related
34 Events. Subscriptions are modeled as Subscription Objects. The
35 Subscription Object specifies that when one of the specified Events
36 occurs, the Printer delivers an asynchronous Event Notification to
37 the specified Notification Recipient via the specified Push or Pull
38 Delivery Method (i.e., protocol).
40 A client associates Subscription Objects with a particular Job by
41 performing the Create-Job-Subscriptions operation or by submitting a
42 Job with subscription information. A client associates Subscription
43 Objects with the Printer by performing a Create-Printer-Subscriptions
44 operation. Four other operations are defined for Subscription
45 Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-
46 Subscription, and Cancel-Subscription.
58 Herriot & Hastings Standards Track [Page 1]
60 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
66 1.1. Notification Overview. . . . . . . . . . . . . . . . . . 5
67 2. Models for Notification. . . . . . . . . . . . . . . . . . . . 8
68 2.1. Model for Simple Notification (Normative). . . . . . . . 8
69 2.2. Additional Models for Notification (Informative) . . . . 9
70 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 9
71 3.1. Conformance Terminology. . . . . . . . . . . . . . . . . 9
72 3.2. Other Terminology. . . . . . . . . . . . . . . . . . . . 10
73 4. Object Relationships . . . . . . . . . . . . . . . . . . . . . 12
74 4.1. Printer and Per-Printer Subscription Objects . . . . . . 13
75 4.2. Printer, Job and Per-Job Subscription Objects. . . . . . 13
76 5. Subscription Object. . . . . . . . . . . . . . . . . . . . . . 13
77 5.1. Rules for Support of Subscription Template Attributes. . 14
78 5.2. Rules for Processing Subscription Template Attributes. . 15
79 5.3. Subscription Template Attributes . . . . . . . . . . . . 18
80 5.3.1. notify-recipient-uri (uri) . . . . . . . . . . . 20
81 5.3.2. notify-pull-method (type2 keyword) . . . . . . . 21
82 5.3.3. notify-events (1setOf type2 keyword) . . . . . . 22
83 5.3.4. notify-attributes (1setOf type2 keyword) . . . . 29
84 5.3.5. notify-user-data (octetString(63)) . . . . . . . 30
85 5.3.6. notify-charset (charset) . . . . . . . . . . . . 31
86 5.3.7. notify-natural-language (naturalLanguage). . . . 31
87 5.3.8. notify-lease-duration (integer(0:67108863)). . . 32
88 5.3.9. notify-time-interval (integer(0:MAX)). . . . . . 33
89 5.4. Subscription Description Attributes. . . . . . . . . . . 34
90 5.4.1. notify-subscription-id (integer (1:MAX)). . . . 35
91 5.4.2. notify-sequence-number (integer (0:MAX)) . . . . 35
92 5.4.3. notify-lease-expiration-time (integer(0:MAX)). . 36
93 5.4.4. notify-printer-up-time (integer(1:MAX)). . . . . 37
94 5.4.5. notify-printer-uri (uri) . . . . . . . . . . . . 37
95 5.4.6. notify-job-id (integer(1:MAX)) . . . . . . . . . 37
96 5.4.7. notify-subscriber-user-name (name(MAX)). . . . . 38
97 6. Printer Description Attributes Related to Notification . . . . 38
98 6.1. printer-state-change-time (integer(1:MAX)) . . . . . . . 39
99 6.2. printer-state-change-date-time (dateTime). . . . . . . . 39
100 7. New Values for Existing Printer Description Attributes . . . . 39
101 7.1. operations-supported (1setOf type2 enum) . . . . . . . . 40
102 8. Attributes Only in Event Notifications . . . . . . . . . . . . 40
103 8.1. notify-subscribed-event (type2 keyword). . . . . . . . . 40
104 8.2. notify-text (text(MAX)). . . . . . . . . . . . . . . . . 41
105 9. Event Notification Content . . . . . . . . . . . . . . . . . . 41
106 9.1. Content of Machine Consumable Event Notifications. . . . 44
107 9.1.1. Event Notification Content Common to All Events. 44
108 9.1.2. Additional Event Notification Content for Job
109 Events . . . . . . . . . . . . . . . . . . . . . 45
114 Herriot & Hastings Standards Track [Page 2]
116 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
119 9.1.3. Additional Event Notification Content for
120 Printer Events . . . . . . . . . . . . . . . . . 46
121 9.2. Content of Human Consumable Event Notification . . . . . 46
122 9.2.1. Event Notification Content Common to All Events. 47
123 9.2.2. Additional Event Notification Content for Job
124 Events . . . . . . . . . . . . . . . . . . . . . 49
125 9.2.3. Additional Event Notification Content for
126 Printer Events . . . . . . . . . . . . . . . . . 49
127 10. Delivery Methods . . . . . . . . . . . . . . . . . . . . . . . 50
128 11. Operations for Notification. . . . . . . . . . . . . . . . . . 52
129 11.1. Subscription Creation Operations . . . . . . . . . . . . 52
130 11.1.1. Create-Job-Subscriptions Operation . . . . . . . 52
131 11.1.2. Create-Printer-Subscriptions operation . . . . . 55
132 11.1.3. Job Creation Operations - Extensions for
133 Notification . . . . . . . . . . . . . . . . . . 56
134 11.2 Other Operations. . . . . . . . . . . . . . . . . . . . . 58
135 11.2.1. Restart-Job Operation - Extensions for
136 Notification . . . . . . . . . . . . . . . . . . 58
137 11.2.2. Validate-Job Operation - Extensions for
138 Notification . . . . . . . . . . . . . . . . . . 59
139 11.2.3. Get-Printer-Attributes - Extensions for
140 Notification . . . . . . . . . . . . . . . . . . 59
141 11.2.4. Get-Subscription-Attributes operation. . . . . . 60
142 11.2.5. Get-Subscriptions operation. . . . . . . . . . . 63
143 11.2.6. Renew-Subscription operation . . . . . . . . . . 66
144 11.2.7. Cancel-Subscription operation. . . . . . . . . . 68
145 12. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . 70
146 12.1. successful-ok-ignored-subscriptions (0x0003) . . . . . . 70
147 12.2. client-error-ignored-all-subscriptions (0x0414). . . . . 71
148 13. Status Codes in Subscription Attributes Groups . . . . . . . . 71
149 13.1. client-error-uri-scheme-not-supported (0x040C) . . . . . 71
150 13.2. client-error-attributes-or-values-not-supported (0x040B) 71
151 13.3. client-error-too-many-subscriptions (0x0415) . . . . . . 72
152 13.4. successful-ok-too-many-events (0x0005) . . . . . . . . . 72
153 13.5. successful-ok-ignored-or-substituted-attributes (0x0001) 72
154 14. Encodings of Additional Attribute Tags . . . . . . . . . . . . 72
155 15. Conformance Requirements . . . . . . . . . . . . . . . . . . . 72
156 15.1. Conformance requirements for clients . . . . . . . . . . 73
157 15.2. Conformance requirements for Printers. . . . . . . . . . 73
158 16. Model for Notification with Cascading Printers (Informative) . 74
159 17. Distributed Model for Notification (Informative) . . . . . . . 75
160 18. Extended Notification Recipient (Informative). . . . . . . . . 76
161 19. Object Model for Notification (Normative). . . . . . . . . . . 77
162 19.1. Object relationships . . . . . . . . . . . . . . . . . . 78
163 19.2. Printer Object and Per-Printer Subscription Objects. . . 79
164 19.3. Job Object and Per-Job Subscription Objects. . . . . . . 79
165 20. Per-Job versus Per-Printer Subscription Objects (Normative). . 79
166 21. Normative References . . . . . . . . . . . . . . . . . . . . . 80
170 Herriot & Hastings Standards Track [Page 3]
172 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
175 22. Informative References . . . . . . . . . . . . . . . . . . . . 80
176 23. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 81
177 23.1. Attribute Registrations. . . . . . . . . . . . . . . . . 82
178 23.2. Additional Enum Attribute Value Registrations within
179 the IPP registry . . . . . . . . . . . . . . . . . . . . 83
180 23.3. Operation Registrations. . . . . . . . . . . . . . . . . 83
181 23.4. Status code Registrations. . . . . . . . . . . . . . . . 83
182 23.5. Attribute Group tag Registrations. . . . . . . . . . . . 84
183 23.6. Registration of Events . . . . . . . . . . . . . . . . . 84
184 23.7. Registration of Event Notification Delivery Methods. . . 85
185 23.7.1. Requirements for Registration of Event
186 Notification Delivery Methods. . . . . . . . . . 85
187 23.7.2. Registration Procedure . . . . . . . . . . . . . 86
188 23.7.3. Delivery Method Document Registrations . . . . . 87
189 23.7.4. Registration Template. . . . . . . . . . . . . . 88
190 24. Internationalization Considerations. . . . . . . . . . . . . . 89
191 25. Security Considerations. . . . . . . . . . . . . . . . . . . . 89
192 25.1. Client access rights . . . . . . . . . . . . . . . . . . 89
193 25.2. Printer security threats . . . . . . . . . . . . . . . . 91
194 25.3. Notification Recipient security threats. . . . . . . . . 91
195 26. Description of the base IPP documents (Informative). . . . . . 92
196 27. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 93
197 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
198 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 95
202 Table 1 - Subscription Template Attributes. . . . . . . . . . . . 20
203 Table 2 - Subscription Description Attributes . . . . . . . . . . 35
204 Table 3 - Printer Description Attributes Associated with
205 Notification. . . . . . . . . . . . . . . . . . . . . . 39
206 Table 4 - Operation-id assignments. . . . . . . . . . . . . . . . 40
207 Table 5 - Attributes in Event Notification Content. . . . . . . . 45
208 Table 6 - Additional Event Notification Content for Job Events. . 46
209 Table 7 - Combinations of Events and Subscribed Events for
210 "job-impressions-completed" . . . . . . . . . . . . . . 46
211 Table 8 - Additional Event Notification Content for Printer
212 Events. . . . . . . . . . . . . . . . . . . . . . . . . 46
213 Table 9 - Printer Name in Event Notification Content. . . . . . . 48
214 Table 10 - Event Name in Event Notification Content. . . . . . . . 48
215 Table 11 - Event Time in Event Notification Content. . . . . . . . 48
216 Table 12 - Job Name in Event Notification Content. . . . . . . . . 49
217 Table 13 - Job State in Event Notification Content . . . . . . . . 49
218 Table 14 - Printer State in Event Notification Content . . . . . . 50
219 Table 15 - Information about the Delivery Method . . . . . . . . . 51
220 Table 16 - Printer Conformance Requirements for Operations . . . . 74
226 Herriot & Hastings Standards Track [Page 4]
228 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
233 Figure 1 - Model for Notification. . . . . . . . . . . . . . . . . 9
234 Figure 2 - Model for Notification with Cascading Printers. . . . . 75
235 Figure 3 - Opaque Use of a Notification Server Transparent to the
236 Client. . . . . . . . . . . . . . . . . . . . . . . . . 76
237 Figure 4 - Use of an Extended Notification Recipient transparent
238 to the Printer. . . . . . . . . . . . . . . . . . . . . 77
239 Figure 5 - Object Model for Notification . . . . . . . . . . . . . 78
243 This IPP notification specification is an OPTIONAL extension to
244 Internet Printing Protocol/1.1: Model and Semantics [RFC2911,
245 RFC2910]. See Appendix 29 for a description of the base IPP
246 documents. This document in combination with the following documents
247 is intended to meet the most important notification requirements
248 described in [RFC3997]:
250 Internet Printing Protocol (IPP): "Job Progress Attributes"
253 Internet Printing Protocol (IPP): "The 'ippget' Delivery Method
254 for Event Notifications" [RFC3996]
256 This specification REQUIRES that clients and Printers support the
257 'ippget' Pull Delivery Method [RFC3996]. Conforming client and
258 Printer implementations MAY support additional Push or Pull Delivery
259 Methods as well. Note: this document does not define any Delivery
260 Methods itself, but it does define the rules for conformance for
261 Delivery Method Documents and their registration with IANA (see
264 Refer to the Table of Contents for the layout of this document.
266 1.1. Notification Overview
268 This document defines operations that a client can perform in order
269 to create Subscription Objects in a Printer and carry out other
270 operations on them. A Subscription Object represents a Subscription
271 abstraction. The Subscription Object specifies that when one of the
272 specified Events occurs, the Printer delivers an asynchronous Event
273 Notification to the specified Notification Recipient via the
274 specified Delivery Method (i.e., protocol).
276 When a client (called a Subscribing Client) performs an operation
277 that creates a Subscription Object, the operation contains one or
278 more Subscription Template Attributes Groups. Each such group holds
282 Herriot & Hastings Standards Track [Page 5]
284 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
287 information used by the Printer to initialize a newly created
288 Subscription Object. The Printer creates one Subscription Object for
289 each Subscription Template Attributes Group in the operation. This
290 group is like the Job Template Attributes group defined in [RFC2911].
291 The following is an example of the information included in a
292 Subscription Template Attributes Group (see section 5 for details on
293 the Subscription Object attributes):
295 1. The names of Subscribed Events that are of interest to the
296 Notification Recipient.
298 2. The address (URL) of one Notification Recipient for a Push
299 Delivery Method or the method for a Pull Delivery Method.
301 3. The Delivery Method (i.e., the protocol) which the Printer uses to
302 deliver the Event Notification.
304 4. Some opaque data that the Printer delivers to the Notification
305 Recipient in the Event Notification. For example, the
306 Notification Recipient might use this opaque data as a forwarding
307 address for the Event Notification.
309 5. The charset to use in text fields within an Event Notification
311 6. The natural language to use in the text fields of the Event
314 7. The requested lease time in seconds for the Subscription Object
316 An operation that creates a Subscription Object is called a
317 Subscription Creation Operation. These operations include the
318 following operations (see section 11.1 for further details):
320 - Job Creation operation: When a client performs such an
321 operation (Print-Job, Print-URI, and Create-Job), a client can
322 include zero or more Subscription Template Attributes Groups in
323 the request. The Printer creates one Subscription Object for
324 each Subscription Template Attributes Group in the request, and
325 the Printer associates each such Subscription Object with the
326 newly created Job. This document extends these operations'
327 definitions in [RFC2911] by adding Subscription Template
328 Attributes Groups in the request and Subscription Attributes
329 Groups in the response.
331 - Create-Job-Subscriptions operation: A client can include one or
332 more Subscription Template Attributes Groups in the request.
333 The Printer creates one Subscription Object for each
338 Herriot & Hastings Standards Track [Page 6]
340 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
343 Subscription Template Attributes Group and associates each with
344 the job that is the target of this operation.
346 - Create-Printer-Subscriptions operation: A client can include
347 one or more Subscription Template Attributes Groups in the
348 request. The Printer creates one Subscription Object for each
349 Subscription Template Attributes Group and associates each with
350 the Printer that is the target of this operation.
352 For each of the above operations:
354 - the Printer associates a Subscription Object with the Printer
355 or a specific Job. When a Subscription Object is associated
356 with a Job Object, it is called a Per-Job Subscription Object.
357 When a Subscription Object is associated with a Printer Object,
358 it is called a Per-Printer Subscription Object.
360 - the response contains one Subscription Attributes Group for
361 each Subscription Template Attributes Group in the request and
362 in the same order. When the Printer successfully creates a
363 Subscription Object, its corresponding Subscription Attributes
364 Group contains the "notify-subscription-id" attribute. This
365 attribute uniquely identifies the Subscription Object and is
366 analogous to a "job-id" for a Job object. Some operations
367 described below use the "notify-subscription-id" to identify
368 the target Subscription Object.
370 This document defines the following additional operations (see
371 section 11.2 for further details):
373 - Restart-Job operation: When a client performs the Restart-Job
374 operation [RFC2911], the Printer re-uses the same Job and its
375 Subscription Objects.
377 - Validate-Job operation: When a client performs this operation, a
378 client can include zero or more Subscription Template Attributes
379 Groups in the request. The Printer determines if it could create
380 one Subscription Object for each Subscription Template Attributes
381 Group in the request. This document extends this operation's
382 definition in [RFC2911] by adding Subscription Template Attributes
383 Groups in the request and Subscription Attributes Groups in the
386 - Get-Subscription-Attributes operation: This operation allows a
387 client to obtain the specified attributes of a target Subscription
394 Herriot & Hastings Standards Track [Page 7]
396 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
399 - Get-Subscriptions operation: This operation allows a client to
400 obtain the specified attributes of all Subscription Objects
401 associated with the Printer or a specified Job.
403 - Renew-Subscription operation: This operation renews the lease on
404 the target Per-Printer Subscription Object before it expires. A
405 newly created Per-Printer Subscription Object receives an initial
406 lease. It is the duty of the client to use this operation
407 frequently enough to preserve a Per-Printer Subscription Object.
408 The Printer deletes a Per-Printer Subscription Object when its
409 lease expires. A Per-Job Subscription Object last exactly as long
410 as its associated Job Object and thus doesn't have a lease.
412 - Cancel-Subscription operation: This operation (1) cancels the
413 lease on the specified Per-Printer Subscription Object and thereby
414 deletes the Per-Printer Subscription Object or (2) deletes the
415 Per-Job Subscription Object.
417 When an Event occurs, the Printer finds all Subscription Objects
418 listening for the Event (see section 9 for details on finding such
419 Subscription Objects). For each such Subscription Object, the
422 a) generates an Event Notification with information specified in
427 i) If the Delivery Method is a Push Delivery Method as indicated
428 by the presence of the Subscription Object's "notify-
429 recipient-uri" attribute, delivers the Event Notification
430 using the Delivery Method and target address identified in the
431 Subscription Object's "notify-recipient-uri" attribute, OR
433 ii) If the Delivery Method is a Pull Delivery Method as indicated
434 by the presence of the Subscription Object's "notify-pull-
435 method" attribute, saves Event Notification for a time period
436 called the Event Life defined by the Delivery Method, i.e.,
437 the Notification Recipient is expected to fetch the Event
440 2. Models for Notification
442 2.1. Model for Simple Notification (Normative)
444 As part of a Subscription Creation Operation, an IPP Printer (i.e.,
445 located in an output device or a server) creates one or more
446 Subscription Objects. In a Subscription Creation Operation, the
450 Herriot & Hastings Standards Track [Page 8]
452 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
455 client specifies the Notification Recipient to which the Printer is
456 to deliver Event Notifications. A Notification Recipient can be the
457 Subscribing Client or a third party.
459 Figure 1 shows the Notification model for a simple Client-Printer
464 output device or server
465 PDA, desktop, or server +---------------+
466 +--------+ | ########### |
467 | client |-----Subscription ---------># Printer # |
468 +--------+ Creation Operation | # Object # |
469 +------------+ | #####|##### |
470 |Notification| +-------|-------+
471 |Recipient |<----IPP Event Notifications----+
472 +------------+ (Job and/or Printer Events)
474 Figure 1 - Model for Notification
476 2.2. Additional Models for Notification (Informative)
478 Additional models have been proposed (see Appendices 16, 17, and 18).
482 This section defines terminology used throughout this document.
483 Other terminology is defined in [RFC2911].
485 3.1. Conformance Terminology
487 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
488 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
489 conformance as defined in RFC 2119 [RFC2119] and [RFC2911] section
490 12.1. If an implementation supports the extension defined in this
491 document, then these terms apply; otherwise, they do not. These
492 terms define conformance to this document only; they do not affect
493 conformance to other documents, unless explicitly stated otherwise.
495 Note: a feature that is OPTIONAL in this document becomes REQUIRED if
496 the Printer implements a Delivery Method that REQUIRES the feature.
498 READ-ONLY - an adjective used in an attribute definition to indicate
499 that an IPP Printer MUST NOT allow the attribute's value to be
506 Herriot & Hastings Standards Track [Page 9]
508 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
511 3.2. Other Terminology
513 This document uses the same terminology as [RFC2911], such as
514 "client", "Printer", "attribute", "attribute value", "keyword",
515 "operation", "request", "response", "administrator", "operator", and
516 "support". In addition, the following terms are defined for use in
517 this document and the Delivery Method Documents:
519 Compound Event Notification - two or more Event Notifications that a
520 Printer delivers together as a single request or response. The
521 Delivery Method Document specifies whether the Delivery Method
522 supports Compound Event Notifications.
524 Delivery Method - the mechanism by which the Printer delivers an
527 Delivery Method Document - a document, separate from this document,
528 that defines a Delivery Method.
530 Event - some occurrence (either expected or unexpected) within the
531 printing system of a change of state, condition, or configuration of
532 a Job or Printer object. An Event occurs only at one instant in time
533 and does not span the time the physical Event takes place. For
534 example, jam-occurred and jam-cleared are two distinct, instantaneous
535 Events, even though the jam may last for a while.
537 Event Life - For a Pull Delivery Method, the length of time in
538 seconds after an Event occurs during which the Printer will retain
539 that Event for delivery in an Event Notification. After the Event
540 Life expires, the Printer will no longer deliver an Event
541 Notification for that Event in such a response.
543 Event Notification - the information about an Event that the Printer
544 delivers when an Event occurs.
546 Event Notification Attributes Group - The attributes group which is
547 used to deliver an Event Notification in a request (Push Delivery
548 Methods) or a response (Pull Delivery Methods).
550 Human Consumable Event Notification - localized text for human
551 consumption only. There is no standardized format and thus programs
552 should not try to parse this text.
554 Job Creation operation - One of the operations that creates a Job
555 object: Print-Job, Print-URI and Create-Job. The Restart-Job
556 operation [RFC2911] is not considered a Job Creation operation, since
557 the Printer re-uses the existing Job object. The Validate-Job
558 operation is not considered a Job Creation operation because no Job
562 Herriot & Hastings Standards Track [Page 10]
564 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
567 object is created. Therefore, when a statement also applies to
568 either the Restart-Job and/or the Validate-Job operation, they are
569 mentioned explicitly.
571 Job Event - an Event caused by some change in a particular job on the
572 Printer, e.g., 'job-completed'.
574 Machine Consumable Event Notification - bytes for program
575 consumption. The bytes are formatted according to the Delivery
578 Notification - when not in the phrases 'Event Notification' and
579 'Notification Recipient' - the concepts of this specification, i.e.,
580 Events, Subscription Objects, and Event Notifications.
582 Notification Recipient - the entity to which the Printer delivers an
583 Event Notification. For Push Delivery Methods, the IPP Printer sends
584 the Notifications to a Notification Recipient. For Pull Delivery
585 Methods, the Notification Recipient is acting in the role of an IPP
586 client and requests Event Notifications and so the terms "client" and
588 "Notification Recipient" are used interchangeably with such Delivery
589 Methods. For example, see [RFC3996].
591 Per-Job Subscription Object - A Subscription Object that is
592 associated with a single Job. The Create-Job-Subscriptions operation
593 and Job Creation operations create such an object.
595 Per-Printer Subscription Object - A Subscription Object that is
596 associated with the Printer as a whole. The Create-Printer-
597 Subscriptions operation creates such an object.
599 Printer Event - an Event caused by some change in the Printer that is
600 not specific to a job, e.g., 'printer-state-changed'.
602 Pull Delivery Method - The Printer saves Event Notifications for some
603 event life time and expects the Notification Recipient to request
604 Event Notifications. The Printer delivers the Event Notifications in
605 a response to such a request.
607 Push Delivery Method -The Printer delivers the Event Notification
608 shortly after an Event occurs.
610 Subscribed Event - an Event that the Subscribing Client expresses
611 interest in by making it a value of the "notify-events" attribute on
612 a Subscription Object.
614 Subscribed Job Event - a Subscribed Event that is a Job Event.
618 Herriot & Hastings Standards Track [Page 11]
620 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
623 Subscribed Printer Event - a Subscribed Event that is a Printer
626 Subscribing Client - The client that creates the Subscription Object.
628 Subscription Attributes Group - The attributes group in a response
629 that contains Subscription Object attributes.
631 Subscription Creation Operation - An operation that creates a
632 Subscription Object: Job Creation operations, Create-Job-
633 Subscriptions operation, Create-Printer-Subscriptions operation. In
634 the context of a Job Creation operation, a Subscription Creation
635 Operation is the part of the Job Creation operation that creates one
636 or more Subscription objects. The Restart-Job operation [RFC2911] is
637 not considered a Subscription Creation Operation, since the Printer
638 re-uses the Job's existing Subscription Objects, rather than creating
639 any new Subscription Objects.
641 Subscription Creation Request - The request portion of a Subscription
644 Subscription Description Attributes - Subscription Object attributes
645 that a Printer supplies during a Subscription Creation Operation.
647 Subscription Object - An object containing a set of attributes that
648 indicate: the Notification Recipient (for Push Delivery Method
649 only), the Delivery Method, the Subscribed Events that cause the
650 Printer to deliver an Event Notification, and the information to
651 include in an Event Notification.
653 Subscription Template Attributes - Subscription Object attributes
654 that a client can supply in a Subscription Creation Operation and
655 associated Printer Object attributes that specify supported and
656 default values for the Subscription Object attributes.
658 Subscription Template Attributes Group - The attributes group in a
659 request that contains Subscription Object attributes that are
660 Subscription Template Attributes.
662 4. Object Relationships
664 This section defines the object relationships between the Printer,
665 Job, and Subscription Objects. It does not define the
666 implementation. For an illustration of these relationships, see
674 Herriot & Hastings Standards Track [Page 12]
676 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
679 4.1. Printer and Per-Printer Subscription Objects
681 1. A Printer object can be associated with zero or more Per-Printer
682 Subscription Objects.
684 2. Each Per-Printer Subscription Object is associated with exactly
687 4.2. Printer, Job and Per-Job Subscription Objects
689 1. A Printer object is associated with zero or more Job objects.
691 2. Each Job object is associated with exactly one Printer object.
693 3. A Job object is associated with zero or more Per-Job Subscription
696 4. Each Per-Job Subscription Object is associated with exactly one
699 5. Subscription Object
701 A Subscribing Client creates a Subscription Object with a
702 Subscription Creation Operation in order to indicate its interest in
703 certain Events. See section 11 for a description of these
704 operations. When an Event occurs, the Subscription Object specifies
705 to the Printer where to deliver Event Notifications for Push Delivery
706 Methods only, how to deliver them, and what to include in them. See
707 section 9 for details on the contents of an Event Notification.
709 Using the IPP Job Template attributes as a model (see [RFC2911]
710 section 4.2), the attributes of a Subscription Object are divided
711 into two categories: Subscription Template Attributes and
712 Subscription Description Attributes.
714 Subscription Template attributes are, in turn, like the Job Template
715 attributes, divided into
717 1. Subscription Object attributes that a client can supply in a
718 Subscription Creation Request and
720 2. their associated Printer Object attributes that specify supported
721 and default values for the Subscription Object attributes
723 The remainder of this section specifies general rules for
724 Subscription Template Attributes and describes each attribute in a
730 Herriot & Hastings Standards Track [Page 13]
732 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
735 5.1. Rules for Support of Subscription Template Attributes
737 Subscription Template Attributes are fundamental to the Notification
738 model described in this specification. The client supplies these
739 attributes in Subscription Creation Operations and the Printer uses
740 these attributes to populate a newly created Subscription Object.
742 Subscription Objects attributes that are Subscription Template
743 Attributes conform to the following rules:
745 1. Each attribute's name starts with the prefix string "notify-" and
746 this document calls such attributes "notify-xxx".
748 2. For each "notify-xxx" Subscription Object attribute defined in
749 column 1 of Table 1 in section 5.3, Table 1 specifies
750 corresponding Printer attributes: "notify-xxx-default", "notify-
751 xxx-supported", "yyy-supported" and "notify-max-xxx-supported"
752 defined in column 2 of Table 1. Note "xxx" stands for the same
753 string in each case and "yyy" stands for some other string.
755 3. If a Printer supports "notify-xxx" in column 1 of Table 1, then
756 the Printer MUST support all associated attributes specified in
757 column 2 of Table 1. For example, Table 1 shows that if the
758 Printer supports "notify-events", it MUST support "notify-events-
759 default", "notify-events-supported" and "notify-max-events-
762 4. If a Printer does not support "notify-xxx" in column 1 of Table 1,
763 then the Printer MUST NOT support any associated "notify-yyy"
764 attributes specified in column 2 of Table 1. For example, Table 1
765 shows that if the Printer doesn't support "notify-events", it MUST
766 NOT support "notify-events-default", "notify-events-supported" and
767 "notify-max-events-supported". Note this rule does not apply to
768 attributes whose names do not start with the string "notify-" and
769 are thus defined in another object and used by other attributes.
771 5. Most "notify-xxx" attributes have a corresponding "yyy-supported"
772 attribute that specifies the supported values for "notify-xxx".
773 Column 2 of Table 1 specifies the name of each "yyy-supported"
774 attribute. The naming rules of IPP/1.1 (see [RFC2911]) are used
775 when "yyy-supported" is "notify-xxx-supported".
777 6. Some "notify-xxx" attributes have a corresponding "notify-xxx-
778 default" attribute that specifies the value for "notify-xxx" if
779 the client does not supply it. Column 2 of Table 1 specifies the
780 name of each "notify-xxx-default" attribute. The naming rules of
781 IPP/1.1 (see [RFC2911]) are used.
786 Herriot & Hastings Standards Track [Page 14]
788 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
791 If a client wishes to present an end user with a list of supported
792 values from which to choose, the client SHOULD query the Printer for
793 its supported value attributes. The client SHOULD also query the
794 default value attributes. If the client then limits selectable
795 values to only those values that are supported, the client can
796 guarantee that the values supplied by the client in the create
797 request all fall within the set of supported values at the Printer.
798 When querying the Printer, the client MAY enumerate each attribute by
799 name in the Get-Printer-Attributes Request, or the client MAY just
800 supply the 'subscription-template' group name in order to get the
801 complete set of supported attributes (both supported and default
802 attributes - see section 11.2.3).
804 5.2. Rules for Processing Subscription Template Attributes
806 This section defines a detailed set of rules that a Printer follows
807 when it processes Subscription Template Attributes in a Subscription
808 Creation Request. These rules are similar to the rules for
809 processing Operation attributes in [RFC2911]. That is, the Printer
810 may or may not support an attribute and a client may or may not
811 supply the attribute. Some combinations of these cases are OK.
812 Others return warnings or errors, and perhaps a list of unsupported
815 A Printer MUST implement the following behavior for processing
816 Subscription Template Attributes in a Subscription Creation Request:
818 1. If a client supplies a "notify-xxx" attribute from column 1 of
819 Table 1 and the Printer supports it and its value, the Printer
820 MUST populate the attribute on the created Subscription Object.
822 2. If a client supplies a "notify-xxx" attribute from column 1 of
823 Table 1 and the Printer doesn't support it or its value, the
824 Printer MUST NOT populate the attribute on the created
825 Subscription Object with it. The Printer MUST do one of the
828 a) If the value of the "notify-xxx" attribute is unsupported, the
829 Printer MUST return the attribute with its value in the
830 Subscription Attributes Group of the response.
832 b) If "notify-xxx" is an unsupported attribute, the Printer MUST
833 return the attribute in the Subscription Attributes Group of
834 the response with the 'unsupported' out-of-band value.
836 Note: The rules of this step are the same as for Unsupported
837 Attributes [RFC2911] section 3.1.7. except that the unsupported
838 attributes are returned in the Subscription Attributes Group
842 Herriot & Hastings Standards Track [Page 15]
844 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
847 rather than the Unsupported Attributes Group because Subscription
848 Creation Operations can create more than one Subscription Object).
850 3. If a client is REQUIRED to supply a "notify-xxx" attribute from
851 column 1 of Table 1 and the Printer doesn't support the supplied
852 value, the Printer MUST NOT create a Subscription Object. The
853 rules for Unsupported Attributes in step #2 still apply.
855 4. If a client does not supply a "notify-xxx" attribute from column 1
856 of Table 1 and the attribute is REQUIRED for the client to supply,
857 the Printer MUST reject the Subscription Creation Operation
858 (including Job Creation operations) without creating a
859 Subscription Object, and MUST return in the response:
861 a) the status code 'client-error-bad-request' AND
863 b) no Subscription Attribute Groups.
865 5. If a client does not supply a "notify-xxx" attribute from column 1
866 of Table 1 that is OPTIONAL for the client to supply, and column 2
869 a) specifies a "notify-xxx-default" attribute, the Printer MUST
870 behave as if the client had supplied the "notify-xxx-default"
871 attribute (see step #1) and populate the Subscription object
872 with the value of the "notify-xxx-default" attribute as part of
873 the Subscription Creation operation (unlike Job Template
874 attributes where the Printer does not populate the Job object
875 with defaults - see [RFC2911]) OR
877 b) does not specify a "notify-xxx-default" attribute, the Printer
878 MUST populate the "notify-xxx" attribute on the Subscription
879 Object according to the definition of the "notify-xxx"
880 attribute in a section 5.3. For some attributes, the "notify-
881 xxx" is populated with the value of some other attribute, and
882 for others, the "notify-xxx" is NOT populated on the
883 Subscription object at all.
885 6. A Printer MUST create a Subscription Object for each Subscription
886 Template Attributes group in a request unless the Printer:
888 a) encounters some attributes in a Subscription Template
889 Attributes Group that require the Printer not to create the
890 Subscription Object OR
892 b) would create a Per-Job Subscription Object when it doesn't have
893 space for another Per-Job Subscription Object OR
898 Herriot & Hastings Standards Track [Page 16]
900 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
903 c) would create a Per-Printer Subscription Object when it doesn't
904 have space for another Per-Printer Subscription Object.
906 7. A response MUST contain one Subscription Attributes Group for each
907 Subscription Template Attributes Group in the request (and in the
908 same order) whether the Printer creates a Subscription Object from
909 the Subscription Template Attributes Group or not. However, the
910 attributes in each Subscription Attributes Group can be in any
913 8. The Printer MUST populate each Subscription Attributes Group of
914 the response such that each contains:
916 a) the "notify-subscription-id" attribute (see section 5.4.1), if
917 and only if the Printer creates a Subscription Object.
919 b) the "notify-lease-duration" attribute (see section 5.3.8), if
920 and only if the Printer creates a Per-Printer Subscription
921 Object. The value of this attribute is the value of the
922 Subscription Object's "notify-lease-duration" attribute. This
923 value MAY be different from the client-supplied value (see
924 section 5.3.8). If a client supplies this attribute in the
925 creation of a Per-Job Subscription Object, it MUST appear in
926 this group with the out-of-band value 'unsupported' to indicate
927 that the Printer doesn't support it in this context.
929 c) all of the unsupported Subscription Template Attributes from
930 step #2. Note, they are not returned in the Unsupported
931 Attributes Group in order to separate the unsupported
932 attributes for each Subscription Object.
934 d) the "notify-status-code" attribute if the Printer does not
935 create the Subscription Object or if there are unsupported
936 attributes from step #2. The possible values of the "notify-
937 status-code" attribute are shown below (see section 13 for more
938 details). The Printer returns the first value in the list
939 below that describes the status.
941 'client-error-uri-scheme-not-supported': the Subscription
942 Object was not created because the scheme of the "notify-
943 recipient-uri" attribute is not supported. See section 13.1
944 for more details about this status code. See step #3 in
945 this section for the case that causes this error, and the
946 resulting step #6a) that causes the Printer not to create
947 the Subscription Object.
954 Herriot & Hastings Standards Track [Page 17]
956 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
959 'client-error-attributes-or-values-not-supported': the
960 Subscription Object was not created because the method of
961 the "notify-pull-method" attribute is not supported. See
962 section 13.1 for more details about this status code. See
963 step #3 in this section for the case that causes this error,
964 and the resulting step #6a) that causes the Printer not to
965 create the Subscription Object.
967 'client-error-too-many-subscriptions': the Subscription
968 Object was not created because the Printer has no space for
969 additional Subscription Objects. The client MAY try again
970 later. See section 13.3 for more details about this status
971 code. See steps #6b) and #6c) in this section for the cases
972 that causes this error.
974 'successful-ok-too-many-events': the Subscription Object was
975 created without the "notify-events" values included in this
976 Subscription Attributes Group because the "notify-events"
977 attribute contains too many values. See section 13.4 for
978 more details about this status code. See step #2 in this
979 section and section 5.3.3 for the cases that cause this
982 'successful-ok-ignored-or-substituted-attributes': the
983 Subscription Object was created but some supplied
984 Subscription Template Attributes are unsupported. These
985 unsupported attributes are also in the Subscription
986 Attributes Group. See section 13.5 for more details about
987 this status code. See step #2 in this section for the cases
988 that cause this status code.
990 9. The Printer MUST validate all Subscription Template Attributes and
991 MUST return all unsupported attributes and values in the
992 corresponding Subscription Attributes Group of the response (see
993 step #2) unless it determines that it could not create additional
994 Subscription Objects because of condition #6b) or condition #6c).
995 Then, the Printer NEED NOT validate these additional Subscription
996 Template Attributes and the client MUST NOT expect to find
997 unsupported attributes from step #2 in such additional
998 Subscription Attribute Groups.
1000 5.3. Subscription Template Attributes
1002 This section contains the Subscription Template Attributes defined
1003 for the Subscription and Printer objects.
1010 Herriot & Hastings Standards Track [Page 18]
1012 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1015 Table 1 below shows the Subscription Template Attributes and has two
1018 - Attribute in Subscription Object: the name and attribute syntax of
1019 each Subscription Object Attribute that is a Subscription Template
1022 - Default and Supported Printer Attributes: the default attribute
1023 and supported Printer attributes that are associated with the
1024 attribute in column 1.
1026 The "notify-recipient-uri" attribute is for use with Push Delivery
1027 Methods. The "notify-pull-method" attribute is for use with Pull
1030 For Push Delivery Methods, a Printer MUST support all attributes in
1031 Table 1 below except for "notify-pull-method" and "notify-attributes"
1032 (and "notify-pull-method-supported" and "notify-attributes-
1033 supported"). For Pull Delivery Methods, a Printer MUST support all
1034 attributes in Table 1 below except for "notify-recipient-uri" and
1035 "notify-attributes" (and "notify-schemes-supported" and "notify-
1036 attributes-supported"). If a Printer supports both Push and Pull
1037 Delivery Methods, then it MUST support both "notify-recipient-uri"
1038 and "notify-pull-method" attributes.
1040 For Pull Delivery Methods, a client MUST supply "notify-recipient-
1041 uri" and MAY omit any of the rest of the attributes in column 1 of
1042 Table 1 in a Subscription Creation Request. For Push Delivery
1043 Methods, a client MUST supply "notify-pull-method" and MAY omit any
1044 of the rest of the attributes in column 1 of Table 1 in a
1045 Subscription Creation Request. A client MUST NOT supply both
1046 "notify-recipient-uri" and "notify-pull-method" attributes in the
1047 same Subscription Creation Request.
1049 Note: The Default and Supported Printer attributes listed in column
1050 2 of Table 1 do not have separate sections in this specification
1051 defining their semantics. Instead, the section for the corresponding
1052 Subscription Object attribute (column 1 of Table 1) contains the
1053 semantics of these Printer attributes. This approach follows the
1054 precedence of the Job Template attributes in section 4.2 of [RFC2911]
1055 where the corresponding "xxx-default" and "xxx-supported" Printer
1056 attributes are defined in the same section as the "xxx" Job
1066 Herriot & Hastings Standards Track [Page 19]
1068 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1071 Table 1 - Subscription Template Attributes
1073 Attribute in Subscription Default and Supported Printer
1076 notify-recipient-uri (uri) * notify-schemes-supported (1setOf
1078 notify-pull-method (type2 notify-pull-method-supported (1setOf
1079 keyword) ** type2 keyword)
1080 notify-events (1setOf type2 notify-events-default (1setOf type2
1082 notify-events-supported (1setOf type2
1084 notify-max-events-supported
1087 notify-attributes (1setOf notify-attributes-supported (1setOf
1088 type2 keyword) type2 keyword)
1091 notify-charset (charset) charset-supported (1setOf charset)
1092 notify-natural-language generated-natural-language-supported
1093 (naturalLanguage) (1setOf naturalLanguage)
1094 notify-lease-duration notify-lease-duration-default
1095 (integer(0:MAX)) (integer(0:67108863))
1096 notify-lease-duration-supported
1097 (1setOf (integer(0: 67108863) |
1098 rangeOfInteger(0:67108863)))
1099 notify-time-interval
1102 * "notify-recipient-uri" is for Push Delivery Methods only.
1103 ** "notify-pull-method" is for Pull Delivery Methods only.
1105 5.3.1. notify-recipient-uri (uri)
1107 This attribute's value is a URL, which is a special case of a URI.
1108 Its value consists of a scheme and an address. The address specifies
1109 the Notification Recipient and the scheme specifies the Push Delivery
1110 Method for each Event Notification associated with this Subscription
1113 If a Printer supports any Push Delivery Methods, a Printer MUST
1114 support this attribute and return the value as supplied by the client
1115 (no case conversion or other canonicalization) in any operation
1116 response that includes this attribute.
1122 Herriot & Hastings Standards Track [Page 20]
1124 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1127 For a Push Delivery Method, a client MUST supply this attribute in a
1128 Subscription Creation Operation. Thus there is no need for a default
1131 The URI scheme of the value of this attribute on a Subscription
1132 object MUST be a value of the "notify-schemes-supported (1setOf
1133 uriScheme)" Printer attribute (see section 5.3.1.1). Note: According
1134 to [RFC2396] the ":" terminates the scheme and so is not part of the
1135 scheme. Therefore, values of the "notify-schemes-supported" Printer
1136 attribute do not include the ":" character.
1138 If the client supplies an unsupported scheme in the value of this
1139 attribute, then the Printer MUST NOT create the Subscription Object
1140 and MUST return the "notify-status-code" attribute with the 'client-
1141 error-uri-scheme-not-supported' value in the Subscription Attributes
1142 Group in the response.
1144 5.3.1.1. notify-schemes-supported (1setOf uriScheme)
1146 This attribute contains the URI schemes supported in the "notify-
1147 recipient-uri" Subscription Template attribute. See sections 5.1 and
1148 5.2 for the behavior of "xxx-supported" Subscription Template Printer
1151 5.3.2. notify-pull-method (type2 keyword)
1153 This attribute's value is a type2 keyword indicating which Pull
1154 Delivery Method is to be used.
1156 Since a Printer MUST support the 'ippget' Pull Delivery Method
1157 [RFC3996] (see section 15), a Printer MUST support this attribute and
1158 return the value as supplied by the client in any operation response
1159 that includes this attribute.
1161 For a Pull Delivery Method, a client MUST supply this attribute in a
1162 Subscription Creation Operation. Thus there is no need for a default
1165 The keyword value of this attribute on a Subscription object MUST be
1166 a value of the "notify-pull-method-supported (1setOf type2 keyword)"
1169 If the client supplies an unsupported method in the value of this
1170 attribute, then the Printer MUST NOT create the Subscription Object
1171 and MUST return the "notify-status-code" attribute with the 'client-
1172 error-attributes-or-values-not-supported' value in the Subscription
1173 Attributes Group in the response.
1178 Herriot & Hastings Standards Track [Page 21]
1180 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1183 5.3.2.1. notify-pull-method-supported (1setOf type2 keyword)
1185 See sections 5.1 and 5.2 for the behavior of "xxx-supported"
1186 Subscription Template Printer attributes.
1188 5.3.3. notify-events (1setOf type2 keyword)
1190 This attribute contains a set of Subscribed Events. When an Event
1191 occurs and it "matches" a value of this attribute, the Printer
1192 delivers an Event Notification using information in the Subscription
1193 Object. The details of "matching" are described subsection 5.3.3.5.
1195 A Printer MUST support this attribute.
1197 A client MAY supply this attribute in a Subscription Creation
1198 Operation. If the client does not supply this attribute in
1199 Subscription Creation Operation, the Printer MUST populate this
1200 attribute on the Subscription Object with its "notify-events-default"
1203 Each keyword value of this attribute on a Subscription Object MUST be
1204 a value of the "notify-events-supported (1setOf type2 keyword)"
1207 The number of values of this attribute MUST NOT exceed the value of
1208 the "notify-max-events-supported" attribute. A Printer MUST support
1209 at least 2 values per Subscription Object. If the number of values
1210 supplied by a client in a Subscription Creation Operation exceeds the
1211 value of this attribute, the Printer MUST treat extra values as
1212 unsupported values and MUST use the value of 'successful-ok-too-
1213 many-events' for the "notify-status-code" attribute in the
1214 Subscription Attributes Group of the response.
1216 5.3.3.1. notify-events-default (1setOf type2 keyword)
1218 See sections 5.1 and 5.2 for the behavior of "xxx-default"
1219 Subscription Template Printer attributes.
1221 5.3.3.2. notify-events-supported (1setOf type2 keyword)
1223 See sections 5.1 and 5.2 for the behavior of "xxx-supported"
1224 Subscription Template Printer attributes.
1234 Herriot & Hastings Standards Track [Page 22]
1236 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1239 5.3.3.3. notify-max-events-supported (integer(2:MAX))
1241 This attribute specified the maximum number of events that the
1242 Printer supports for the "notify-events" Subscription Template
1243 attribute. See sections 5.1 and 5.2 for the behavior of "xxx-
1244 supported" Subscription Template Printer attributes.
1246 5.3.3.4. Standard Values for Subscribed Events
1248 Each value of this attribute is a keyword and it specifies a
1249 Subscribed Event that represents certain changes. Some keywords
1250 represent a subset of changes of another keyword, e.g., 'job-
1251 completed' is an Event value which is a sub-value of 'job-state-
1252 change'. See section 5.3.3.5 for the case where this attribute
1253 contains both a value and a sub-value.
1255 The values in this section are divided into three categories: No
1256 Events, Job Events and Printer Events.
1258 A Printer MUST support the Events indicated as "REQUIRED" and MAY
1259 support the Events indicated as "OPTIONAL".
1261 5.3.3.4.1. No Events
1263 The standard and only keyword value for No Events is:
1265 'none': REQUIRED - no Event Notifications for any Events. As the
1266 sole value of "notify-events-supported", this value means that the
1267 Printer does not support the delivery of Event Notifications. As
1268 the sole value of "notify-events-default", this value means that a
1269 client MUST specify the "notify-events" attribute in order for a
1270 Subscription Creation Operation to succeed. If the Printer
1271 receives this value as the sole value of a Subscription Creation
1272 Operation, it does not create a Subscription Object. If a Printer
1273 receives this value with other values of a Subscription Creation
1274 Operation, the Printer MUST treat this value as an unsupported
1277 5.3.3.4.2. Subscribed Printer Events
1279 The standard keyword values for Subscribed Printer Events are:
1281 'printer-state-changed': REQUIRED - the Printer changed state from
1282 any state to any other state. Specifically, the value of the
1283 Printer's "printer-state", "printer-state-reasons" or "printer-
1284 is-accepting-jobs" attributes changed.
1290 Herriot & Hastings Standards Track [Page 23]
1292 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1295 This Subscribed Event value has the following sub-values:
1296 'printer-restarted' and 'printer-shutdown'. A client can listen
1297 for any of these sub-values if it doesn't want to listen to all
1298 printer-state changes:
1300 'printer-restarted': OPTIONAL - when the printer is powered
1303 'printer-shutdown': OPTIONAL - when the device is being
1306 'printer-stopped: REQUIRED - when the printer stops printing,
1307 i.e., the value of the "printer-state" Printer attribute
1310 'printer-config-changed': OPTIONAL - when the configuration of a
1311 Printer has changed, i.e., the value of the "printer-message-
1312 from-operator" or any "configuration" Printer attribute has
1313 changed. A "configuration" Printer attribute is an attribute
1314 which can change value because of some human interaction either
1315 direct or indirect, and which is not covered by one of the other
1316 Events in this section. Examples of "configuration" Printer
1317 attributes are any of the Job Template attributes, such as "xxx-
1318 supported", "xxx-ready" and "xxx-default". The client has to
1319 perform a Get-Printer-Attributes to find out the new values of
1320 these changed attributes. This Event is useful for GUI clients
1321 and drivers to update the available printer capabilities to the
1324 This Event value has the following sub-values: 'printer-media-
1325 changed' and 'printer-finishings-changed'. A client can listen
1326 for any of these sub-values if it doesn't want to listen to all
1327 printer-configuration changes:
1329 'printer-media-changed': OPTIONAL - when the media loaded on
1330 a printer has been changed, i.e., the "media-ready"
1331 attribute has changed. This Event includes two cases: an
1332 input tray that goes empty and an input tray that receives
1333 additional media of the same type or of a different type.
1334 The client must check the "media-ready" Printer attribute
1335 (see [RFC2911] section 4.2.11) separately to find out what
1338 'printer-finishings-changed': OPTIONAL - when the finisher on
1339 a printer has been changed, i.e., the "finishings-ready"
1340 attribute has changed. This Event includes two cases: a
1341 finisher that goes empty and a finisher that is refilled
1342 (even if it is not full). The client must check the
1346 Herriot & Hastings Standards Track [Page 24]
1348 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1351 "finishings-ready" Printer attribute separately to find out
1354 'printer-queue-order-changed': OPTIONAL - the order of jobs in the
1355 Printer's queue has changed, so that an application that is
1356 monitoring the queue can perform a Get-Jobs operation to determine
1357 the new order. This Event does not include when a job enters the
1358 queue (the 'job-created' Event covers that) and does not include
1359 when a job leaves the queue (the 'job-completed' Event covers
1362 5.3.3.4.3. Subscribed Job Events
1364 The standard keyword values for Subscribed Job Events are:
1366 'job-state-changed': REQUIRED - the job has changed from any state
1367 to any other state. Specifically, the Printer delivers this Event
1368 whenever the value of the "job-state" attribute or "job-state-
1369 reasons" attribute changes. When a Job is removed from the Job
1370 Retention or Job History phases (see [RFC2911] section 4.3.7.1),
1371 no Event is generated.
1373 This Event value has the following sub-values: 'job-created',
1374 'job-completed' and 'job-stopped'. A client can listen for any of
1375 these sub-values if it doesn't want to listen to all 'job-state
1378 'job-created': REQUIRED - the Printer has accepted a Job
1379 Creation operation, a Restart-Job operation [RFC2911], or any
1380 job operation that creates a Job object from an existing Job
1381 object. The Printer populates the job's "time-at-creation"
1382 attribute value (see [RFC2911] section 4.3.14.1). The Printer
1383 puts the job in the 'pending', 'pending-held' or 'processing'
1386 'job-completed': REQUIRED - the job has reached one of the
1387 completed states, i.e., the value of the job's "job-state"
1388 attribute has changed to: 'completed', 'aborted', or
1389 'canceled'. The Job's "time-at-completed" and "date-time-at-
1390 completed" (if supported) attributes are set (see [RFC2911]
1391 section 4.3.14). When a Job completes, a Notification
1392 Recipient MAY query the Job using the Get-Job-Attributes
1393 operation. To allow such a query, the Printer retains the Job
1394 in the Job Retention and/or the Job History phases (see
1395 [RFC2911] section 4.3.7.1) for a suitable amount of time that
1396 depends on implementation and the Delivery Methods supported.
1397 The Printer also delivers this Event when a Job is removed with
1398 the Purge-Job operation (see [RFC2911] section 3.2.9). In this
1402 Herriot & Hastings Standards Track [Page 25]
1404 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1407 case, the Event Notification MUST report the 'job-state' as
1408 'canceled' and the Job object is no longer present for query.
1410 'job-stopped: OPTIONAL - when the job stops printing, i.e.,
1411 the value of the "job-state" Job attribute becomes
1412 'processing-stopped'.
1414 'job-config-changed': OPTIONAL - when the configuration of a job has
1415 changed, i.e., the value of the "job-message-from-operator" or any
1416 of the "configuration" Job attributes have changed. A
1417 "configuration" Job attribute is an attribute that can change
1418 value because of some human interaction either direct or indirect.
1419 Examples of "configuration" Job attributes are any of the job
1420 template attributes and the "job-name" attribute. The client
1421 performs a Get-Job-Attributes to find out the new values of the
1422 changed attributes. This Event is useful for GUI clients and
1423 drivers to update the job information to the user.
1425 'job-progress': OPTIONAL - when the Printer has completed Printing a
1426 sheet. See the separate [RFC3381] specification for additional
1427 attributes that a Printer MAY deliver in an Event Notification
1428 caused by this Event. The "notify-time-interval" attribute
1429 affects this Event by causing the Printer NOT to deliver an Event
1430 Notification every time a 'job-progress' Events occurs. See
1431 section 5.3.9 for full details.
1433 5.3.3.5. Rules for Matching of Subscribed Events
1435 When an Event occurs, the Printer MUST find each Subscription object
1436 whose "notify-events" attribute "matches" the Event. The rules for
1437 "matching" of Subscribed Events are described separately for Printer
1438 Events and for Job Events. This section also describes some special
1441 5.3.3.5.1. Rules for Matching of Printer Events
1443 Given that the Printer causes Printer Event E to occur, for each
1444 Per-Job or Per-Printer Subscription S in the Printer, if E equals a
1445 value of this attribute in S or E is a sub-value of a value of this
1446 attribute in S, the Printer MUST generate an Event Notification.
1448 Consider the example. There are three Subscription Objects each with
1449 the Subscribed Printer Event 'printer-state-changed'. Subscription
1450 Object A is a Per-Printer Subscription Object. Subscription Object B
1451 is a Per-Job Subscription Object for Job 1, and Subscription Object C
1452 is a Per-Job Subscription Object for Job 2. When the Printer enters
1453 the 'stopped' state, the Printer delivers an Event Notification to
1454 the Notification Recipients of Subscription Objects A, B, and C
1458 Herriot & Hastings Standards Track [Page 26]
1460 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1463 because this is a Printer Event. Note if Job 1 has already
1464 completed, the Printer would not deliver an Event Notification for
1465 its Subscription Object, even if Job 1 is retained in the Job
1466 Retention and/or the Job History phases (see [RFC2911] section
1469 5.3.3.5.2. Rules for Matching of Job Events
1471 Given that Job J causes Job Event E to occur:
1473 1. For each Per-Printer Subscription S in the Printer, if E equals a
1474 value of this attribute in S or E is a sub-value of a value of
1475 this attribute in S, the Printer MUST generate an Event
1478 2. For each Per-Job Subscription S associated with Job J, if E equals
1479 a value of this attribute in S or E is a sub-value of a value of
1480 this attribute in S, the Printer MUST generate an Event
1483 3. For each Per-Job Subscription S that is NOT associated Job J, if E
1484 equals a value of this attribute in S or E is a sub-value of a
1485 value of this attribute in, the Printer MUST NOT generate an Event
1486 Notification from S.
1488 Consider the example: There are three Subscription Objects listening
1489 for the Job Event 'job-completed'. Subscription Object A is a Per-
1490 Printer Subscription Object. Subscription Object B is a Per-Job
1491 Subscription Object for Job 1, and Subscription Object C is a Per-Job
1492 Subscription Object for Job 2. In addition, Per-Printer Subscription
1493 Object D is listening for the Job Event 'job-state-changed'. When
1494 Job 1 completes, the Printer delivers an Event Notification to the
1495 Notification Recipient of Subscription Object A (because it is Per-
1496 Printer) and Subscription Object B because it is a Per-Job
1497 Subscription Object associated with the Job generating the Event.
1498 The Printer also delivers an Event Notification to the Notification
1499 Recipient of Subscription Object D because 'job-completed' is a sub-
1500 value of 'job-state-changed' - the value that Subscription Object D
1501 is listening for. The Printer does not deliver an Event Notification
1502 to the Notification Recipients of Subscription Object C because it is
1503 a Per-Job Subscription Object associated with some Job other than the
1504 Job generating the Event.
1506 5.3.3.5.3. Special Cases for Matching Rules
1508 This section contains two rules for the special case where a single
1509 Event produces multiple Event Notifications destined for the same
1510 Notification Recipient. These two rules clarify whether a Printer
1514 Herriot & Hastings Standards Track [Page 27]
1516 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1519 should send multiple Event Notifications or consolidate them into a
1520 single Event Notification.
1522 If an Event matches Subscribed Events in two different Subscription
1523 Objects and the Printer would deliver two identical Event
1524 Notifications (except for the "notify-subscription-id" attribute) to
1525 the same Notification Recipient using the same Delivery Method, the
1526 Printer MUST deliver both Event Notifications. That is, the Printer
1527 MUST NOT try to consolidate seemingly identical Event Notifications
1528 that occur in separate Subscription objects. Incidentally, the
1529 Printer MUST NOT reject Subscription Creation Operations that would
1530 create this scenario.
1532 Consider the example: At the time a Job completes, there are two
1533 Per-Printer Subscription Objects A and B with the same Notification
1534 Recipient R. Subscription Object A has the Subscribed Job Event
1535 'job-state-changed'. Subscription Object B has the Subscribed Job
1536 Event 'job-completed'. Both Subscription Objects match the Event
1537 'job-completed'. The Printer delivers two Event Notifications to the
1538 Notification Recipient R. One with the value of 'job-state-changed'
1539 for the "notify-subscribed-event" attribute and the other with the
1540 value of 'job-completed' for the "notify-subscribed-event"
1543 If an Event matches two Subscribed Events in a single Subscription
1544 object (e.g., a value and its sub-value), a Printer MAY deliver one
1545 Event Notification for each matched value in the Subscription Object
1546 or it MAY deliver only a single Event Notification. The rules in
1547 sections 5.3.3.5.1 and 5.3.3.5.2 are purposefully flexible about the
1548 number of Event Notifications sent when Event E matches two or more
1549 values in a Subscription Object.
1551 Consider the example: At the time a Job completes, a Subscription
1552 Object A has two Subscribed Job Events 'job-state-changed' and 'job-
1553 completed'. Both Subscribed Job Events match the Event 'job-
1554 completed'. The Printer delivers either one or two Event
1555 Notifications to the Notification Recipient of Subscription Object A,
1556 depending on implementation. If it delivers two Event Notifications,
1557 one has the value of 'job-state-changed' for the "notify-
1558 subscribed-event" attribute, and the other has the value of 'job-
1559 completed' for the "notify-subscribed-event" attribute. If it
1560 delivers one Event Notification, it has the value of either 'job-
1561 state-changed' or 'job-completed' for the "notify-subscribed-event"
1562 attribute, depending on implementation. The algorithm for choosing
1563 such a value is implementation dependent.
1570 Herriot & Hastings Standards Track [Page 28]
1572 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1575 5.3.4. notify-attributes (1setOf type2 keyword)
1577 This attribute contains a set of attribute names. When a Printer
1578 delivers a Machine Consumable Event Notification, it includes a fixed
1579 set of attributes (see section 9.1). If this attribute is present
1580 and the Event Notification is Machine Consumable, the Printer also
1581 includes the attributes specified by this attribute.
1583 A Printer MAY support this attribute.
1585 A client MAY supply this attribute in a Subscription Creation
1586 Operation. If the client does not supply this attribute in
1587 Subscription Creation Operation or the Printer does not support this
1588 attribute, the Subscription Object either (1) MAY contain the
1589 "notify-attributes" attribute with a 'none' value or (2) NEED NOT
1590 contain the attribute at all. There is no "notify-attributes-
1591 default" Printer attribute.
1593 Each keyword value of this attribute on a Subscription Object MUST be
1594 a value of the "notify-attributes-supported (1setOf type2 keyword)"
1595 Printer attribute (see section 5.3.4.1). The "notify-attributes-
1596 supported" MAY contain any Printer attribute, Job attribute or
1597 Subscription Object attribute that the Printer supports in an Event
1598 Notification. It MUST NOT contain any of the attributes in Section
1599 9.1 that a Printer automatically puts in an Event Notification; it
1600 would be redundant. If a client supplies an attribute in Section
1601 9.1, the Printer MUST treat it as an unsupported attribute value of
1602 the "notify-attributes" attribute.
1604 The following rules apply to each keyword value N of the "notify-
1605 attributes" attribute: If the value N names:
1607 a) a Subscription attribute, the Printer MUST use the attribute N in
1608 the Subscription Object that is being used to generate the Event
1611 b) a Job attribute and the Printer is generating an Event
1612 Notification from a Per-Job Subscription Object S, the Printer
1613 MUST use the attribute N in the Job object associated with S.
1615 c) a Job attribute and the Printer is generating an Event
1616 Notification from a Per-Printer Subscription Object and the Event
1619 - a Job Event, the Printer MUST use the attribute N in the Job
1620 object that caused the Event.
1626 Herriot & Hastings Standards Track [Page 29]
1628 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1631 - a Printer Event, the Printer MUST use the attribute N in the
1634 If a Printer supports this attribute and a Subscription Object
1635 contains this attribute and the Delivery Method generates a Machine
1636 Consumable Event Notification, the Printer MUST include in each Event
1639 a) the attributes specified in section 9.1 and
1641 b) each attribute named by this attribute.
1643 The Printer MUST NOT use this attribute to generate a Human
1644 Consumable Event Notification.
1646 5.3.4.1. notify-attributes-supported (1setOf type2 keyword)
1648 See sections 5.1 and 5.2 for the behavior of "xxx-supported"
1649 Subscription Template Printer attributes.
1651 5.3.5. notify-user-data (octetString(63))
1653 This attribute contains opaque data that some Delivery Methods
1654 include in each Machine Consumable Event Notification. The opaque
1655 data might contain, for example:
1657 - the identity of the Subscriber
1659 - a path or index to some Subscriber information
1661 - a key that identifies to the Notification Recipient the ultimate
1662 recipient of the Event Notification
1664 - the id for a Notification Recipient that had previously registered
1665 with an Instant Messaging Service
1667 A Printer MUST support this attribute.
1669 A client MAY supply this attribute in a Subscription Creation
1670 Operation. If the client does not supply this attribute in the
1671 Subscription Creation Operation, the Subscription Object either (1)
1672 MAY contain the "notify-user-data" attribute with a zero length value
1673 or (2) NEED NOT contain the attribute at all. There is no "notify-
1674 user-data-default" Printer attribute.
1682 Herriot & Hastings Standards Track [Page 30]
1684 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1687 There is no "notify-user-data-supported" Printer attribute. Rather,
1688 any octetString whose length does not exceed 63 octets is a supported
1689 value. If the length exceeds 63 octets, the Printer MUST treat it as
1690 an unsupported value.
1692 5.3.6. notify-charset (charset)
1694 This attribute specifies the charset to be used in the Event
1695 Notification content sent to the Notification Recipient, whether the
1696 Event Notification content is Machine Consumable or Human Consumable.
1698 A Printer MUST support this attribute.
1700 A client MAY supply this attribute in a Subscription Creation
1701 Operation. If the client does not supply this attribute in
1702 Subscription Creation Operation or supplies an unsupported value, the
1703 Printer MUST populate this attribute in the Subscription Object with
1704 the value of the "attributes-charset" operation attribute, which is a
1705 REQUIRED attribute in all IPP requests (see [RFC2911]). If the value
1706 of the "attributes-charset" attribute is unsupported, the Printer
1707 MUST populate this attribute in the Subscription Object with the
1708 value of the Printer's "charset-configured" attribute. There is no
1709 "notify-charset-default" Printer attribute.
1711 The value of this attribute on a Subscription Object MUST be a value
1712 of the "charset-supported (1setOf charset)" Printer attribute.
1714 5.3.7. notify-natural-language (naturalLanguage)
1716 This attribute specifies the natural language to be used in any human
1717 consumable text in the Event Notification content sent to the
1718 Notification Recipient, whether the Event Notification content is
1719 Machine Consumable or Human Consumable.
1721 A Printer MUST support this attribute.
1723 A client MAY supply this attribute in a Subscription Creation
1724 Operation. If the client does not supply this attribute in
1725 Subscription Creation Operation or supplies an unsupported value, the
1726 Printer MUST populate this attribute in the Subscription Object with
1727 the value of the "attributes-natural-language" operation attribute,
1728 which is a REQUIRED attribute in all IPP requests (see [RFC2911]
1729 section 3.1.4). If the value of the "attributes-natural-language"
1730 attribute is unsupported, the Printer MUST populate this attribute in
1731 the Subscription Object with the value of the Printer's "natural-
1732 language-configured" attribute (see [RFC2911] section 4.4.19). There
1733 is no "notify-natural-language-default" Printer attribute.
1738 Herriot & Hastings Standards Track [Page 31]
1740 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1743 The value of this attribute on a Subscription Object MUST be a value
1744 of the "generated-natural-language-supported (1setOf type2
1745 naturalLanguage)" Printer attribute (see [RFC2911] section 4.4.20).
1747 5.3.8. notify-lease-duration (integer(0:67108863))
1749 This attribute specifies the duration of the lease (in seconds)
1750 associated with the Per-Printer Subscription Object at the time the
1751 Subscription Object was created or the lease was renewed. The
1752 duration of the lease is infinite if the value is 0, i.e., the lease
1753 never expires. See section 5.4.3 on "notify-lease-expiration-time
1754 (integer(0:MAX))" for more details.
1756 This attribute is not present on a Per-Job Subscription Object
1757 because the Subscription Object lasts exactly as long as the
1758 associated Job object. See discussion of the 'job-completed' event
1759 in section 5.3.3.4.3 about retention of the Job object after
1762 A Printer MUST support this attribute.
1764 For a Subscription Object Creation operation of a Per-Job
1765 Subscription Object, the client MUST NOT supply this attribute. If
1766 the client does supply this attribute, the Printer MUST treat it as
1767 an unsupported attribute.
1769 For a Subscription Creation Operation of a Per-Printer Subscription
1770 Object or a Renew-Subscription operation, a client MAY supply this
1771 attribute. If the client does not supply this attribute, the Printer
1772 MUST populate this attribute with its "notify-lease-duration-default"
1773 (0:67108863) attribute value. If the client supplies this attribute
1774 with an unsupported value, the Printer MUST populate this attribute
1775 with a supported value, and this value SHOULD be as close as possible
1776 to the value requested by the client. Note: this rule implies that a
1777 Printer doesn't assign the value of 0 (infinite) unless the client
1780 After the Printer has populated this attribute with a supported
1781 value, the value represents the "granted duration" of the lease in
1782 seconds and the Printer updates the value of the Subscription
1783 Object's "notify-lease-expiration-time" attribute as specified in
1786 The value of this attribute on a Subscription Object MUST be a value
1787 of the "notify-lease-duration-supported" (1setOf (integer(0:67108863)
1788 | rangeOfInteger(0:67108863))) Printer attribute.
1794 Herriot & Hastings Standards Track [Page 32]
1796 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1799 A Printer MAY require authentication in order to return the value of
1800 0 (the lease never expires) as one of the values of "notify-lease-
1801 duration-supported", and to allow 0 as a value of the "notify-lease-
1802 duration" attribute.
1804 Note: The maximum value 67,108,863 is 2 raised to the 26 power minus
1805 1 and is about 2 years in seconds. The value is considerably less
1806 than MAX so that there is virtually no chance of an overflow when the
1807 Printer adds it to the Printer's "printer-up-time" attribute value
1808 (see [RFC2911] section 4.4.29) to produce the "notify-lease-
1809 expiration-time" Subscription Description attribute value (see
1812 5.3.8.1. notify-lease-duration-default (integer(0:67108863))
1814 See sections 5.1 and 5.2 for the behavior of "xxx-default"
1815 Subscription Template Printer attributes.
1817 5.3.8.2. notify-lease-duration-supported (1setOf (integer(0: 67108863) |
1818 rangeOfInteger(0:67108863)))
1820 See sections 5.1 and 5.2 for the behavior of "xxx-supported"
1821 Subscription Template Printer attributes.
1823 5.3.9. notify-time-interval (integer(0:MAX))
1825 The 'job-progress' Event occurs each time that a Printer completes a
1826 sheet. Some Notification Recipients do not want to receive an Event
1827 Notification every time this Event occurs. This attribute allows a
1828 Subscribing Client to request how often it wants to receive Event
1829 Notifications for 'job-progress' Events. The value of this attribute
1830 MAY be any nonnegative integer (0,MAX) indicating the minimum number
1831 of seconds between 'job-progress' Event Notifications.
1833 The Printer MUST support this attribute if and only if the Printer
1834 supports the 'job-progress' Event.
1836 A client MAY supply this attribute in a Subscription Creation
1837 Operation. If the client does not supply this attribute in the
1838 Subscription Creation Operation, the Subscription Object either (1)
1839 MAY contain the "notify-time-interval" attribute with a '0' value or
1840 (2) NEED NOT contain this attribute at all. There is no "notify-
1841 time-interval-default" Printer attribute.
1843 There is no "notify-time-interval-supported" Printer attribute.
1850 Herriot & Hastings Standards Track [Page 33]
1852 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1855 If the 'job-progress' Event occurs and a Subscription Object contains
1856 the 'job-progress' Event as a value of the 'notify-events' attribute,
1857 there are two cases to consider:
1859 1. This attribute is not present on the Subscription Object or has
1860 the value of 0. The Printer MUST generate and deliver an Event
1861 Notification (as is the case with other Events).
1863 2. This attribute is present with a nonzero value of N:
1865 a) If the Printer has not sent an Event Notification for the
1866 'job-progress' Event for the associated Subscription Object
1867 within the past N seconds, the Printer MUST deliver an Event
1868 Notification for the Event that just occurred. Note when the
1869 Printer completes the first page of a Job, this rule implies
1870 that the Printer delivers an Event Notification for a Per-Job
1871 Subscription Object.
1873 b) Otherwise, the Printer MUST NOT generate or deliver an Event
1874 Notification for the associated Subscription Object. The
1875 Printer MUST NOT increase the value of the "notify-sequence-
1876 number" Subscription Object attribute (i.e., the sequence of
1877 values of the "notify-sequence-number" attribute counts the
1878 Event Notifications that the Printer sent and not the Events
1879 that do not cause an Event Notification to be sent).
1881 It is RECOMMENDED that a Subscribing Client use this attribute when
1882 it subscribes to the 'job-progress' Event, and that the value be
1883 sufficiently large to limit the frequency with which the Printer
1884 delivers Event Notifications requests.
1886 This attribute MUST NOT effect any Events other than 'job-progress'.
1888 5.4. Subscription Description Attributes
1890 Subscription Description Attributes are those attributes that a
1891 Printer adds to a Subscription Object at the time of its creation.
1893 A Printer MUST support all attributes in this Table 2.
1895 A client MUST NOT supply the attributes in Table 2 in a Subscription
1896 Template Attributes Group of a Subscription Creation Operation.
1897 There are no corresponding default or supported attributes.
1906 Herriot & Hastings Standards Track [Page 34]
1908 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1911 Table 2 - Subscription Description Attributes
1913 Subscription Object attributes:
1915 notify-subscription-id (integer(1:MAX))
1916 notify-sequence-number (integer(0:MAX))
1917 notify-lease-expiration-time (integer(0:MAX))
1918 notify-printer-up-time (integer(1:MAX))
1919 notify-printer-uri (uri)
1920 notify-job-id (integer(1:MAX))
1921 notify-subscriber-user-name (name(MAX))
1923 5.4.1. notify-subscription-id (integer (1:MAX))
1925 This attribute identifies a Subscription Object instance with a
1926 number that is unique within the context of the Printer. The Printer
1927 generates this value at the time it creates the Subscription Object.
1929 A Printer MUST support this attribute.
1931 The Printer MAY assign the value of this attribute sequentially as it
1932 creates Subscription Objects. However, if there is no security on
1933 Subscription objects, sequential assignment exposes the system to a
1934 passive traffic monitoring threat.
1936 The Printer SHOULD avoid re-using recent values of this attribute
1937 during continuous operation of the Printer as well as across power
1938 cycles. Then a Subscribing Client is unlikely to find that a stale
1939 reference accesses a new Subscription Object.
1941 The 0 value is not permitted in order to allow for compatibility with
1942 "job-id" and with MIB table index values, which are recommended not
1945 5.4.2. notify-sequence-number (integer (0:MAX))
1947 The value of this attribute indicates the number of times that the
1948 Printer has generated and attempted to deliver an Event Notification
1949 for this Subscription object. When an Event Notification contains
1950 this attribute, the Notification Recipient can determine whether it
1951 missed some Event Notifications (i.e., numbers skipped) or received
1952 duplicates (i.e., same number twice).
1954 A Printer MUST support this attribute.
1956 When the Printer creates a Subscription Object, it MUST populate this
1957 attribute with a value of 0. This value indicates that the Printer
1958 has not sent any Event Notifications for this Subscription Object.
1962 Herriot & Hastings Standards Track [Page 35]
1964 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
1967 Each time the Printer delivers a newly generated Event Notification,
1968 it MUST increase the value of this attribute by 1. For some Delivery
1969 Methods, the Printer MUST include this attribute in each Event
1970 Notification, and the value MUST be the value after it is increased
1971 by 1. That is, the value of this attribute in the first Event
1972 Notification after Subscription object creation MUST be 1, the second
1973 MUST be 2, etc. If a Delivery Method is defined such that the
1974 Notification Recipient returns a response, the Printer can re-try
1975 delivering an Event Notification a certain number of times with the
1976 same sequence number when the Notification Recipient fails to return
1979 If a Subscription Object lasts long enough to reach the value of MAX,
1980 its next value MUST be 0, i.e., it wraps.
1982 5.4.3. notify-lease-expiration-time (integer(0:MAX))
1984 This attribute specifies the time in the future when the lease on the
1985 Per-Printer Subscription Object will expire, i.e., the "printer-up-
1986 time" value at which the lease will expire. If the value is 0, the
1987 lease never expires.
1989 A Printer MUST support this attribute.
1991 When the Printer creates a Per-Job Subscription Object, this
1992 attribute MUST NOT be present - the Subscription Object lasts exactly
1993 as long as the associated Job object. See also the discussion of the
1994 'job-completed' event in section 5.3.3.4.3 about retention of the Job
1995 object after completion so that a Notification Recipient can query
1996 the Job object after receiving the 'job-completed' Event
1999 When the Printer creates a Per-Printer Subscription Object, it
2000 populates this attribute with a value that is the sum of the values
2001 of the Printer's "printer-up-time" attribute and the Subscription
2002 Object's "notify-lease-duration" attribute with the following
2003 exception. If the value of the Subscription Object's "notify-lease-
2004 duration" attribute is 0 (i.e., no expiration time), then the value
2005 of this attribute MUST be set to 0 (i.e., no expiration time).
2007 When the Printer powers up, it MUST populate this attribute in each
2008 persistent Subscription Object with a value using the algorithm in
2009 the previous paragraph.
2011 When the "printer-up-time" equals the value of this attribute, the
2012 Printer MUST delete the Subscription Object. A client can extend a
2013 lease of a Per-Printer Subscription Object with the Renew-
2014 Subscription operation (see section 11.2.6).
2018 Herriot & Hastings Standards Track [Page 36]
2020 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2023 Note: In order to compute the number of seconds remaining in a lease
2024 for a Per-Printer Subscription Object, a client can subtract the
2025 Subscription's "notify-printer-up-time" attribute (see section 5.4.4)
2026 from the Subscription's "notify-lease-expiration-time" attribute.
2028 5.4.4. notify-printer-up-time (integer(1:MAX))
2030 This attribute is an alias for the Printer's "printer-up-time"
2031 attribute " (see [RFC2911] section 4.4.29). In other words, when
2032 this attribute is queried with the Get-Subscriptions or Get-
2033 Subscription-Attributes operations (see sections 11.2.4 and 11.2.5),
2034 the value returned is the current value of the Printer's "printer-
2035 up-time" attribute, rather than the time at which the Subscription
2038 A Printer MUST support this attribute.
2040 When the Printer creates a Per-Job Subscription Object, this
2041 attribute MUST NOT be present. When the Printer creates a Per-
2042 Printer Subscription Object, this attribute MUST be present.
2044 Note: this attribute exists in a Per-Printer Subscription Object so
2045 that a client using the Get-Subscription-Attributes or Get-
2046 Subscription operations can convert the Per-Printer Subscription's
2047 "notify-lease-expiration-time" attribute to wall clock time with one
2048 request. If the value of the "notify-lease-expiration-time"
2049 attribute is not 0 (i.e., no expiration time), then the difference
2050 between the "notify-lease-expiration-time" attribute and the
2051 "notify-printer-up-time" is the remaining number of seconds on the
2052 lease from the current time.
2054 5.4.5. notify-printer-uri (uri)
2056 This attribute identifies the Printer object that created this
2057 Subscription Object.
2059 A Printer MUST support this attribute.
2061 During a Subscription Creation Operation, the Printer MUST populate
2062 this attribute with the value of the "printer-uri" operation
2063 attribute in the request. From the Printer URI, the client can, for
2064 example, determine what security scheme was used.
2066 5.4.6. notify-job-id (integer(1:MAX))
2068 This attribute specifies whether the containing Subscription Object
2069 is a Per-Job or Per-Printer Subscription Object, and for Per-Job
2070 Subscription Objects, it specifies the associated Job.
2074 Herriot & Hastings Standards Track [Page 37]
2076 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2079 A Printer MUST support this attribute.
2081 If this attribute is not present, the Subscription Object MUST be a
2082 Per-Printer Subscription. If this attribute is present, the
2083 Subscription Object MUST be a Per-Job Subscription Object and this
2084 attribute MUST identify the Job with which the Subscription Object is
2087 Note: This attribute could be useful to a Notification Recipient that
2088 receives an Event Notification generated from a Per-Job Subscription
2089 Object and caused by a Printer Event. The Event Notification gives
2090 access to the Printer and the Subscription Object. The Event
2091 Notification gives access to the associated Job only via this
2092 attribute. See discussion of the 'job-completed' event in section
2093 5.3.3.4.3 about retention of the Job object after completion so that
2094 a Notification Recipient can query the Job object after receiving the
2095 'job-completed' Event Notification.
2097 5.4.7. notify-subscriber-user-name (name(MAX))
2099 This attribute contains the name of the user who performed the
2100 Subscription Creation Operation.
2102 A Printer MUST support this attribute.
2104 The Printer MUST populates this attribute with the most authenticated
2105 printable name that it can obtain from the authentication service
2106 over which the Subscription Creation Operation was received. The
2107 Printer uses the same mechanism for determining the value of this
2108 attribute as it does for a Job's "job-originating-user-name" (see
2109 [RFC2911] section 4.3.6).
2111 Note: To help with authentication, a Subscription Object may have
2112 additional private attributes about the user, e.g., a credential of a
2113 principal. Such private attributes are implementation-dependent and
2114 not defined in this document.
2116 6. Printer Description Attributes Related to Notification
2118 This section defines the Printer Description attributes that are
2119 related to Notification. Table 3 lists the Printer Description
2120 attributes, indicates the Printer support required for conformance,
2121 and whether or not the attribute is READ-ONLY (see section 3.1):
2130 Herriot & Hastings Standards Track [Page 38]
2132 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2135 Table 3 - Printer Description Attributes Associated with Notification
2137 Printer object attributes: REQUIRED READ-ONLY
2139 printer-state-change-time (integer(1:MAX)) No Yes
2140 printer-state-change-date-time (dateTime) No Yes
2142 6.1. printer-state-change-time (integer(1:MAX))
2144 This OPTIONAL attribute records the most recent time at which the
2145 'printer-state-changed' Printer Event occurred whether or not any
2146 Subscription objects were listening for this event. This attribute
2147 helps a client or operator to determine how long the Printer has been
2148 in its current state.
2150 A Printer MAY support this attribute and if so, the attribute MUST be
2153 On power-up, the Printer MUST populate this attribute with the value
2154 of its "printer-up-time" attribute, so that it always has a value.
2155 Whenever the 'printer-state-changed' Printer Event occurs, the
2156 Printer MUST update this attribute with the value of the Printer's
2157 "printer-up-time" attribute.
2159 6.2. printer-state-change-date-time (dateTime)
2161 This OPTIONAL attribute records the most recent time at which the
2162 'printer-state-changed' Printer Event occurred whether or not there
2163 were any Subscription Objects listening for this event. This
2164 attribute helps a client or operator to determine how long the
2165 Printer has been in its current state.
2167 A Printer MAY support this attribute and if so, the attribute MUST be
2170 On power-up, the Printer MUST populate this attribute with the value
2171 of its "printer-current-time" attribute, so that it always has a
2172 value (see [RFC2911] section 4.4.30 on "printer-current-time").
2173 Whenever the 'printer-state-changed' Printer Event occurs, the
2174 Printer MUST update this attribute with the value of the Printer's
2175 "printer-current-time" attribute.
2177 7. New Values for Existing Printer Description Attributes
2179 This section contains those attributes for which additional values
2186 Herriot & Hastings Standards Track [Page 39]
2188 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2191 7.1. operations-supported (1setOf type2 enum)
2193 The following "operation-id" values are added in order to support the
2194 new operations defined in this document:
2196 Table 4 - Operation-id assignments
2198 Value Operation Name
2200 0x0016 Create-Printer-Subscriptions
2201 0x0017 Create-Job-Subscriptions
2202 0x0018 Get-Subscription-Attributes
2203 0x0019 Get-Subscriptions
2204 0x001A Renew-Subscription
2205 0x001B Cancel-Subscription
2207 8. Attributes Only in Event Notifications
2209 This section contains those attributes that exist only in Event
2210 Notifications and do not exist in any objects.
2212 8.1. notify-subscribed-event (type2 keyword)
2214 This attribute indicates the Subscribed Event that caused the Printer
2215 to deliver this Event Notification. This attribute exists only in
2216 Event Notifications.
2218 This attribute MUST contain one of the values of the "notify-events"
2219 attribute in the Subscription Object, i.e., one of the Subscribed
2220 Event values. Its value is the Subscribed Event that "matches" the
2221 Event that caused the Printer to deliver this Event Notification.
2222 This Subscribed Event value may be identical to the Event or the
2223 Event may be a sub-value of the Subscribed Event. For example, the
2224 'job-completed' Event (which is a sub-event of the 'job-state-
2225 changed' event) would cause the Printer to deliver an Event
2226 Notification for either the 'job-completed' or 'job-state-changed'
2227 Subscribed Events and to deliver the 'job-completed' or 'job-state-
2228 changed' value for this attribute, respectively. See section 5.3.3.5
2229 for the "matching" rules of Subscribed Events and for additional
2232 The Delivery Method Document specifies whether the Printer includes
2233 the value of this attribute in an Event Notification.
2242 Herriot & Hastings Standards Track [Page 40]
2244 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2247 8.2. notify-text (text(MAX))
2249 This attribute contains a Human Consumable text message (see section
2250 9.2). This message describes the Event and is encoded as plain text,
2251 i.e., 'text/plain' with the charset specified by Subscription
2252 Object's "notify-charset" attribute.
2254 Note: this attribute contains a text message only and must not
2255 contain any encoding information, such as 'text/plain'. The
2256 'text/plain' encoding is implicit and thus the charset must be
2257 specified by an alternate mechanism, namely the "notify-charset"
2260 The Delivery Method Document specifies whether the Printer includes
2261 this attribute in an Event Notification.
2263 9. Event Notification Content
2265 This section defines the Event Notification content that the Printer
2266 delivers when an Event occurs.
2268 When an Event occurs, the Printer MUST find each Subscription object
2269 whose "notify-events" attribute "matches" the Event. See section
2270 5.3.3.5 for details on "matching". For each matched Subscription
2271 Object, the Printer MUST create an Event Notification with the
2272 content and format that the Delivery Method Document specifies. The
2273 content contains the value of attributes specified by the Delivery
2274 Method Document. The Printer obtains the values immediately after
2275 the Event occurs. For example, if the "printer-state" attribute
2276 changes from 'idle' to 'processing', the Event 'printer-state-
2277 changed' occurs and the Printer puts various attributes into the
2278 Event Notification, including "printer-up-time" and "printer-state"
2279 with the values that they have immediately after the Event occurs,
2280 i.e., the value of "printer-state" is 'processing'.
2282 Event Notification Ordering:
2284 When a Printer delivers Event Notifications, the Event Notifications
2285 from any given Subscription Object MUST be in time stamp order, i.e.,
2286 in order of increasing "printer-up-time" attribute value in the Event
2287 Notification (see Table 5). These Event Notifications MAY be
2288 interleaved with those from other Subscription Objects, as long as
2289 those others are also in time stamp order. The Printer MUST observe
2290 these ordering requirements whether delivering multiple pending
2291 Events as multiple separate Event Notifications or together in a
2292 single Compound Event Notification.
2298 Herriot & Hastings Standards Track [Page 41]
2300 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2303 If a Subscribing Client wants the Printer to deliver certain Event
2304 Notifications in time stamp order, the Subscribing Client uses a
2305 single Subscription Object. Even so, depending on the underlying
2306 transport, the actual order that a Notification Recipient receives
2307 separate Event Notifications may differ from the order sent by the
2308 Printer (e.g., email).
2310 Example: Consider two Per-Printer Subscription Objects: SO1 and SO2.
2311 SO1 requests 'job-state-changed' events and SO2 requests 'printer-
2312 state-changed' events. The number in parens is the time stamp. The
2313 following Event Notification sequences are the only ones that conform
2314 to the ordering requirements for the Printer to deliver the Event
2317 (a) SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO1:
2318 'job-completed' (1009), SO2: 'printer-stopped' (1005)
2320 (b) SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO2:
2321 'printer-stopped' (1005), SO1: 'job-completed' (1009)
2323 (c) SO1: 'job-created' (1000), SO2: 'printer-stopped' (1005), SO1:
2324 'job-stopped' (1005), SO1: 'job-completed' (1009)
2326 (d) SO2: 'printer-stopped (1005), SO1: 'job-created' (1000), SO1:
2327 'job-stopped' (1005), SO1: 'job-completed' (1009)
2329 Examples (b) and (c) are interleaved; examples (a) and (d) are not
2330 interleaved and are not appropriate for some Delivery Methods.
2332 If two different Events occur simultaneously, or nearly so (e.g.,
2333 "printer-up-time" has the same value for both), the Printer MUST
2334 create a separate Event Notification for each Event, even if the
2335 associated Subscription Object is the same for both Events. However,
2336 the Printer MAY combine these distinct Event Notifications into a
2337 single Compound Event Notification if the Delivery Method supports
2338 Compound Event Notifications. For example, suppose that two nearly-
2339 simultaneously Events represent two successive 'printer-state-
2340 changed' Events, one from 'idle' to 'processing' and another from
2341 'processing' to 'stopped'. These two Events have the same name but
2342 are different instances of the Event. Then the Printer MUST create a
2343 separate Event Notification for each Event and SHOULD accurately
2344 report the "printer-state" of the first Event as 'processing' and the
2345 second Event as 'stopped'.
2347 If a Subscription Object contains more than one Subscribed Event, and
2348 several Events occur in quick succession each matching a different
2349 Subscribed Event in the Subscription Object, the Printer MUST NOT
2350 generate a single Event Notification from several of these Events,
2354 Herriot & Hastings Standards Track [Page 42]
2356 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2359 but MAY combine distinct Event Notifications into a single Compound
2360 Event Notification if the Delivery Method supports Compound Event
2363 After the Printer has created the Event Notification, the Printer
2364 delivers it via either a:
2366 Push Delivery Method: The Printer delivers the Event Notification
2367 shortly after an Event occurs. For some Push Delivery Methods,
2368 the Notification Recipient MUST deliver a response; for others it
2369 MUST NOT deliver a response.
2371 Pull Delivery Method: The Printer saves Event Notifications for
2372 some Event Life and expects the Notification Recipient to request
2373 Event Notifications. The Printer returns the Event Notifications
2374 in a response to such a request.
2376 If an error that meets the following conditions occurs, the Printer
2377 MUST cancel the Subscription Object.
2379 a) the error occurs during the delivering of an Event Notification
2380 generated from Subscription Object S AND
2382 b) the error would continue to occur every time the Printer delivers
2383 an Event Notification generated from Subscription Object S in the
2386 For example, if the address of the "notify-recipient-uri" of
2387 Subscription Object A references a non-existent target and the
2388 Printer determines this fact, it MUST delete Subscription Object A.
2390 The next two sections describe the values that a Printer delivers in
2391 the content of Machine Consumable and Human Consumable Event
2392 Notifications, respectively.
2394 The tables in the sub-sections of this section contain the following
2397 a) Source Value: the name of the attribute that supplies the value
2398 for the Event Notification. Asterisks in this field refer to a
2399 note below the table.
2401 b) Delivers: if the Printer supports the value (column 1) on the
2402 Source Object (column 3) the Delivery Method MUST specify:
2404 MUST: that the Printer MUST deliver the value.
2410 Herriot & Hastings Standards Track [Page 43]
2412 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2415 SHOULD: either that the Printer MUST deliver the value or that
2416 the value is incompatible with the Delivery Method.
2418 MAY: that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT,
2419 or NEED NOT deliver the value. The Delivery Method specifies
2420 the level of conformance for the Printer.
2422 c) Source Object: the object from which the source value comes. If
2423 the object is "Event Notification", the Printer fabricates the
2424 value when it delivers the Event Notification. See section 8.
2426 9.1. Content of Machine Consumable Event Notifications
2428 This section defines the attributes that a Delivery Method MUST
2429 mention in a Delivery Method Document when specifying the Machine
2430 Consumable Event Notification's contents.
2432 This document does not define the order of attributes in Event
2433 Notifications. However, Delivery Method Documents MAY define the
2434 order of some or all of the attributes.
2436 A Delivery Method Document MUST specify additional attributes (if
2437 any) that a Printer implementation delivers in a Machine Consumable
2440 Notification Recipients MUST be able to accept Event Notifications
2441 containing attributes they do not recognize. What a Notification
2442 Recipient does with an unrecognized attribute is implementation-
2443 dependent. Notification Recipients MAY attempt to display
2444 unrecognized attributes anyway or MAY ignore them.
2446 The next three sections define the attributes in Event Notification
2451 2. for Job Events only
2453 3. for Printer Events only
2455 9.1.1. Event Notification Content Common to All Events
2457 This section lists the attributes that a Delivery Method Document
2458 MUST specify for all Events.
2460 Table 5 lists potential values in each Event Notification.
2466 Herriot & Hastings Standards Track [Page 44]
2468 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2471 Table 5 - Attributes in Event Notification Content
2473 Source Value Delivers Source Object
2475 notify-subscription-id (integer(1:MAX)) MUST Subscription
2476 notify-printer-uri (uri) MUST Subscription
2477 notify-subscribed-event (type2 keyword) MUST Event
2479 printer-up-time (integer(MIN:MAX)) MUST Printer
2480 printer-current-time (dateTime) * MUST Printer
2481 notify-sequence-number (integer (0:MAX)) SHOULD Subscription
2482 notify-charset (charset) SHOULD Subscription
2483 notify-natural-language (naturalLanguage) SHOULD Subscription
2484 notify-user-data (octetString(63)) ** SHOULD Subscription
2485 notify-text (text) SHOULD Event
2487 attributes from the "notify-attributes" MAY Printer
2489 attributes from the "notify-attributes" MAY Job
2491 attributes from the "notify-attributes" MAY Subscription
2494 *A Printer MUST deliver this value only if and only if it supports
2495 the Printer's "printer-current-time" attribute.
2497 ** If the Subscription Object does not contain a "notify-user-data"
2498 attribute and the Delivery Method Document REQUIRES the Printer to
2499 deliver the "notify-user-data" source value in the Event
2500 Notification, the Printer MUST deliver an octet-string of length 0.
2502 *** The last three rows represent additional attributes that a client
2503 MAY request via the "notify-attributes" attribute. A Printer MAY
2504 support the "notify-attributes" attribute. The Delivery Method MUST
2505 say that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, or NEED
2506 NOT support the "notify-attributes" attribute and specific values of
2507 this attribute. The Delivery Method MAY say that support for the
2508 "notify-attributes" is conditioned on support of the attribute by the
2509 Printer or it MAY say that Printer MUST support the "notify-
2510 attributes" attribute if the Printer supports the Delivery Method.
2512 9.1.2. Additional Event Notification Content for Job Events
2514 This section lists the additional attributes that a Delivery Method
2515 Document MUST specify for Job Events. See Table 6.
2522 Herriot & Hastings Standards Track [Page 45]
2524 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2527 Table 6 - Additional Event Notification Content for Job Events
2529 Source Value Delivers Source
2532 job-id (integer(1:MAX)) MUST Job
2533 job-state (type1 enum) MUST Job
2534 job-state-reasons (1setOf type2 keyword) MUST Job
2535 job-impressions-completed (integer(0:MAX)) * MUST Job
2537 * The Printer MUST deliver the "job-impressions-completed" attribute
2538 in an Event Notification only for the combinations of Events and
2539 Subscribed Events shown in Table 7.
2541 Table 7 - Combinations of Events and Subscribed Events for "job-
2542 impressions-completed"
2544 Job Event Subscribed Job Event
2546 'job-progress' 'job-progress'
2547 'job-completed' 'job-completed'
2548 'job-completed' 'job-state-changed'
2550 9.1.3. Additional Event Notification Content for Printer Events
2552 This section lists the additional attributes that a Delivery Method
2553 Document MUST specify for Printer Events. See Table 8.
2555 Table 8 - Additional Event Notification Content for Printer Events
2557 Source Value Delivers Source Object
2559 printer-state (type1 enum) MUST Printer
2560 printer-state-reasons (1setOf type2 MUST Printer
2562 printer-is-accepting-jobs (boolean) MUST Printer
2564 9.2. Content of Human Consumable Event Notification
2566 This section defines the information that a Delivery Method MUST
2567 mention in a Delivery Method Document when specifying the Human
2568 Consumable Event Notifications contents or the value of the "notify-
2571 Such a Delivery Method MUST specify the following information and a
2572 Printer SHOULD deliver it:
2574 a) the Printer name (see Table 9)
2578 Herriot & Hastings Standards Track [Page 46]
2580 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2583 b) the time of the Event (see Table 11)
2585 c) for Printer Events only:
2587 i) the Event (see Table 10) and/or Printer state information (see
2590 d) for Job Events only:
2592 i) the job identity (see Table 12)
2594 ii) the Event (see Table 10) and/or Job state information (see
2597 The subsections of this section specify the attributes that a Printer
2598 MUST use to obtain this information.
2600 A Delivery Method Document MUST specify additional information (if
2601 any) that a Printer implementation delivers in a Human Consumable
2602 Event Notification or in the "notify-text" attribute.
2604 A client MUST NOT request additional attributes via the "notify-
2605 attributes" attribute because this attribute works only for Machine
2606 Consumable Event Notifications.
2608 Notification Recipients MUST NOT expect to be able to parse the Human
2609 Consumable Event Notification contents or the value of the "notify-
2612 The next three sections define the attributes in Event Notification
2616 b) for Job Events only
2617 c) for Printer Events only
2619 9.2.1. Event Notification Content Common to All Events
2621 This section lists the source of the information that a Delivery
2622 Method MUST specify for all Events.
2624 There is a separate table for each piece of information. Each row in
2625 the table represents a source value for the information and the
2626 values are listed in order of preference, with the first one being
2627 the preferred one. An implementation SHOULD use the source value
2628 from the earliest row in each table. It MAY use the source value
2634 Herriot & Hastings Standards Track [Page 47]
2636 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2639 from another row instead, or it MAY combine the source values from
2640 several rows. An implementation is free to determine the best way to
2641 present this information.
2643 In all tables of this section, all rows contain a "MAY" in order to
2644 state that the Delivery Method specifies the conformance.
2646 Table 9 lists the source of the information for the Printer Name.
2647 The "printer-name" is more user-friendly unless the Notification
2648 Recipient is in a place where the Printer name is not meaningful.
2649 For example, an implementation could have the intelligence to deliver
2650 the value of the "printer-name" attribute to a Notification Recipient
2651 that can access the Printer via value of the "printer-name" attribute
2652 and otherwise deliver the value of the "notify-printer-uri"
2655 Table 9 - Printer Name in Event Notification Content
2657 Source Value Delivers Source Object
2659 printer-name (name(127)) MAY Printer
2660 notify-printer-uri (uri) MAY Subscription
2663 Table 10 lists the source of the information for the Event name. A
2664 Printer MAY combine this information with state information described
2665 for Jobs in Table 13 or for Printers in Table 14.
2667 Table 10 - Event Name in Event Notification Content
2669 Source Value Delivers Source Object
2671 notify-subscribed-event (type2 keyword) MAY Subscription
2673 Table 11 lists the source of the information for the time that the
2674 Event occurred. A Printer can deliver this value only if it supports
2675 the Printer's "printer-current-time" attribute. If a Printer does
2676 not support the "printer-current-time" attribute, it MUST NOT deliver
2677 the "printer-up-time" value instead, since it is not an allowed
2678 option for human consumable information.
2680 Table 11 - Event Time in Event Notification Content
2682 Source Value Delivers Source Object
2684 printer-current-time (dateTime) MAY Printer
2690 Herriot & Hastings Standards Track [Page 48]
2692 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2695 9.2.2. Additional Event Notification Content for Job Events
2697 This section lists the source of the additional information that a
2698 Delivery Method MUST specify for Job Events.
2700 Table 12 lists the source of the information for the job name. The
2701 "job-name" is likely more meaningful to a user than "job-id".
2703 Table 12 - Job Name in Event Notification Content
2705 Source Value Delivers Source Object
2707 job-name (name(MAX)) MAY Job
2708 job-id (integer(1:MAX)) MAY Job
2710 Table 13 lists the source of the information for the job state. If a
2711 Printer supports the "job-state-message" and "job-detailed-state-
2712 message" attributes, it SHOULD use those attributes for the job state
2713 information, otherwise, it should fabricate such information from the
2714 "job-state" and "job-state-reasons". For some Events, a Printer MAY
2715 combine this information with Event information.
2717 Table 13 - Job State in Event Notification Content
2719 Source Value Delivers Source
2722 job-state-message (text(MAX)) MAY Job
2723 job-detailed-status-messages (1setOf text(MAX)) MAY Job
2724 job-state (type1 enum) MAY Job
2725 job-state-reasons (1setOf type2 keyword) MAY Job
2727 9.2.3. Additional Event Notification Content for Printer Events
2729 This section lists the source of the additional information that a
2730 Delivery Method MUST specify for Printer Events.
2732 Table 14 lists the source of the information for the printer state.
2733 If a Printer supports the "printer-state-message", it SHOULD use that
2734 attribute for the job state information, otherwise it SHOULD
2735 fabricate such information from the "printer-state" and "printer-
2736 state-reasons". For some Events, a Printer MAY combine this
2737 information with Event information.
2746 Herriot & Hastings Standards Track [Page 49]
2748 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2751 Table 14 - Printer State in Event Notification Content
2753 Source Value Delivers Source
2756 printer-state-message (text(MAX)) MAY Printer
2757 printer-state (type1 enum) MAY Printer
2758 printer-state-reasons (1setOf type2 keyword) MAY Printer
2759 printer-is-accepting-jobs (boolean) MAY Printer
2761 10. Delivery Methods
2763 A Delivery Method is the mechanism, i.e., protocol, by which the
2764 Printer delivers an Event Notification to a Notification Recipient.
2765 There are several potential Delivery Methods for Event Notifications,
2766 standardized, as well as proprietary. This specification REQUIRES
2767 that the 'ippget' Pull Delivery Method [RFC3996] be supported.
2768 Conforming implementations MAY support additional Push or Pull
2769 Delivery Methods as well. This document does not define any of these
2770 delivery mechanisms. Each Delivery Method MUST be defined in a
2771 Delivery Method Document that is separate from this document. New
2772 Delivery Methods will be created as needed using an extension to the
2773 registration procedures defined in [RFC2911]. Such documents are
2774 registered with IANA (see section 23.7.3).
2776 The following sorts of Delivery Methods are possible:
2778 - The Notification Recipient polls for Event Notifications at
2779 intervals directed by the Printer
2781 - The Printer delivers Event Notifications to the Notification
2782 Recipient using http as the transport.
2784 - The Printer delivers an email message.
2786 This section specifies how to define a Delivery Method Document and
2787 what to put in such a document.
2789 A Delivery Method Document MUST contain an exact copy of the
2790 following paragraph, caption and table. In addition, column 2 of the
2791 table in the Delivery Method Document MUST contain answers to
2792 questions in column 1 for the Delivery Method. Also, the Delivery
2793 Method document MUST contain a reference to this document and call
2794 that reference [RFC3995] because the table contains an [RFC3995]
2797 If a Printer supports this Delivery Method, the following are its
2802 Herriot & Hastings Standards Track [Page 50]
2804 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2807 Table 15 - Information about the Delivery Method
2809 Document Method Conformance Requirement Delivery Method
2812 1. What is the URL scheme name for the Push Delivery Method or the
2813 keyword method name for the Pull Delivery Method?
2815 2. Is the Delivery Method REQUIRED, RECOMMENDED, or OPTIONAL for an
2816 IPP Printer to support?
2818 3. What transport and delivery protocols does the Printer use to
2819 deliver the Event Notification Content, i.e., what is the entire
2822 4. Can several Event Notifications be combined into a Compound Event
2825 5. Is the Delivery Method initiated by the Notification Recipient
2826 (pull), or by the Printer (push)?
2828 6. Is the Event Notification content Machine Consumable or Human
2831 7. What section in this document answers the following question?
2832 For a Machine Consumable Event Notification, what is the
2833 representation and encoding of values defined in section 9.1 of
2834 [RFC3995] and the conformance requirements thereof? For a Human
2835 Consumable Event Notification, what is the representation and
2836 encoding of pieces of information defined in section 9.2 of
2837 [RFC3995] and the conformance requirements thereof?
2839 8. What are the latency and reliability of the transport and
2842 9. What are the security aspects of the transport and delivery
2843 protocol, e.g., how it is handled in firewalls?
2845 10. What are the content length restrictions?
2847 11. What are the additional values or pieces of information that a
2848 Printer delivers in an Event Notification content and the
2849 conformance requirements thereof?
2851 12. What are the additional Subscription Template and/or
2852 Subscription Description attributes and the conformance
2853 requirements thereof?
2858 Herriot & Hastings Standards Track [Page 51]
2860 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2863 13. What are the additional Printer Description attributes and the
2864 conformance requirements thereof?
2866 11. Operations for Notification
2868 This section defines all of the operations for Notification. Section
2869 7.1 assigns the "operation-id" for each operation. The following two
2870 sub-sections define Subscription Creation Operations, and other
2873 11.1. Subscription Creation Operations
2875 This section defines the Subscription Creation Operations. The first
2876 section on Create-Job-Subscriptions gives most of the information.
2877 The other Subscription Creation Operations refer to the section on
2878 Create-Job-Subscriptions, even though the Create-Job-Subscriptions
2879 operation is the only OPTIONAL operation in this document (see
2882 A Printer MUST support Create-Printer-Subscriptions and the
2883 Subscription Template Attributes Group in Job Creation operations.
2884 It MAY support Create-Job-Subscriptions operations.
2886 11.1.1. Create-Job-Subscriptions Operation
2888 The operation creates one or more Per-Job Subscription Objects. The
2889 client supplies one or more Subscription Template Attributes Groups
2890 each containing one or more of Subscription Template Attributes
2891 (defined in section 5.3).
2893 Except for errors, the Printer MUST create exactly one Per-Job
2894 Subscription Object from each Subscription Template Attributes Group
2895 in the request, even if the newly created Subscription Object would
2896 have identical behavior to some existing Subscription Object. The
2897 Printer MUST associate each newly created Per-Job Subscription Object
2898 with the target Job, which is specified by the "notify-job-id"
2899 operation attribute.
2901 The Printer MUST accept the request in any of the target job's 'not-
2902 completed' states, i.e., 'pending', 'pending-held', 'processing', or
2903 'processing-stopped'. The Printer MUST NOT change the job's "job-
2904 state" attribute because of this operation. If the target job is in
2905 any of the 'completed' states, i.e., 'completed', 'canceled', or
2906 'aborted, then the Printer MUST reject the request and return the
2907 'client-error-not-possible' status code; the response MUST NOT
2908 contain any Subscription Attribute Groups.
2914 Herriot & Hastings Standards Track [Page 52]
2916 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2919 Access Rights: To create Per-Job Subscription Objects, the
2920 authenticated user (see [RFC2911] section 8.3) performing this
2921 operation MUST (1) be the job owner, (2) have Operator or
2922 Administrator access rights for this Printer (see [RFC2911] sections
2923 1 and 8.5), or (3) be otherwise authorized by the Printer's
2924 administrator-configured security policy to create Per-Job
2925 Subscription Objects for the target job. Otherwise the Printer MUST
2926 reject the operation and return: the 'client-error-forbidden',
2927 'client-error-not-authenticated', or 'client-error-not-authorized'
2928 status code as appropriate.
2930 11.1.1.1. Create-Job-Subscriptions Request
2932 The following groups of attributes are part of the Create-Job-
2933 Subscriptions Request:
2935 Group 1: Operation Attributes
2937 Natural Language and Character Set:
2938 The "attributes-charset" and "attributes-natural-language"
2939 attributes as described in [RFC2911] section 3.1.4.1.
2942 The "printer-uri" attribute which defines the target for this
2943 operation as described in [RFC2911] section 3.1.5.
2945 Requesting User Name:
2946 The "requesting-user-name" attribute SHOULD be supplied by the
2947 client as described in [RFC2911] section 8.3.
2949 11.1.1.1.1. notify-job-id (integer(1:MAX))
2951 The client MUST supply this attribute and it MUST specify the Job
2952 object to associate the Per-Job Subscription with. The value of
2953 "notify-job-id" MUST be the value of the "job-id" of the associated
2954 Job object. If the client does not supply this attribute, the
2955 Printer MUST reject this request with a 'client-error-bad-request'
2958 Group 2-N: Subscription Template Attributes
2960 For each occurrence of this group:
2962 The client MUST supply one or more Subscription Template
2963 Attributes in any order. See section 5.3 for a description of
2964 each such attribute. See section 5.2 for details on processing
2970 Herriot & Hastings Standards Track [Page 53]
2972 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
2975 11.1.1.2. Create-Job-Subscriptions Response
2977 The Printer MUST return to the client the following sets of
2978 attributes as part of a Create-Job-Subscriptions response:
2980 Group 1: Operation Attributes
2983 In addition to the REQUIRED status code returned in every
2984 response, the response OPTIONALLY includes a "status-message"
2985 (text(255)) and/or a "detailed-status-message" (text(MAX))
2986 operation attribute as described in [RFC2911] sections 13 and
2989 In this group, the Printer can return any status codes defined in
2990 [RFC2911] and section 12. The following is a description of the
2991 important status codes:
2993 successful-ok: the Printer created all Subscription Objects
2994 requested (see [RFC2911]).
2996 successful-ok-ignored-subscriptions: the Printer created some
2997 Subscription Objects requested but some failed. The
2998 Subscription Attributes Groups with a "notify-status-code"
2999 attribute are the ones that failed (see section 12.1).
3001 client-error-ignored-all-subscriptions: the Printer created no
3002 Subscription Objects requested and all failed. The
3003 Subscription Attributes Groups with a "notify-status-code"
3004 attribute are the ones that failed (see section 12.2).
3006 client-error-not-possible: For this operation and other Per-Job
3007 Subscription operations, this error can occur because the
3008 specified Job has already completed (see [RFC2911], whether or
3009 not the Job is retained in the Job Retention and/or Job History
3010 phases (see [RFC2911] section 4.3.7.1).
3012 Natural Language and Character Set:
3013 The "attributes-charset" and "attributes-natural-language"
3014 attributes as described in [RFC2911] section 3.1.4.2.
3016 Group 2: Unsupported Attributes
3018 See [RFC2911] section 3.1.7 for details on returning Unsupported
3019 Attributes. This group does not contain any unsupported
3020 Subscription Template Attributes; they are returned in the
3021 Subscription Attributes Group (see below).
3026 Herriot & Hastings Standards Track [Page 54]
3028 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3031 Group 3-N: Subscription Attributes
3033 These groups MUST be returned unless the Printer is unable to
3034 interpret the entire request, e.g., the "status-code" parameter
3035 returned in Group 1 has the value: 'client-error-bad-request'.
3037 "notify-status-code" (type2 enum):
3038 Indicates the status of this subscription (see section 13 for
3039 the status code definitions). Section 5.2 defines when this
3040 attribute MUST be present in this group.
3042 See section 5.2 for details on the contents of each occurrence of
3045 11.1.2. Create-Printer-Subscriptions operation
3047 The operation is identical to Create-Job-Subscriptions with
3048 exceptions noted in this section.
3050 The operation creates Per-Printer Subscription Objects instead of
3051 Per-Job Subscription Objects, and associates each newly created Per-
3052 Printer Subscription Object with the Printer specified by the
3053 operation target rather than with a specific Job.
3055 The Printer MUST accept the request in any of its states, i.e.,
3056 'idle', 'processing', or 'stopped'. The Printer MUST NOT change its
3057 "printer-state" attribute because of this operation.
3059 Access Rights: To create Per-Printer Subscription Objects, the
3060 authenticated user (see [RFC2911] section 8.3) performing this
3061 operation MUST have (1) Operator or Administrator access rights for
3062 this Printer (see [RFC2911] sections 1 and 8.5), or (2) be otherwise
3063 authorized by the Printer's administrator-configured security policy
3064 to create Per-Printer Subscription Objects for this Printer.
3065 Otherwise, the Printer MUST reject the operation and return: the
3066 'client-error-forbidden', 'client-error-not-authenticated', or
3067 'client-error-not-authorized' status code as appropriate.
3069 11.1.2.1. Create-Printer-Subscriptions Request
3071 The groups are identical to the Create-Job-Subscriptions (see section
3072 11.1.1.1) except that the Operation Attributes group MUST NOT contain
3073 the "notify-job-id" attribute. If the client does supply the
3074 "notify-job-id" attribute, then the Printer MUST treat it as any
3075 other unsupported Operation attribute and MUST return it in the
3076 Unsupported Attributes group.
3082 Herriot & Hastings Standards Track [Page 55]
3084 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3087 11.1.2.2. Create-Printer-Subscriptions Response
3089 The groups are identical to the Create-Job-Subscriptions (see section
3092 11.1.3. Job Creation Operations - Extensions for Notification
3094 This document extends the Job Creation operations (see section 3.2)
3095 to create Subscription Objects as a part of the operation.
3097 The Job Creation operations are identical to Create-Job-Subscriptions
3098 operation with exceptions noted in this section.
3100 Unlike the Create-Job-Subscriptions operation, a Job Creation
3101 operation associates the newly created Subscription Objects with the
3102 Job object created by this operation. The operation succeeds if and
3103 only if the Job creation succeeds. If the Printer does not create
3104 some or all of the requested Subscription Objects, the Printer MUST
3105 return a 'successful-ok-ignored-subscriptions' status-code instead
3106 of a 'successful-ok' status-code, but the Printer MUST NOT reject the
3107 operation because of a failure to create Subscription Objects.
3109 If the Job Creation operation includes a Job Template group, the
3110 client MUST supply it after the Operation Attributes group and before
3111 the first Subscription Template Attributes Group.
3113 If a Printer does not support this Notification specification, then
3114 it MUST treat the Subscription Attributes Group like an unknown group
3115 and ignore it (see [RFC2911] section 5.2.2). Because the Printer
3116 ignores the Subscription Attributes Group, it doesn't return them in
3117 the response either, thus indicating to the client that the Printer
3118 doesn't support Notification.
3120 After completion of a successful Job Creation operation, the Printer
3121 generates a 'job-created' event (see section 5.3.3.4.3).
3123 Access Rights: To create Per-Job Subscription Objects, the
3124 authenticated user (see [RFC2911] section 8.3) performing this
3125 operation MUST either have permission to create Jobs on the Printer
3126 or have Operator or Administrator access rights for this Printer (see
3127 [RFC2911] sections 1 and 8.5). Otherwise the Printer MUST reject the
3128 operation and return: the 'client-error-forbidden', 'client-error-
3129 not-authenticated', or 'client-error-not-authorized' status code as
3138 Herriot & Hastings Standards Track [Page 56]
3140 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3143 11.1.3.1. Job Creation Request
3145 The groups for this operation are sufficiently different from the
3146 Create-Job-Subscriptions operation that they are all presented here.
3147 The following groups of attributes are supplied as part of a Job
3150 Group 1: Operation Attributes
3152 Same as defined in [RFC2911] for Print-Job, Print-URI, and
3153 Create-Job requests.
3155 Group 2: Job Template Attributes
3157 The client OPTIONALLY supplies a set of Job Template attributes as
3158 defined in [RFC2911] section 4.2.
3160 Group 3 to N: Subscription Template Attributes
3162 The same as Group 2-N in Create-Job-Subscriptions. See section
3165 Group N+1: Document Content (Print-Job only)
3167 The client MUST supply the document data to be processed.
3169 11.1.3.2. Job Creation Response
3171 The Printer MUST return to the client the following sets of
3172 attributes as part of a Print-Job, Print-URI, and Create-Job
3175 Group 1: Operation Attributes
3179 As defined in [RFC2911] for Print-Job, Print-URI, and Create-
3182 In this group, the Printer can return any status codes defined
3183 in [RFC2911] and section 12. The following is a description of
3184 the important status codes:
3186 successful-ok: the Printer created the Job and all
3187 Subscription Objects requested (see [RFC2911].
3189 successful-ok-ignored-subscriptions: the Printer created
3190 the Job and not all of the Subscription Objects requested
3194 Herriot & Hastings Standards Track [Page 57]
3196 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3199 (see section 12.1). This status-code hides 'successful-ok-
3200 xxx' status-codes that could reveal problems in Job
3201 creation. The Printer MUST NOT return the 'client-error-
3202 ignored-all-subscriptions' status code for Job Creation
3203 operations because the Printer returns an error status-code
3204 only when it fails to create a Job.
3206 Natural Language and Character Set:
3207 The "attributes-charset" and "attributes-natural-language"
3208 attributes as described in [RFC2911] section 3.1.4.2.
3210 Group 2: Unsupported Attributes
3212 See [RFC2911] section 3.1.7 for details on returning Unsupported
3213 Attributes. This group does not contain any unsupported
3214 Subscription Template Attributes; they are returned in the
3215 Subscription Attributes Group (see below).
3217 Group 3: Job Object Attributes
3219 The "job-id" of the Job Object just created, etc., as defined in
3220 [RFC2911] for Print-Job, Print-URI, and Create-Job requests.
3222 Group 4 to N: Subscription Attributes
3224 These groups MUST be returned if and only if the client supplied
3225 Subscription Template Attributes and the operation was accepted.
3227 See section 5.2 for details on the contents of each occurrence of
3230 11.2. Other Operations
3232 This section defines other operations on Subscription objects.
3234 11.2.1. Restart-Job Operation - Extensions for Notification
3236 The Restart-Job operation [RFC2911] is neither a Job Creation
3237 operation nor a Subscription Creation operation (see section 3.2).
3239 For the Restart-Job operation, the client MUST NOT supply any Job
3240 Subscription Attributes Groups. The Printer MUST treat any supplied
3241 Job Subscription Attributes as unsupported attributes.
3243 For this operation, the Printer does not return a job-id or any
3244 Subscription Attributes groups because the Printer reuses the
3245 existing Job object with the same job-id and the existing Per-Job
3246 Subscription Objects with the same subscription-ids. However, after
3250 Herriot & Hastings Standards Track [Page 58]
3252 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3255 successful completion of this operation, the Printer generates a
3256 'job-created' event (see section 5.3.3.4.3).
3258 11.2.2. Validate-Job Operation - Extensions for Notification
3260 A client can test whether one or more Subscription Objects could be
3261 created using the Validate-Job operation. The client supplies one or
3262 more Subscription Template Attributes Groups (defined in section
3263 5.3), just as in a Job Creation request.
3265 A Printer MUST support this extension to this operation.
3267 The Printer MUST accept requests that are identical to the Job
3268 Creation request defined in section 11.1.3.1, except that the request
3269 MUST NOT contain document data.
3271 The Printer MUST return the same groups and attributes as the Print-
3272 Job operation (section 11.1.3.1) with the following exceptions. The
3273 Printer MUST NOT return a Job Object Attributes Group because no Job
3274 is created. The Printer MUST NOT return the "notify-subscription-id"
3275 attribute in any Subscription Attribute Group because no Subscription
3278 If the Printer would succeed in creating a Subscription Object, the
3279 corresponding Subscription Attributes Group either has no 'status-
3280 code' attribute or a 'status-code' attribute with a value of
3281 'successful-ok-too-many-events' or 'successful-ok-ignored-or-
3282 substituted-attributes' (see sections 5.2 and 13). The status-codes
3283 have the same meaning as in Job Creation except the results state
3284 what "would happen".
3286 The Printer MUST validate Subscription Template Attributes Groups in
3287 the same manner as the Job Creation operations.
3289 11.2.3. Get-Printer-Attributes - Extensions for Notification
3291 This operation is extended so that it returns Printer attributes
3292 defined in this document.
3294 A Printer MUST support this extension to this operation.
3296 In addition to the requirements of [RFC2911] section 3.2.5, a Printer
3297 MUST support the following additional values for the "requested-
3298 attributes" Operation attribute in this operation and return such
3299 attributes in the Printer Object Attributes group of its response.
3301 1. Subscription Template Attributes: Each supported attribute in
3302 column 2 of Table 1.
3306 Herriot & Hastings Standards Track [Page 59]
3308 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3311 2. New Printer Description Attributes: Each supported attribute in
3314 3. New Group Name: The 'subscription-template' group name, which
3315 names all supported Subscription Template Attribute in column 2 of
3316 Table 1. This group name is also used in the Get-Subscription-
3317 Attributes and Get-Subscriptions operation with an analogous
3320 4. Extended Group Name: The 'all' group name, which names all Printer
3321 attributes according to [RFC2911] section 3.2.5. In this
3322 extension 'all' names all attributes specified in [RFC2911] plus
3323 those named in items 1 and 2 of this list.
3325 11.2.4. Get-Subscription-Attributes operation
3327 This operation allows a client to request the values of the
3328 attributes of a Subscription Object.
3330 A Printer MUST support this operation.
3332 This operation is almost identical to the Get-Job-Attributes
3333 operation (see [RFC2911] section 3.3.4). The only differences are
3334 that the operation is directed at a Subscription Object rather than a
3335 Job object, and the returned attribute group contains Subscription
3336 Object attributes rather than Job object attributes.
3338 Access Rights: The authenticated user (see [RFC2911] section 8.3)
3339 performing this operation MUST (1) be the Subscription Object owner,
3340 (2) have Operator or Administrator access rights for this Printer
3341 (see [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
3342 the Printer's administrator-configured security policy to query the
3343 Subscription Object for the target job. Otherwise the Printer MUST
3344 reject the operation and return: the 'client-error-forbidden',
3345 'client-error-not-authenticated', or 'client-error-not-authorized'
3346 status code as appropriate. Furthermore, the Printer's security
3347 policy MAY limit which attributes are returned, in a manner similar
3348 to the Get-Job-Attributes operation (see [RFC2911] end of section
3351 11.2.4.1. Get-Subscription-Attributes Request
3353 The following groups of attributes are part of the Get-Subscription-
3356 Group 1: Operation Attributes
3358 Natural Language and Character Set:
3362 Herriot & Hastings Standards Track [Page 60]
3364 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3367 The "attributes-charset" and "attributes-natural-language"
3368 attributes as described in section [RFC2911] 3.1.4.1.
3371 The "printer-uri" attribute which defines the target for this
3372 operation as described in [RFC2911] section 3.1.5.
3374 Requesting User Name:
3375 The "requesting-user-name" attribute SHOULD be supplied by the
3376 client as described in [RFC2911] section 8.3.
3378 11.2.4.1.1. "notify-subscription-id" (integer (1:MAX))
3380 The client MUST supply this attribute. The Printer MUST support this
3381 attribute. This attribute specifies the Subscription Object from
3382 which the client is requesting attributes. If the client omits this
3383 attribute, the Printer MUST reject this request with the 'client-
3384 error-bad-request' status code.
3386 11.2.4.1.2. "requested-attributes" (1setOf keyword)
3388 The client OPTIONALLY supplies this attribute. The Printer MUST
3389 support this attribute. This attribute specifies the attributes of
3390 the specified Subscription Object that the Printer MUST return in the
3391 response. Each value of this attribute is either an attribute name
3392 (defined in sections 5.3 and 5.4) or an attribute group name. The
3393 attribute group names are:
3395 - 'subscription-template': all attributes that are both defined in
3396 section 5.3 and present on the specified Subscription Object
3397 (column 1 of Table 1).
3399 - 'subscription-description': all attributes that are both defined
3400 in section 5.4 and present on the specified Subscription Object
3403 - 'all': all attributes that are present on the specified
3404 Subscription Object.
3406 A Printer MUST support all these group names.
3408 If the client omits this attribute, the Printer MUST respond as if
3409 this attribute had been supplied with a value of 'all'.
3411 11.2.4.2. Get-Subscription-Attributes Response
3413 The Printer returns the following sets of attributes as part of the
3414 Get-Subscription-Attributes Response:
3418 Herriot & Hastings Standards Track [Page 61]
3420 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3423 Group 1: Operation Attributes
3428 Natural Language and Character Set:
3429 The "attributes-charset" and "attributes-natural-language"
3430 attributes as described in [RFC2911] section 3.1.4.2. The
3431 "attributes-natural-language" MAY be the natural language of the
3432 Subscription Object, rather than the one requested.
3434 Group 2: Unsupported Attributes
3436 See [RFC2911] section 3.1.7 and section 3.2.5.2 for details on
3437 returning Unsupported Attributes.
3439 The response NEED NOT contain the "requested-attributes" operation
3440 attribute with any supplied keyword values that were requested by
3441 the client but are not supported by the IPP object. If the
3442 Printer object does return unsupported attributes referenced in
3443 the "requested-attributes" operation attribute, the values of the
3444 "requested-attributes" attribute returned MUST include only the
3445 unsupported keywords that were requested by the client. If the
3446 client had requested a group name, such as 'all', the resulting
3447 unsupported attributes returned MUST NOT include attribute keyword
3448 names described in the standard but not supported by the
3451 Group 3: Subscription Attributes
3453 This group contains a set of attributes with their current values.
3454 Each attribute returned in this group:
3456 a) MUST be specified by the "requested-attributes" attribute in the
3459 b) MUST be present on the specified Subscription Object AND
3461 c) MUST NOT be restricted by the security policy in force. For
3462 example, a Printer MAY prohibit a client who is not the creator of
3463 a Subscription Object from seeing some or all of its attributes.
3464 See [RFC2911] end of section 3.3.4.2 and section 8.
3466 The Printer can return the attributes of the Subscription Object
3467 in any order. The client MUST accept the attributes in any order.
3474 Herriot & Hastings Standards Track [Page 62]
3476 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3479 11.2.5. Get-Subscriptions operation
3481 This operation allows a client to retrieve the values of attributes
3482 of all Subscription Objects belonging to a Job or Printer.
3484 A Printer MUST supported this operation.
3486 This operation is similar to the Get-Subscription-Attributes
3487 operation, except that this Get-Subscriptions operation returns
3488 attributes from possibly more than one object.
3490 This operation is similar to the Get-Jobs operation (see [RFC2911]
3491 section 3.2.6), except that the operation returns Subscription
3492 Objects rather than Job objects.
3494 Access Rights: To query Per-Job Subscription Objects of the
3495 specified job (client supplied the "notify-job-id" operation
3496 attribute - see section 11.2.5.1.1), the authenticated user (see
3497 [RFC2911] section 8.3) performing this operation MUST (1) be the
3498 Subscription Object owner, (2) have Operator or Administrator access
3499 rights for this Printer (see [RFC2911] sections 1 and 8.5), or (3) be
3500 otherwise authorized by the Printer's administrator-configured
3501 security policy to query the Subscription Object for the target job.
3502 To query Per-Printer Subscription Objects of the Printer (client
3503 omits the "notify-job-id" operation attribute - see section
3504 11.2.5.1.1), the authenticated user (see [RFC2911] section 8.3)
3505 performing this operation MUST (1) have Operator or Administrator
3506 access rights for this Printer (see [RFC2911] sections 1 and 8.5), or
3507 (2) be otherwise authorized by the Printer's administrator-configured
3508 security policy to query Per-Printer Subscription Objects for the
3509 target Printer. Otherwise the Printer MUST reject the operation and
3510 return: the 'client-error-forbidden', 'client-error-not-
3511 authenticated', or 'client-error-not-authorized' status code as
3512 appropriate. Furthermore, the Printer's security policy MAY limit
3513 which attributes are returned, in a manner similar to the Get-Jobs
3514 and Get-Printer-Attributes operations (see [RFC2911] end of sections
3515 3.2.6.2 and 3.2.5.2).
3517 11.2.5.1. Get-Subscriptions Request
3519 The following groups of attributes are part of the Get-Subscriptions
3522 Group 1: Operation Attributes
3524 Natural Language and Character Set:
3525 The "attributes-charset" and "attributes-natural-language"
3526 attributes as described in [RFC2911] section 3.1.4.1.
3530 Herriot & Hastings Standards Track [Page 63]
3532 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3536 The "printer-uri" attribute which defines the target for this
3537 operation as described in [RFC2911] section 3.1.5.
3539 Requesting User Name:
3540 The "requesting-user-name" attribute SHOULD be supplied by the
3541 client as described in [RFC2911] section 8.3.
3543 11.2.5.1.1. "notify-job-id" (integer(1:MAX))
3545 If the client specifies this attribute, the Printer returns the
3546 specified attributes of all Per-Job Subscription Objects associated
3547 with the Job whose "job-id" attribute value equals the value of this
3548 attribute. If the client does not specify this attribute, the
3549 Printer returns the specified attributes of all Per-Printer
3550 Subscription Objects. Note: there is no way to get all Per-Job
3552 Subscriptions known to the Printer in a single operation. A Get-Jobs
3553 operation followed by a Get-Subscriptions operation for each Job will
3554 return all Per-Job Subscriptions.
3556 11.2.5.1.2. "limit" (integer(1:MAX))
3558 The client OPTIONALLY supplies this attribute. The Printer MUST
3559 support this attribute. It is an integer value that determines the
3560 maximum number of Subscription Objects that a client will receive
3561 from the Printer even if the "my-subscriptions" attribute constrains
3562 which Subscription Objects are returned. The limit is a "stateless
3563 limit" in that if the value supplied by the client is 'N', then only
3564 the first 'N' Subscription Objects are returned in the Get-
3565 Subscriptions Response. There is no mechanism to allow for the next
3566 'M' Subscription Objects after the first 'N' Subscription Objects.
3567 If the client does not supply this attribute, the Printer responds
3568 with all applicable Subscription Objects.
3570 11.2.5.1.3. "requested-attributes" (1setOf type2 keyword)
3572 The client OPTIONALLY supplies this attribute. The Printer MUST
3573 support this attribute. This attribute specifies the attributes of
3574 the specified Subscription Objects that the Printer MUST return in
3575 the response. Each value of this attribute is either an attribute
3576 name (defined in sections 5.3 and 5.4) or an attribute group name
3577 (defined in section 11.2.4.1). If the client omits this attribute,
3578 the Printer MUST respond as if the client had supplied this attribute
3579 with the one value: 'notify-subscription-id'.
3586 Herriot & Hastings Standards Track [Page 64]
3588 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3591 11.2.5.1.4. "my-subscriptions" (boolean)
3593 The client OPTIONALLY supplies this attribute. The Printer MUST
3594 support this attribute. If the value is 'false', the Printer MUST
3595 consider the Subscription Objects from all users as candidates. If
3596 the value is 'true', the Printer MUST return the Subscription Objects
3597 created by the requesting user of this request. If the client does
3598 not supply this attribute, the Printer MUST respond as if the client
3599 had supplied the attribute with a value of 'false'. The means for
3600 authenticating the requesting user and matching the Subscription
3601 Objects is similar to that for Jobs which is described in [RFC2911]
3604 11.2.5.2 Get-Subscriptions Response
3606 The Printer returns the following sets of attributes as part of the
3607 Get-Subscriptions Response:
3609 Group 1: Operation Attributes
3614 Natural Language and Character Set:
3615 The "attributes-charset" and "attributes-natural-language"
3616 attributes as described in [RFC2911] section 3.1.4.2.
3618 Group 2: Unsupported Attributes
3620 Same as for Get-Subscription-Attributes.
3622 Groups 3 to N: Subscription Attributes
3624 The Printer responds with one Subscription Attributes Group for
3625 each requested Subscription Object (see the "notify-job-id"
3626 attribute in the Operation Attributes Group of this operation).
3628 The Printer returns Subscription Objects in any order.
3630 If the "limit" attribute is present in the Operation Attributes
3631 group of the request, the number of Subscription Attributes Groups
3632 in the response MUST NOT exceed the value of the "limit"
3635 It there are no Subscription Objects associated with the specified
3636 Job or Printer, the Printer MUST return zero Subscription
3637 Attributes Groups and it MUST NOT treat this case as an error,
3642 Herriot & Hastings Standards Track [Page 65]
3644 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3647 i.e., the status-code MUST be 'successful-ok' unless something
3648 else causes the status code to have some other value.
3650 See the Group 3 response (Subscription Attributes Group) of the
3651 Get-Subscription-Attributes operation (section 11.2.4.2) for the
3652 attributes that a Printer returns in this group.
3654 11.2.6. Renew-Subscription operation
3656 This operation allows a client to request the Printer to extend the
3657 lease on a Per-Printer Subscription Object.
3659 The Printer MUST support this operation.
3661 The Printer MUST accept this request for a Per-Printer Subscription
3662 Object in any of the target Printer's states, i.e., 'idle',
3663 'processing', or 'stopped', but MUST NOT change the Printer's
3664 "printer-state" attribute.
3666 The Printer MUST reject this request for a Per-Job Subscription
3667 Object because it has no lease (see section 5.4.3). The status code
3668 returned MUST be 'client-error-not-possible'.
3670 Access Rights: The authenticated user (see [RFC2911] section 8.3)
3671 performing this operation MUST (1) be the owner of the Per-Printer
3672 Subscription Object, (2) have Operator or Administrator access rights
3673 for the Printer (see [RFC2911] sections 1 and 8.5), or (3) be
3674 otherwise authorized by the Printer's administrator-configured
3675 security policy to renew Per-Printer Subscription Objects for the
3676 target Printer. Otherwise, the Printer MUST reject the operation and
3677 return: the 'client-error-forbidden', 'client-error-not-
3678 authenticated', or 'client-error-not-authorized' status code as
3681 11.2.6.1. Renew-Subscription Request
3683 The following groups of attributes are part of the Renew-Subscription
3686 Group 1: Operation Attributes
3688 Natural Language and Character Set:
3689 The "attributes-charset" and "attributes-natural-language"
3690 attributes as described in [RFC2911] section 3.1.4.1.
3693 The "printer-uri" attribute which defines the target for this
3694 operation as described in [RFC2911] section 3.1.5.
3698 Herriot & Hastings Standards Track [Page 66]
3700 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3703 Requesting User Name:
3704 The "requesting-user-name" (name(MAX)) attribute SHOULD be
3705 supplied by the client as described in [RFC2911] section 8.3.
3707 11.2.6.1.1. "notify-subscription-id" (integer (1:MAX))
3709 The client MUST supply this attribute. The Printer MUST support this
3710 attribute. This attribute specifies the Per-Printer Subscription
3711 Object whose lease the Printer MUST renew. If the client omits this
3712 attribute, the Printer MUST reject this request with the 'client-
3713 error-bad-request' status code.
3715 Group 2: Subscription Template Attributes
3717 11.2.6.1.2. "notify-lease-duration" (integer(0:MAX))
3719 The client MAY supply this attribute. It indicates the number of
3720 seconds to renew the lease for the specified Subscription Object. A
3721 value of 0 requests an infinite lease (which MAY require Operator
3722 access rights). If the client omits this attribute, the Printer MUST
3723 use the value of the Printer's "notify-lease-duration-default"
3724 attribute. See section 5.3.8 for more details.
3726 11.2.6.2. Renew-Subscription Response
3728 The Printer returns the following sets of attributes as part of the
3729 Renew-Subscription Response:
3731 Group 1: Operation Attributes
3736 The following are some of the status codes returned (see
3739 successful-ok: The operation successfully renewed the lease
3740 on the Subscription Object for the requested duration.
3742 successful-ok-ignored-or-substituted-attributes: The
3743 operation successfully renewed the lease on the Subscription
3744 Object for some duration other than the amount requested.
3746 client-error-not-possible: The operation failed because the
3747 "notify-subscription-id" Operation attribute identified a
3748 Per-Job Subscription Object.
3754 Herriot & Hastings Standards Track [Page 67]
3756 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3759 client-error-not-found: The operation failed because the
3760 "notify-subscription-id" Operation attribute identified a
3761 non-existent Subscription Object.
3763 Natural Language and Character Set:
3764 The "attributes-charset" and "attributes-natural-language"
3765 attributes as described in [RFC2911] section 3.1.4.2. The
3766 "attributes-natural-language" MAY be the natural language of the
3767 Subscription Object, rather than the one requested.
3769 Group 2: Unsupported Attributes
3771 See [RFC2911] section 3.1.7 for details on returning Unsupported
3774 Group 3: Subscription Attributes
3776 The Printer MUST return the following Subscription Attribute:
3778 11.2.6.2.1. "notify-lease-duration" (integer(0:MAX))
3780 The value of this attribute MUST be the number of seconds that the
3781 Printer has granted for the lease of the Subscription Object (see
3782 section 5.3.8 for details, such as the value of this attribute when
3783 the Printer doesn't support the requested value).
3785 11.2.7. Cancel-Subscription operation
3787 This operation allows a client to delete a Subscription Object and
3788 stop the Printer from delivering more Event Notifications. Once
3789 performed, there is no way to reference the Subscription Object.
3791 A Printer MUST supported this operation.
3793 The Printer MUST accept this request in any of the target Printer's
3794 states, i.e., 'idle', 'processing', or 'stopped', but MUST NOT change
3795 the Printer's "printer-state" attribute.
3797 If the specified Subscription Object is a Per-Job Subscription
3798 Object, the Printer MUST accept this request in any of the target
3799 Job's states, but MUST NOT change the Job's "job-state" attribute or
3802 Note: There is no way to change any attributes on a Subscription
3803 Object, except the "notify-lease-duration" attribute (using the
3804 Renew-Subscription operation). In order to change other attributes,
3805 a client performs a Subscription Creation Operation and Cancel-
3806 Subscription operation on the old Subscription Object. If the client
3810 Herriot & Hastings Standards Track [Page 68]
3812 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3815 wants to avoid missing Event Notifications, it performs the
3816 Subscription Creation Operation first. If this order would create
3817 too many Subscription Objects on the Printer, the client reverses the
3820 Access Rights: The authenticated user (see [RFC2911] section 8.3)
3821 performing this operation MUST (1) be the owner of the Subscription
3822 Object, (2) have Operator or Administrator access rights for the
3823 Printer (see [RFC2911] sections 1 and 8.5), or (3) be otherwise
3824 authorized by the Printer's administrator-configured security policy
3825 to cancel the target Subscription Object. Otherwise, the Printer
3826 MUST reject the operation and return: the 'client-error-forbidden',
3827 'client-error-not-authenticated', or 'client-error-not-authorized'
3828 status code as appropriate.
3830 11.2.7.1. Cancel-Subscription Request
3832 The following groups of attributes are part of the Cancel-
3833 Subscription Request:
3835 Group 1: Operation Attributes
3837 Natural Language and Character Set:
3838 The "attributes-charset" and "attributes-natural-language"
3839 attributes as described in [RFC2911] section 3.1.4.1.
3842 The "printer-uri" attribute which defines the target for this
3843 operation as described in [RFC2911] section 3.1.5.
3845 Requesting User Name:
3846 The "requesting-user-name" attribute SHOULD be supplied by the
3847 client as described in [RFC2911] section 8.3.
3849 11.2.7.1.1. "notify-subscription-id" (integer (1:MAX))
3851 The client MUST supply this attribute. The Printer MUST support this
3852 attribute. This attribute specifies the Subscription Object that the
3853 Printer MUST cancel. If the client omits this attribute, the Printer
3854 MUST reject this request with the 'client-error-bad-request' status
3866 Herriot & Hastings Standards Track [Page 69]
3868 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3871 11.2.7.2. Cancel-Subscription Response
3873 The Printer returns the following sets of attributes as part of the
3874 Cancel-Subscription Response:
3876 Group 1: Operation Attributes
3881 The following are some of the status codes returned (see
3884 successful-ok: The operation successfully canceled
3885 (deleted) the Subscription Object.
3887 client-error-not-found: The operation failed because the
3888 "notify-subscription-id" Operation attribute identified a
3889 non-existent Subscription Object.
3891 Natural Language and Character Set:
3892 The "attributes-charset" and "attributes-natural-language"
3893 attributes as described in [RFC2911] section 3.1.4.2. The
3894 "attributes-natural-language" MAY be the natural language of the
3895 Subscription Object, rather than the one requested.
3897 Group 2: Unsupported Attributes
3899 See [RFC2911] section 3.1.7 for details on returning Unsupported
3904 The following status codes are defined as extensions for Notification
3905 and are returned as the value of the "status-code" parameter in the
3906 Operation Attributes Group of a response (see [RFC2911] section
3907 3.1.6.1). Operations in this document can also return the status
3908 codes defined in section 13 of [RFC2911]. The 'successful-ok' status
3909 code is an example of such a status code.
3911 12.1. successful-ok-ignored-subscriptions (0x0003)
3913 The Subscription Creation Operation was unable to create all
3914 requested Subscription Objects.
3916 For a Create-Job-Subscriptions or Create-Printer-Subscriptions
3917 operation, this status code means that the Printer created one or
3922 Herriot & Hastings Standards Track [Page 70]
3924 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3927 more Subscription Objects, but not all requested Subscription
3930 For a Job Creation operation, this status code means that the Printer
3931 created the Job along with zero or more Subscription Objects. The
3932 Printer returns this status code even if other job attributes are
3933 unsupported or in conflict. That is, if an IPP Printer finds a
3934 warning that would allow it to return 'successful-ok-ignored-
3935 subscriptions' and either 'successful-ok-ignored-or-substituted-
3936 attributes' and/or 'successful-ok-conflicting-attributes', it MUST
3937 return 'successful-ok-ignored-subscriptions'.
3939 12.2. client-error-ignored-all-subscriptions (0x0414)
3941 This status code is the same as 'successful-ok-ignored-subscriptions'
3942 except that only the Create-Job-Subscriptions and Create-Printer-
3943 Subscriptions operation return it. They return this status code only
3944 when the Printer creates zero Subscription Objects.
3946 13. Status Codes in Subscription Attributes Groups
3948 This section contains values of the "notify-status-code" (type2 enum)
3949 attribute that the Printer returns in a Subscription Attributes Group
3950 in a response when the corresponding Subscription Object:
3952 1. is not created or
3954 2. is created and some of the client-supplied attributes are not
3957 The following sections are ordered in decreasing order of importance
3958 of the status-codes.
3960 13.1. client-error-uri-scheme-not-supported (0x040C)
3962 This status code is defined in [RFC2911]. This document extends its
3963 meaning and allows it to be in a Subscription Attributes Group of a
3966 The scheme of the client-supplied URI in a "notify-recipient-uri"
3967 Subscription Template Attribute in a Subscription Creation Operation
3968 is not supported. See section 5.3.1.
3970 13.2. client-error-attributes-or-values-not-supported (0x040B)
3972 This status code is defined in [RFC2911]. This document extends its
3973 meaning and allows it to be in a Subscription Attributes Group of a
3978 Herriot & Hastings Standards Track [Page 71]
3980 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
3983 The method of the client-supplied keyword in a "notify-pull-method"
3984 Subscription Template Attribute in a Subscription Creation Operation
3985 is not supported. See section 5.3.2.
3987 13.3. client-error-too-many-subscriptions (0x0415)
3989 The number of Subscription Objects supported by the Printer would be
3990 exceeded if this Subscription Object were created (see section 5.2).
3992 13.4. successful-ok-too-many-events (0x0005)
3994 The client supplied more Events in the "notify-events" operation
3995 attribute of a Subscription Creation Operation than the Printer
3996 supports, as indicated in its "notify-max-events-supported" Printer
3997 attribute (see section 5.3.3).
3999 13.5. successful-ok-ignored-or-substituted-attributes (0x0001)
4001 This status code is defined in [RFC2911]. This document extends its
4002 meaning to include unsupported Subscription Template Attributes and
4003 it can appear in a Subscription Attributes Group.
4005 14. Encodings of Additional Attribute Tags
4007 This section assigns values to two attributes tags as extensions to
4008 the encoding defined in [RFC2910]).
4010 The "subscription-attributes-tag" delimits Subscription Template
4011 Attributes Groups in requests and Subscription Attributes Groups in
4014 The "event-notification-attributes-tag" delimits Event Notifications
4015 in Delivery Methods that use an IPP-like encoding.
4017 The following table specifies the values for the delimiter tags:
4019 Tag Value (Hex) Meaning
4021 0x06 "subscription-attributes-tag"
4022 0x07 "event-notification-attributes-tag"
4024 15. Conformance Requirements
4026 It is OPTIONAL for IPP clients and Printers to implement this Event
4027 Notification specification.
4034 Herriot & Hastings Standards Track [Page 72]
4036 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4039 15.1. Conformance requirements for clients
4041 If this Event Notification specification is implemented by a client,
4042 the client MUST support the 'ippget' Pull Delivery Method and meet
4043 the conformance requirements as defined in [RFC3996] for clients. A
4044 client MAY support additional Delivery Methods.
4046 15.2. Conformance requirements for Printers
4048 If this Event Notification specification is implemented by a Printer,
4051 - meet the Conformance Requirements detailed in section 5 of
4054 - support the Subscription Template Attributes Group in requests and
4055 the Subscription Attributes Group in responses.
4057 - support all of the following attributes:
4059 a. REQUIRED Subscription Object attributes in section 5.
4060 b. REQUIRED Printer Description object attributes in section 6.
4061 c. REQUIRED attributes in Event Notification content in section 8.
4063 - support the 'ippget' Pull Delivery Method and meet the conformance
4064 requirements as defined in [RFC3996] for Printers. The Printer
4065 MAY support additional Push and Pull Delivery Methods.
4067 - deliver Event Notifications that conform to the requirements of
4068 section 9 and the requirements of the Delivery Method Document for
4069 each supported Delivery Method (the conformance requirements for
4070 Delivery Method Documents is specified in section 10).
4072 - for all of the Job Creation Operations that the Printer supports,
4073 MUST support the REQUIRED extensions for notification defined in
4076 - meet the conformance requirements for operations as described in
4077 Table 16 and meet the requirements for Printers as specified in
4078 the indicated sub-sections of section 11:
4090 Herriot & Hastings Standards Track [Page 73]
4092 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4095 Table 16 - Printer Conformance Requirements for Operations
4101 Create-Printer-Subscriptions (section 11.1.2) REQUIRED
4102 Create-Job-Subscriptions (section 11.1.1) OPTIONAL
4103 Get-Subscription-Attributes (section 11.2.3) REQUIRED
4104 Get-Subscriptions (section 11.2.5) REQUIRED
4105 Renew-Subscription (section 11.2.6) REQUIRED
4106 Cancel-Subscription (section 11.2.7) REQUIRED
4108 16. Model for Notification with Cascading Printers (Informative)
4110 With this model (see Figure 2 below), there is an intervening Print
4111 server between the human user and the output-device. So the system
4112 effectively has two Printer objects. There are two cases to
4115 1. When the Printer 1 (in the server) generates Events, the system
4116 behaves like the client and Printer in Figure 1. In this case,
4117 Printer 1 delivers Event Notifications that are shown as Event
4118 Notifications (A) of Figure 2.
4120 2. When the Printer 2 (in the output-device) generates Events, there
4121 are two possible system configurations:
4123 a) Printer 1 forwards the client-supplied Subscription Creation
4124 Operations to the downstream Printer 2 and lets Printer 2
4125 deliver the Event Notifications directly to the Notification
4126 Recipients supplied by the Client (Event Notifications(C) in
4129 b) Printer 1 performs the client-supplied Subscription Creation
4130 Operations and also forwards the Subscription Creation
4131 Operations to Printer 2 with the Notification Recipient changed
4132 to be the Printer 1. When an Event occurs in Printer 2,
4133 Printer 2 delivers the Event Notification (B) to Notification
4134 Recipient of Printer 1, which relays the received Event
4135 Notification (B) to the client-supplied Notification Recipient
4136 (as Event Notifications(A) in the diagram). Note, when a
4137 client performs a Subscription Creation Operation, Printer 1
4138 need not forward the Subscription Creation Operation to Printer
4139 2 if it would create a duplicate Subscription Object on Printer
4146 Herriot & Hastings Standards Track [Page 74]
4148 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4151 Note: when Printer 1 is forwarding Subscription Creation Operations
4152 to Printer 2, it may request Printer 2 to create additional
4153 Subscription Objects (called "piggy-backing"). Piggy-backing is
4156 - Device A is configured to accept (IPP or non-IPP) requests from
4159 - Server S wants to receive Job Events that the client didn't
4160 request and Server S wants these Events for jobs it submits and
4164 +------------+ +------------+
4166 +--------+ Subscription | ###########| | ###########|
4167 | client |--Creation ----># Printer #| Subscription | # Printer #|
4168 +--------+ Operation | # Object 1#|---Creation------|># Object 2#|
4169 | ###|#######| Operation | ####|#|####|
4170 +----|---^---+ +-----|-|----+
4171 +--------+ Event | | | |
4172 |Notific-|<-Notifications(A)-+ +-- Event Notifications(B)--+ |
4173 |ation Re|<-------------Event Notifications(C)-----------------+
4177 Figure 2 - Model for Notification with Cascading Printers
4179 17. Distributed Model for Notification (Informative)
4181 A Printer implementation could use some other remote notification
4182 server to provide some or most of the service. For example, the
4183 remote notification server could deliver Event Notifications using
4184 Delivery Methods that are not directly supported by the output device
4185 or Printer object. Or, the remote notification server could store
4186 Subscription Objects (passed to it from the output device in response
4187 to Subscription Creation requests), accept Events, format the Event
4188 Notification in the natural language of the Notification Recipient,
4189 and deliver the Event Notifications to the Notification Recipient(s).
4191 Figure 3 shows this partitioning. The interface between the output
4192 device (or Printer object) and the remote notification server is
4193 outside the scope of this document and is intended to be transparent
4194 to the client and this document.
4202 Herriot & Hastings Standards Track [Page 75]
4204 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4207 ***********************
4209 * Printer in combination
4210 * with the distributed
4211 * Notification Server)
4213 * output device or server
4215 PDA, desktop, or server * + ########### +
4216 +--------+ * | # # |
4217 | client |---IPP Subscription--------># Printer # |
4218 +--------+ Creation operation * | # Object # |
4223 +------------+ * | Notifications
4224 |Notification| IPP-defined * +------v--------+
4225 |Recipient |<--Event Notifications---| Notification |
4226 +------------+ * | Server |
4229 *************************
4230 *** = Implementation configuration opaque boundary
4232 Figure 3 - Opaque Use of a Notification Server Transparent to the
4235 18. Extended Notification Recipient (Informative)
4237 The model allows for an extended Notification Recipient that is
4238 itself a notification server that forwards each Event Notification to
4239 another recipient (called the Ultimate Notification Recipient in this
4240 section). The Delivery Method to the Ultimate Recipient is probably
4241 different from the Delivery Method used by the Printer to the
4242 extended Notification Recipient.
4244 This extended Notification Recipient is transparent to the Printer
4245 but not to the client.
4247 When a client performs a Subscription Creation Operation, it
4248 specifies the extended Notification Recipient as it would any
4249 Notification Recipient. In addition, the client specifies the
4250 Ultimate Notification Recipient in the Subscription Creation
4251 Operation in a manner specified by the extended Notification
4252 Recipient. Typically, it is either some bytes in the value of
4253 "notify-user-data" or some additional parameter in the value of
4254 "notify-recipient-uri". The client also subscribes directly with the
4258 Herriot & Hastings Standards Track [Page 76]
4260 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4263 extended Notification Recipient (by means outside this document),
4264 since it is a notification server in its own right.
4266 The IPP Printer treats the extended Notification Recipient like any
4267 other Notification Recipient and the IPP Printer is not aware of the
4268 forwarding. The Delivery Method that the extended Notification
4269 Recipient uses for delivering the Event Notification to the Ultimate
4270 Notification Recipient is beyond the scope of this document and is
4271 transparent to the IPP Printer.
4273 Examples of this extended Notification Recipient are paging,
4274 immediate messaging services, general notification services, and NOS
4275 vendors' infrastructure. Figure 4 shows this approach.
4277 PDA, desktop, or server server or output device
4279 +--------+ | ########### |
4280 | client |---Subscription Creation -----------># Printer # |
4281 +--------+ Operation | # Object # |
4283 +------------+ +------------+ IPP-defined +-------|-------+
4284 |Ultimate | any |Notification|<--Event Notifications----+
4285 |Notification|<----|Recipient |
4286 |Recipient | +------------+
4287 +------------+ (Notification Server)
4289 Figure 4 - Use of an Extended Notification Recipient transparent to
4292 19. Object Model for Notification (Normative)
4294 This section describes the Notification object model that adds a
4295 Subscription Object which together with the Job and Printer object
4296 provide the complete Notification semantics.
4314 Herriot & Hastings Standards Track [Page 77]
4316 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4319 The object relationships can be seen pictorially as:
4321 Subscription Objects (Per-Printer Subscriptions) Printer object
4322 +----+ +------------+
4323 | s1 |<--------------------------------------------->| |
4325 | s2 |<-------------------------------------------->| p1 |
4327 | s3 |<------------------------------------------->| |
4328 +----+ +------------+
4335 | | s4 is a Per-Job Subscription Object
4341 | s6 |<----->| | s5 and s6 are Per-Job Subscription
4342 +----+ ++--------++ Objects
4346 | | <----> indicates association
4349 Figure 5 - Object Model for Notification
4351 s1, s2, and s3 are Per-Printer Subscription Objects and can identify
4352 Printer and/or Job Events.
4354 s4, s5, and s6 are Per-Job Subscription Objects and can identify
4355 Printer and/or Job Events.
4357 19.1. Object relationships
4359 This sub-section defines the object relationships between the
4360 Printer, Job, and Subscription Objects by example. Whether Per-
4361 Printer Subscription Objects are actually contained in a Printer
4362 object or are just bi-directionally associated with them in some way
4363 is IMPLEMENTATION DEPENDENT and is transparent to the client.
4364 Similarly, whether Per-Job Subscription Objects are actually
4370 Herriot & Hastings Standards Track [Page 78]
4372 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4375 contained in a Job object or are just bi-directionally associated
4376 with them in some way is IMPLEMENTATION DEPENDENT and is transparent
4377 to the client. The object relationships are defined as follows:
4379 19.2. Printer Object and Per-Printer Subscription Objects
4381 1. The Printer object contains (is associated with) zero or more
4382 Per-Printer Subscription Objects (p1 contains s1-s3 Per-Printer
4383 Subscription Objects).
4385 2. Each Per-Printer Subscription Object (s1, s2, and s3) is contained
4386 in (or is associated with) exactly one Printer object (p1).
4388 19.3. Job Object and Per-Job Subscription Objects
4390 1. A Job object (j1, j2, j3) is associated with zero or more Per-Job
4391 Subscription Objects (s4-s6). Job j1 is associated with Per-Job
4392 Subscription Object s4, Job j2 is associated with Per-Job
4393 Subscription Objects s5 and s6, and Job j3 is not associated with
4394 any Per-Job Subscription Object.
4396 2. Each Per-Job Subscription Object is associated with exactly one
4399 20. Per-Job versus Per-Printer Subscription Objects (Normative)
4401 Per-Job and Per-Printer Subscription Objects are quite similar.
4402 Either type of Subscription Object can subscribe to Job Events,
4403 Printer Events, or both. Both types of Subscription Objects can be
4404 queried using the Get-Subscriptions and Get-Subscription-Attributes
4405 operations and canceled using the Cancel-Subscription operation.
4406 Both types of Subscription Objects create Subscription Objects which
4407 have the same Subscription Object attributes defined. However, there
4408 are some semantic differences between Per-Job Subscription Objects
4409 and Per-Printer Subscription Objects. A Per-Job Subscription Object
4410 is established by the client when submitting a job and after creating
4411 the job using the Create-Job-Subscriptions operation by specifying
4412 the "job-id" of the Job with the "notify-job-id" attribute. A Per-
4413 Printer Subscription Object is established between a client and a
4414 Printer using the Create-Printer-Subscriptions operation. Some
4415 specific differences are:
4417 1. A client usually creates one or more Per-Job Subscription Objects
4418 as part of the Job Creation operations (Create-Job, Print-Job, and
4419 Print-URI), rather than using the OPTIONAL Create-Job-
4420 Subscriptions operation, especially since Printer implementations
4421 NEED NOT support the Create-Job-Subscriptions operation, since it
4426 Herriot & Hastings Standards Track [Page 79]
4428 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4431 2. For Per-Job Subscription Objects, the Subscription Object is only
4432 valid while the job is "not-complete" (see sections 5.4.3) while
4433 for the Per-Printer Subscription Objects, the Subscription Object
4434 is valid until the time (in seconds) that the Printer returned in
4435 the "notify-lease-expiration-time" operation attribute.
4437 3. Job Events in a Per-Job Subscription Object apply only to "one
4438 job" (the Job created by the Job Creation operation or references
4439 by the Create-Job-Subscriptions operation) while Job Events in a
4440 Per-Printer Subscription Object apply to ALL jobs contained in the
4443 21. Normative References
4445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4446 Requirement Levels", BCP 14, RFC 2119 , March 1997.
4448 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter,
4449 "Uniform Resource Identifiers (URI): Generic
4450 Syntax", RFC 2396, August 1998.
4452 [RFC2717] Petke, R. and I. King, "Registration Procedures for
4453 URL Scheme Names", RFC 2717, November 1999.
4455 [RFC2910] Herriot, R., Butler, S., Moore, P., and R. Turner,
4456 "Internet Printing Protocol/1.1: Encoding and
4457 Transport", RFC 2910, September 2000.
4459 [RFC2911] deBry, R., Hastings, T., Herriot, R., Isaacson, S.,
4460 and P. Powell, "Internet Printing Protocol/1.1:
4461 Model and Semantics", RFC 2911, September 2000.
4463 [RFC3381] Hastings, T., Lewis, H., and R. Bergman, "IPP: Job
4464 Progress Attributes", RFC 3381, September 2002.
4466 [RFC3996] Herriot, R., Hastings, T., and H. Lewis, "Internet
4467 Printing Protocol (IPP): The 'ippget' Delivery
4468 Method for Event Notifications", RFC 3996, March
4471 22. Informative References
4473 [IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for
4474 Writing an IANA Considerations Section in RFCs",
4475 BCP 26, RFC 2434, October 1998.
4482 Herriot & Hastings Standards Track [Page 80]
4484 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4487 [RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner,
4488 "Internet Printing Protocol/1.0: Encoding and
4489 Transport", RFC 2565, April 1999.
4491 [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S.,
4492 and P. Powell, "Internet Printing Protocol/1.0:
4493 Model and Semantics", RFC 2566, April 1999.
4495 [RFC2567] Wright, D., "Design Goals for an Internet Printing
4496 Protocol", RFC 2567, April 1999.
4498 [RFC2568] Zilles, S., "Rationale for the Structure and Model
4499 and Protocol for the Internet Printing Protocol",
4500 RFC 2568, April 1999.
4502 [RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J.
4503 Martin, "Mapping between LPD and IPP Protocols",
4504 RFC 2569, April 1999.
4506 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
4507 Masinter, L., Leach, P., and T. Berners-Lee,
4508 "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
4511 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C.,
4512 and H. Holst, "Internet Printing Protocol/1.1:
4513 Implementer's Guide", RFC 3196, November 2001.
4515 [RFC3997] Hastings, T., Editor, deBry, R., and H. Lewis,
4516 "Internet Printing Protocol (IPP): Requirements for
4517 IPP Notifications", RFC 3997, March 2005.
4519 23. IANA Considerations
4521 This section contains the registration information that IANA added to
4522 the IPP Registry according to the procedures defined in RFC 2911
4523 [RFC2911] section 6 to cover the definitions in this document. In
4524 addition, this section defines how Events and Delivery Methods will
4525 be registered when they are defined in other documents. The
4526 resulting registrations have been published in the
4527 http://www.iana.org/assignments/ipp-registrations registry.
4538 Herriot & Hastings Standards Track [Page 81]
4540 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4543 23.1. Attribute Registrations
4545 The following table lists all the attributes defined in this
4546 document. These have been registered according to the procedures in
4547 RFC 2911 [RFC2911] section 6.2.
4549 Subscription Template attributes: Reference Section
4550 --------------------------------- --------- -------
4551 notify-attributes (1setOf type2 keyword) [RFC3995] 5.3.4
4552 notify-attributes-supported (1setOf type2 keyword)
4554 notify-charset (charset) [RFC3995] 5.3.6
4555 notify-events (1setOf type2 keyword) [RFC3995] 5.3.3
4556 notify-events-default (1setOf type2 keyword) [RFC3995] 5.3.3.1
4557 notify-events-supported (1setOf type2 keyword) [RFC3995] 5.3.3.2
4558 notify-lease-duration (integer(0:67108863)) [RFC3995] 5.3.8
4559 notify-lease-duration-default (integer(0:67108863))
4561 notify-lease-duration-supported (1setOf (integer(0: 67108863) |
4562 rangeOfInteger(0:67108863))) [RFC3995] 5.3.8.2
4563 notify-max-events-supported (integer(2:MAX)) [RFC3995] 5.3.3.3
4564 notify-natural-language (naturalLanguage) [RFC3995] 5.3.7
4565 notify-pull-method (type2 keyword) [RFC3995] 5.3.2
4566 notify-pull-method-supported (1setOf type2 keyword)
4568 notify-recipient-uri (uri) [RFC3995] 5.3.1
4569 notify-schemes-supported (1setOf uriScheme) [RFC3995] 5.3.1.1
4570 notify-time-interval (integer(0:MAX)) [RFC3995] 5.3.9
4571 notify-user-data (octetString(63)) [RFC3995] 5.3.5
4573 Subscription Description Attributes:
4574 notify-job-id (integer(1:MAX)) [RFC3995] 5.4.6
4575 notify-lease-expiration-time (integer(0:MAX)) [RFC3995] 5.4.3
4576 notify-printer-up-time (integer(1:MAX)) [RFC3995] 5.4.4
4577 notify-printer-uri (uri) [RFC3995] 5.4.5
4578 notify-sequence-number (integer (0:MAX)) [RFC3995] 5.4.2
4579 notify-subscriber-user-name (name(MAX)) [RFC3995] 5.4.7
4580 notify-subscription-id (integer (1:MAX)) [RFC3995] 5.4.1
4582 Printer Description Attributes:
4583 printer-state-change-date-time (dateTime) [RFC3995] 6.2
4584 printer-state-change-time (integer(1:MAX)) [RFC3995] 6.1
4586 Attributes Only in Event Notifications
4587 notify-subscribed-event (type2 keyword) [RFC3995] 8.1
4588 notify-text (text(MAX)) [RFC3995] 8.2
4594 Herriot & Hastings Standards Track [Page 82]
4596 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4599 23.2. Additional Enum Attribute Value Registrations within the IPP
4602 The following table lists all the new enum attribute values defined
4603 in this document. These have been registered within the IPP registry
4604 according to the procedures in RFC 2911 [RFC2911] section 6.1.
4607 Value Name Reference Section
4608 ------ ----------------------------- --------- -------
4609 operations-supported (1setOf type2 enum) [RFC2911] 4.4.15
4610 0x0016 Create-Printer-Subscriptions [RFC3995] 7.1
4611 0x0017 Create-Job-Subscriptions [RFC3995] 7.1
4612 0x0018 Get-Subscription-Attributes [RFC3995] 7.1
4613 0x0019 Get-Subscriptions [RFC3995] 7.1
4614 0x001A Renew-Subscription [RFC3995] 7.1
4615 0x001B Cancel-Subscription [RFC3995] 7.1
4617 23.3. Operation Registrations
4619 The following table lists all of the operations defined in this
4620 document. These have been registered according to the procedures in
4621 RFC 2911 [RFC2911] section 6.4.
4623 Operation Name Reference Section
4624 --------------------------------- --------- -------
4625 Cancel-Subscription [RFC3995] 11.2.7
4626 Create-Job - Extensions [RFC3995] 11.1.3
4627 Create-Job-Subscriptions [RFC3995] 11.1.1
4628 Create-Printer-Subscriptions [RFC3995] 11.1.2
4629 Get-Printer-Attributes - Extensions [RFC3995] 11.2.3
4630 Get-Subscription-Attributes [RFC3995] 11.2.4
4631 Get-Subscriptions [RFC3995] 11.2.5
4632 Print-Job - Extensions [RFC3995] 11.1.3
4633 Print-URI - Extensions [RFC3995] 11.1.3
4634 Renew-Subscription [RFC3995] 11.2.6
4635 Validate-Job Operation - Extensions [RFC3995] 11.2.2
4637 23.4. Status code Registrations
4639 The following table lists all the status codes defined in this
4640 document. These have been registered according to the procedures in
4641 RFC 2911 [RFC2911] section 6.6.
4650 Herriot & Hastings Standards Track [Page 83]
4652 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4655 Value Status Code Name Reference Section
4656 ----- ---------------------------- --------- -------
4657 0x0000:0x00FF - Successful:
4658 0x0003 successful-ok-ignored-subscriptions [RFC3995] 12.1
4659 0x0005 successful-ok-too-many-events [RFC3995] 13.4
4661 0x0400:0x04FF - Client Error:
4662 0x0414 client-error-ignored-all-subscriptions [RFC3995] 12.2
4663 0x0415 client-error-too-many-subscriptions [RFC3995] 13.3
4665 23.5. Attribute Group tag Registrations
4667 The following table lists all the attribute group tags defined in
4668 this document. These have been registered according to the
4669 procedures in RFC 2911 [RFC2911] section 6.5.
4671 Value Attribute Group Tag Name Reference Section
4672 ----- -------------------------------- -------- -------
4673 0x06 subscription-attributes-tag [RFC3995] 14
4674 0x07 event-notification-attributes-tag [RFC3995] 14
4676 23.6. Registration of Events
4678 The following table lists all the Events defined in this document as
4679 type2 keywords to be used with the "notify-events", "notify-events-
4680 default", and "notify-events-supported" Subscription Template
4681 attributes (see section 5.3.3)). Rather than creating a separate
4682 section in the IPP Registry for Events, these event keywords have
4683 been registered according to the procedures of [RFC2911] section 7.1
4684 as additional keyword attribute values for use with the "notify-
4685 events" Subscription Template attribute (see section 5.3.3), i.e.,
4686 registered as keyword values for the "notify-events", "notify-
4687 events-default", and "notify-events-supported" attributes:
4689 Attribute (attribute syntax)
4690 Value Reference Section
4691 --------------------- --------- -------
4692 notify-events (1setOf type2 keyword) [RFC3995] 5.3.3
4693 notify-events-default (1setOf type2 keyword) [RFC3995] 5.3.3.1
4694 notify-events-supported (1setOf type2 keyword) [RFC3995] 5.3.3.2
4695 notify-subscribed-event (type2 keyword) [RFC3995] 8.1
4697 none [RFC3995] 5.3.3.4.1
4699 printer-state-changed [RFC3995] 5.3.3.4.2
4700 printer-restarted [RFC3995] 5.3.3.4.2
4701 printer-shutdown [RFC3995] 5.3.3.4.2
4702 printer-stopped [RFC3995] 5.3.3.4.2
4706 Herriot & Hastings Standards Track [Page 84]
4708 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4711 printer-config-changed [RFC3995] 5.3.3.4.2
4712 printer-media-changed [RFC3995] 5.3.3.4.2
4713 printer-finishings-changed [RFC3995] 5.3.3.4.2
4714 printer-queue-order-changed [RFC3995] 5.3.3.4.2
4716 job-state-changed [RFC3995] 5.3.3.4.3
4717 job-created [RFC3995] 5.3.3.4.3
4718 job-completed [RFC3995] 5.3.3.4.3
4719 job-stopped [RFC3995] 5.3.3.4.3
4720 job-config-changed [RFC3995] 5.3.3.4.3
4721 job-progress [RFC3995] 5.3.3.4.3
4723 23.7. Registration of Event Notification Delivery Methods
4725 This section describes the requirements and procedures for
4726 registration and publication of Event Notification Delivery Methods
4727 and for the submission of such proposals.
4729 23.7.1. Requirements for Registration of Event Notification Delivery
4732 Registered IPP Event Notification Delivery Methods are expected to
4733 follow a number of requirements described below.
4735 23.7.1.1. Required Characteristics
4737 A Delivery Method Document MUST either (1) contain all of the
4738 semantics of the Delivery Method or (2) contain the IPP Delivery
4739 Method registration requirements and a profile of some other protocol
4740 that in combination is the Delivery Method (e.g., mailto). The
4741 Delivery Method Document (and any documents it requires) MUST define
4742 either (1) a URL for a Push Delivery Method that the meets the
4743 requirements of [RFC2717]. or (2) a keyword for a Pull Delivery
4746 IPP Event Notification Delivery Method Documents MUST meet the
4747 requirements of this document (see sections 9 and 10).
4749 In addition, a Delivery Method Document MUST contain the following
4752 Type of registration: IPP Event Notification Delivery Method
4753 Name of this delivery method:
4754 Proposed URL scheme name of this Push Delivery Method or the
4755 keyword name of this Pull Delivery Method:
4757 Address of proposer:
4762 Herriot & Hastings Standards Track [Page 85]
4764 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4767 Email address of proposer:
4768 Is this delivery method REQUIRED or OPTIONAL for conformance to
4769 the IPP Event Notification and Subscriptions document:
4770 Is this delivery method defining Machine Consumable and/or Human
4773 23.7.1.2. Naming Requirements
4775 Exactly one (URL scheme or keyword) name MUST be assigned to each
4778 Each assigned name MUST uniquely identify a single Delivery Method.
4779 All Push Delivery Method names MUST conform to the rules for URL
4780 scheme names, according to [RFC2396] and [RFC2717] for schemes in the
4781 IETF tree. All Pull Delivery Method names MUST conform to the rules
4782 for keywords according to [RFC2911].
4784 23.7.1.3. Functionality Requirements
4786 Delivery Methods MUST function as a protocol that is capable of
4787 delivering (push or pull) IPP Event Notifications to Notification
4790 23.7.1.4. Usage and Implementation Requirements
4792 Use of a large number of Delivery Methods may hamper
4793 interoperability. However, the use of a large number of undocumented
4794 and/or unlabeled Delivery Methods hampers interoperability even more.
4796 A Delivery Method should therefore be registered ONLY if it adds
4797 significant functionality that is valuable to a large community, OR
4798 if it documents existing practice in a large community. Note that
4799 Delivery Methods registered for the second reason should be
4800 explicitly marked as being of limited or specialized use and should
4801 only be used with prior bilateral agreement.
4803 23.7.1.5. Publication Requirements
4805 Delivery Method Documents MUST be published in a standards track,
4806 informational, or experimental RFCs.
4808 23.7.2. Registration Procedure
4810 The IPP WG is developing a small number of Delivery Methods which are
4811 intended to be published as standards track RFCs. However, some
4812 parties may wish to register additional Delivery Methods in the
4813 future. This section describes the procedures for these additional
4818 Herriot & Hastings Standards Track [Page 86]
4820 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4823 23.7.2.1. Present the proposal to the Community
4825 First the Delivery Method Document MUST be an Internet-Draft with a
4826 target category of standards track, informational, or experimental.
4827 The same MUST be true for any documents that it references.
4829 Deliver the proposed Delivery Method Document proposal to the
4830 "ipp@pwg.org" mailing list. This mailing list has been established
4831 by [RFC2911] for reviewing proposed registrations and discussing
4832 other IPP matters. Proposed Delivery Method Documents are not
4833 formally registered and MUST NOT be used until approved.
4835 The intent of the public posting is to solicit comments and feedback
4836 on the definition and suitability of the Delivery Method and the name
4837 chosen for it over a four week period.
4839 23.7.2.2. Delivery Method Reviewer
4841 The Delivery Method Reviewer is the same person who has been
4842 appointed by the IETF Application Area Director(s) as the IPP
4843 Designated Expert according to [RFC2911] and [IANA-CON]. When the
4844 four week period is over and the IPP Designated Expert is convinced
4845 that consensus has been achieved, the IPP Designated Expert either
4846 approves the request for registration or rejects it. Rejection may
4847 occur because of significant objections raised on the list or
4848 objections raised externally.
4850 Decisions made by the Reviewer must be posted to the ipp@pwg.org
4851 mailing list within 14 days. Decisions made by the Reviewer may be
4852 appealed to the IESG.
4854 23.7.2.3. IANA Registration
4856 Provided that the Delivery Method registration proposal has either
4857 passed review or has been successfully appealed to the IESG, the IANA
4858 will be notified by the delivery method reviewer and asked to
4859 register the Delivery Method and make it available to the community.
4861 23.7.3. Delivery Method Document Registrations
4863 Each Push Delivery Method Document defines a URI scheme. Such a URI
4864 scheme is used in a URI value of the "notification-recipient" (uri)
4865 Subscription Template attribute (see section 5.3.1) and the uriScheme
4866 value of the "notify-schemes-supported" (1setOf uriScheme 5.3.1.1)
4867 Printer attribute(see section ). Rather than creating a separate
4868 section in the IPP Registry for Delivery Methods, Push Delivery
4869 Methods will be registered as an additional value of the "notify-
4870 schemes-supported" Printer attribute. These uriScheme values will be
4874 Herriot & Hastings Standards Track [Page 87]
4876 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4879 registered according to the procedures of [RFC2911] section 7.1 for
4880 additional attribute values. Therefore, the IPP Registry entry for a
4881 Push Delivery Method will be of the form:
4885 --------------------- -------- -------
4886 notify-schemes-supported (1setOf uriScheme) [RFC3995] 5.3.1.1
4887 <scheme name> RFC xxxx m.n
4889 Each Pull Delivery Method Document defines a keyword method which is
4890 registered as an additional value of the "notify-pull-method" and
4891 "notify-pull-method-supported" Printer attributes. These keyword
4892 values will be registered according to the procedures of [RFC2911]
4893 section 7.1 for additional attribute values. Therefore, the IPP
4894 Registry entry for a Pull Delivery Method will be of the form:
4898 --------------------- -------- -------
4899 notify-pull-method (type2 keyword) [RFC3995] 5.3.2
4900 notify-pull-method-supported (1setOf type2 keyword)
4902 <method keyword name> RFC xxxx m.n
4904 23.7.4. Registration Template
4907 Subject: Registration of a new Delivery Method
4909 Delivery Method name:
4911 (All Push Delivery Method names must be suitable for use as the value
4912 of a URL scheme in the IETF tree and all Pull Delivery Method names
4913 must be suitable IPP keywords according to [RFC2911])
4915 Published specification(s):
4917 (A specification for the Delivery Method must be openly available
4918 that accurately describes what is being registered.)
4920 Person & email address to contact for further information:
4930 Herriot & Hastings Standards Track [Page 88]
4932 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4935 24. Internationalization Considerations
4937 This IPP Notification specification continues support for the
4938 internationalization of [RFC2911] of attributes containing text
4939 strings and names. Allowing a Subscribing Client to specify a
4940 different natural language and charset for each Subscription Object
4941 increases the internationalization support.
4943 The Printer MUST be able to localize the content of Human Consumable
4944 Event Notifications and to localize the value of "notify-text"
4945 attribute in Machine Consumable Event Notifications that it delivers
4946 to Notification Recipients. For localization, the Printer MUST use
4947 the value of the "notify-charset" attribute and the "notify-natural-
4948 language" attribute in the Subscription Object supplied by the
4951 25. Security Considerations
4953 Clients submitting Notification requests to the IPP Printer have the
4954 same security issues as submitting an IPP/1.1 print job request (see
4955 [RFC2911] section 3.2.1 and section 8). The same mechanisms used by
4956 IPP/1.1 can therefore be used by the client Notification submission.
4957 Operations that require authentication can use the HTTP
4958 authentication. Operations that require privacy can use the HTTP/TLS
4959 privacy. As with IPP/1.1 Print Job Objects, if there is no security
4960 on Subscription Objects, sequential assignment of subscription-ids
4961 exposes the system to a passive traffic monitoring threat.
4963 25.1. Client access rights
4965 The Subscription Object access control model is the same as the
4966 access control model for Job objects. The client MUST have the
4967 following access rights for the indicated Subscription operations:
4969 1. Create-Job-Subscriptions (see section 11.1.1): A Per-Job
4970 Subscription object is associated with a Job. To create Per-Job
4971 Subscription Objects, the authenticated user (see [RFC2911]
4972 section 8.3) performing this operation MUST (1) be the job owner,
4973 (2) have Operator or Administrator access rights for this Printer
4974 (see [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized
4975 by the Printer's administrator-configured security policy to
4976 create Per-Job Subscription Objects for the target job.
4978 2. Create-Printer-Subscriptions (see section 11.1.2): A Per-Printer
4979 Subscription object is associated with the Printer. To create
4980 Per-Printer Subscription Objects, the authenticated user (see
4981 [RFC2911] section 8.3) performing this operation MUST (1) have
4982 Operator or Administrator access rights for this Printer (see
4986 Herriot & Hastings Standards Track [Page 89]
4988 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
4991 [RFC2911] sections 1 and 8.5) or (2) be otherwise authorized by
4992 the Printer's administrator-configured security policy to create
4993 Per-Printer Subscription Objects for this Printer.
4995 3. Get-Subscription-Attributes (see section 11.2.4): The access
4996 control model for this operation is the same as that of the Get-
4997 Job-Attributes operation (see [RFC2911] section 3.3.4). The
4998 primary difference is that a Get-Subscription-Attributes operation
4999 is directed at a Subscription Object rather than at a Job object,
5000 and a returned attribute group contains Subscription Object
5001 attributes rather than Job object attributes. To query the
5002 specified Subscription Object, the authenticated user (see
5003 [RFC2911] section 8.3) performing this operation MUST (1) be the
5004 Subscription Object owner, (2) have Operator or Administrator
5005 access rights for this Printer (see [RFC2911] sections 1 and 8.5),
5006 or (3) be otherwise authorized by the Printer's administrator-
5007 configured security policy to query the Subscription Object for
5008 the target job. Furthermore, the Printer's security policy MAY
5009 limit which attributes are returned, in a manner similar to the
5010 Get-Job-Attributes operation (see [RFC2911] end of section
5013 4. Get-Subscriptions (see section 11.2.5): The access control model
5014 for this operation is the same as that of the Get-Jobs operation
5015 (see [RFC2911] section 3.2.6). The primary difference is that the
5016 operation is directed at Subscription Objects rather than at Job
5017 objects, and the returned attribute groups contain Subscription
5018 Object attributes rather than Job object attributes. To query
5019 Per-Job Subscription Objects of the specified job (client supplied
5020 the "notify-job-id" operation attribute - see section 11.2.5.1.1),
5021 the authenticated user (see [RFC2911] section 8.3) performing this
5022 operation MUST (1) be the Subscription Object owner, (2) have
5023 Operator or Administrator access rights for this Printer (see
5024 [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
5025 the Printer's administrator-configured security policy to query
5026 the Subscription Object for the target job. To query Per-Printer
5027 Subscription Objects of the Printer (client omits the "notify-
5028 job-id" operation attribute - see section 11.2.5.1.1), the
5029 authenticated user (see [RFC2911] section 8.3) performing this
5030 operation MUST (1) have Operator or Administrator access rights
5031 for this Printer (see [RFC2911] sections 1 and 8.5), or (2) be
5032 otherwise authorized by the Printer's administrator-configured
5033 security policy to query Per-Printer Subscription Objects for the
5034 target Printer. Furthermore, the Printer's security policy MAY
5035 limit which attributes are returned, in a manner similar to the
5036 Get-Job-Attributes operation (see [RFC2911] end of section
5042 Herriot & Hastings Standards Track [Page 90]
5044 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
5047 5. Renew-Subscriptions (see section 11.2.6): The authenticated user
5048 (see [RFC2911] section 8.3) performing this operation MUST (1) be
5049 the owner of the Per-Printer Subscription Object, (2) have
5050 Operator or Administrator access rights for the Printer (see
5051 [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
5052 the Printer's administrator-configured security policy to renew
5053 Per-Printer Subscription Objects for the target Printer
5055 6. Cancel-Subscription (see section 11.2.7): The authenticated user
5056 (see [RFC2911] section 8.3) performing this operation MUST (1) be
5057 the owner of the Subscription Object, (2) have Operator or
5058 Administrator access rights for the Printer (see [RFC2911]
5059 sections 1 and 8.5), or (3) be otherwise authorized by the
5060 Printer's administrator-configured security policy to cancel the
5061 target Subscription Object.
5063 The standard security concerns (delivery to the right user, privacy
5064 of content, tamper proof content) apply to each Delivery Method.
5065 Some Delivery Methods are more secure than others. Each Delivery
5066 Method Document MUST discuss its Security Considerations.
5068 25.2. Printer security threats
5070 Notification trap door: If a Printer supports the OPTIONAL "notify-
5071 attributes" Subscription Template attribute (see section 5.3.4) where
5072 the client can request that the Printer return any specified Job,
5073 Printer, and Subscription object attributes, the Printer MUST apply
5074 the same security policy to these requested attributes in the Get-
5075 Notifications request as it does for the Get-Jobs, Get-Job-
5076 Attributes, Get-Printer-Attributes, and Get-Subscription-Attributes
5079 25.3. Notification Recipient security threats
5081 Unwanted Events Notifications (spam): For any Push Delivery Method,
5082 by far the biggest security concern is the abuse of notification:
5083 delivering unwanted Event Notifications to third parties (i.e.,
5084 spam). The problem is made worse by notification addresses that may
5085 be redistributed to multiple parties. There exist scenarios where
5086 third party notification is used (see Scenario #2 and #3 in
5087 [RFC3997]). Any fully secure solution would require active agreement
5088 of all recipients before delivering anything.
5098 Herriot & Hastings Standards Track [Page 91]
5100 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
5103 26. Description of the base IPP documents (Informative)
5105 The base set of IPP documents includes:
5107 Design Goals for an Internet Printing Protocol [RFC2567]
5108 Rationale for the Structure and Model and Protocol for the Internet
5109 Printing Protocol [RFC2568]
5110 Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
5111 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
5112 Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
5113 Mapping between LPD and IPP Protocols [RFC2569]
5115 The "Design Goals for an Internet Printing Protocol" document takes a
5116 broad look at distributed printing functionality, and it enumerates
5117 real-life scenarios that help to clarify the features that need to be
5118 included in a printing protocol for the Internet. It identifies
5119 requirements for three types of users: end users, operators, and
5120 administrators. It calls out a subset of end user requirements that
5121 are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator
5122 operations have been added to IPP/1.1 [RFC2911, RFC2910].
5124 The "Rationale for the Structure and Model and Protocol for the
5125 Internet Printing Protocol" document describes IPP from a high level
5126 view, defines a roadmap for the various documents that form the suite
5127 of IPP specification documents, and gives background and rationale
5128 for the IETF IPP working group's major decisions.
5130 The "Internet Printing Protocol/1.1: Model and Semantics" document
5131 describes a simplified model with abstract objects, their attributes,
5132 and their operations. The model introduces a Printer and a Job. The
5133 Job supports multiple documents per Job. The model document also
5134 addresses how security, internationalization, and directory issues
5137 The "Internet Printing Protocol/1.1: Encoding and Transport" document
5138 is a formal mapping of the abstract operations and attributes defined
5139 in the model document onto HTTP/1.1 [RFC2616]. It also defines the
5140 encoding rules for a new Internet MIME media type called
5141 "application/ipp". This document also defines the rules for
5142 transporting over HTTP a message body whose Content-Type is
5143 "application/ipp". This document defines the 'ipp' scheme for
5144 identifying IPP printers and jobs.
5146 The "Internet Printing Protocol/1.1: Implementer's Guide" document
5147 gives insight and advice to implementers of IPP clients and IPP
5148 objects. It is intended to help them understand IPP/1.1 and some of
5149 the considerations that may assist them in the design of their client
5150 and/or IPP object implementations. For example, a typical order of
5154 Herriot & Hastings Standards Track [Page 92]
5156 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
5159 processing requests is given, including error checking. Motivation
5160 for some of the specification decisions is also included.
5162 The "Mapping between LPD and IPP Protocols" document gives some
5163 advice to implementers of gateways between IPP and LPD (Line Printer
5164 Daemon) implementations.
5168 The following people made significant contributions to the design and
5169 review of this specification:
5178 EMail: sisaacson@novell.com
5182 Utah Valley State College
5186 EMail: debryro@uvsc.edu
5192 Hudson, NH 03051-5308
5196 EMail: jkm@underscore.com
5201 800 Phillips Road MS 128-51E
5206 EMail: mshepherd@usa.xerox.com
5210 Herriot & Hastings Standards Track [Page 93]
5212 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
5216 Ricoh Printing Systems America
5217 1757 Tapo Canyon Road
5218 Simi Valley, CA 93063-3394
5222 EMail: ron.bergman@rpsa.ricoh.com
5227 Global Workflow Solutions
5232 EMail: bob@herriot.com
5237 701 S Aviation Blvd, ESAE 242
5238 El Segundo, CA 90245
5242 EMail: hastings@cp10.es.xerox.com
5266 Herriot & Hastings Standards Track [Page 94]
5268 RFC 3995 IPP: Event Notifications and Subscriptions March 2005
5271 Full Copyright Statement
5273 Copyright (C) The Internet Society (2005).
5275 This document is subject to the rights, licenses and restrictions
5276 contained in BCP 78, and except as set forth therein, the authors
5277 retain all their rights.
5279 This document and the information contained herein are provided on an
5280 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5281 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
5282 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
5283 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
5284 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5285 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5287 Intellectual Property
5289 The IETF takes no position regarding the validity or scope of any
5290 Intellectual Property Rights or other rights that might be claimed to
5291 pertain to the implementation or use of the technology described in
5292 this document or the extent to which any license under such rights
5293 might or might not be available; nor does it represent that it has
5294 made any independent effort to identify any such rights. Information
5295 on the procedures with respect to rights in RFC documents can be
5296 found in BCP 78 and BCP 79.
5298 Copies of IPR disclosures made to the IETF Secretariat and any
5299 assurances of licenses to be made available, or the result of an
5300 attempt made to obtain a general license or permission for the use of
5301 such proprietary rights by implementers or users of this
5302 specification can be obtained from the IETF on-line IPR repository at
5303 http://www.ietf.org/ipr.
5305 The IETF invites any interested party to bring to its attention any
5306 copyrights, patents or patent applications, or other proprietary
5307 rights that may cover technology that may be required to implement
5308 this standard. Please address the information to the IETF at ietf-
5313 Funding for the RFC Editor function is currently provided by the
5322 Herriot & Hastings Standards Track [Page 95]