doc: Add RFC documents

1 files changed, 5323 insertions, 0 deletions

diff --git a/doc/rfc/rfc3995.txt b/doc/rfc/rfc3995.txt
new file mode 100644
index 0000000..9a8013b
--- /dev/null
+++ b/doc/rfc/rfc3995.txt
@@ -0,0 +1,5323 @@
+
+
+
+
+
+
+Network Working Group                                         R. Herriot
+Request for Comments: 3995                     Global Workflow Solutions
+Category: Standards Track                                    T. Hastings
+Updates: 2911, 2910                                    Xerox Corporation
+                                                              March 2005
+
+
+                   Internet Printing Protocol (IPP):
+                 Event Notifications and Subscriptions
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes an OPTIONAL extension to the Internet
+   Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).
+   This extension allows a client to subscribe to printing related
+   Events.  Subscriptions are modeled as Subscription Objects.  The
+   Subscription Object specifies that when one of the specified Events
+   occurs, the Printer delivers an asynchronous Event Notification to
+   the specified Notification Recipient via the specified Push or Pull
+   Delivery Method (i.e., protocol).
+
+   A client associates Subscription Objects with a particular Job by
+   performing the Create-Job-Subscriptions operation or by submitting a
+   Job with subscription information.  A client associates Subscription
+   Objects with the Printer by performing a Create-Printer-Subscriptions
+   operation.  Four other operations are defined for Subscription
+   Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-
+   Subscription, and Cancel-Subscription.
+
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 1]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+       1.1.  Notification Overview. . . . . . . . . . . . . . . . . .  5
+   2.  Models for Notification. . . . . . . . . . . . . . . . . . . .  8
+       2.1.  Model for Simple Notification (Normative). . . . . . . .  8
+       2.2.  Additional Models for Notification (Informative) . . . .  9
+   3.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  9
+       3.1.  Conformance Terminology. . . . . . . . . . . . . . . . .  9
+       3.2.  Other Terminology. . . . . . . . . . . . . . . . . . . . 10
+   4.  Object Relationships . . . . . . . . . . . . . . . . . . . . . 12
+       4.1.  Printer and Per-Printer Subscription Objects . . . . . . 13
+       4.2.  Printer, Job and Per-Job Subscription Objects. . . . . . 13
+   5.  Subscription Object. . . . . . . . . . . . . . . . . . . . . . 13
+       5.1.  Rules for Support of Subscription Template Attributes. . 14
+       5.2.  Rules for Processing Subscription Template Attributes. . 15
+       5.3.  Subscription Template Attributes . . . . . . . . . . . . 18
+             5.3.1.  notify-recipient-uri (uri) . . . . . . . . . . . 20
+             5.3.2.  notify-pull-method (type2 keyword) . . . . . . . 21
+             5.3.3.  notify-events (1setOf type2 keyword) . . . . . . 22
+             5.3.4.  notify-attributes (1setOf type2 keyword) . . . . 29
+             5.3.5.  notify-user-data (octetString(63)) . . . . . . . 30
+             5.3.6.  notify-charset (charset) . . . . . . . . . . . . 31
+             5.3.7.  notify-natural-language (naturalLanguage). . . . 31
+             5.3.8.  notify-lease-duration (integer(0:67108863)). . . 32
+             5.3.9.  notify-time-interval (integer(0:MAX)). . . . . . 33
+       5.4.  Subscription Description Attributes. . . . . . . . . . . 34
+             5.4.1.  notify-subscription-id  (integer (1:MAX)). . . . 35
+             5.4.2.  notify-sequence-number (integer (0:MAX)) . . . . 35
+             5.4.3.  notify-lease-expiration-time (integer(0:MAX)). . 36
+             5.4.4.  notify-printer-up-time (integer(1:MAX)). . . . . 37
+             5.4.5.  notify-printer-uri (uri) . . . . . . . . . . . . 37
+             5.4.6.  notify-job-id (integer(1:MAX)) . . . . . . . . . 37
+             5.4.7.  notify-subscriber-user-name (name(MAX)). . . . . 38
+   6.  Printer Description Attributes Related to Notification . . . . 38
+       6.1.  printer-state-change-time (integer(1:MAX)) . . . . . . . 39
+       6.2.  printer-state-change-date-time (dateTime). . . . . . . . 39
+   7.  New Values for Existing Printer Description Attributes . . . . 39
+       7.1.  operations-supported (1setOf type2 enum) . . . . . . . . 40
+   8.  Attributes Only in Event Notifications . . . . . . . . . . . . 40
+       8.1.  notify-subscribed-event (type2 keyword). . . . . . . . . 40
+       8.2.  notify-text (text(MAX)). . . . . . . . . . . . . . . . . 41
+   9.  Event Notification Content . . . . . . . . . . . . . . . . . . 41
+       9.1.  Content of Machine Consumable Event Notifications. . . . 44
+             9.1.1.  Event Notification Content Common to All Events. 44
+             9.1.2.  Additional Event Notification Content for Job
+                     Events . . . . . . . . . . . . . . . . . . . . . 45
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 2]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+             9.1.3.  Additional Event Notification Content for
+                     Printer Events . . . . . . . . . . . . . . . . . 46
+       9.2.  Content of Human Consumable Event Notification . . . . . 46
+             9.2.1.  Event Notification Content Common to All Events. 47
+             9.2.2.  Additional Event Notification Content for Job
+                     Events . . . . . . . . . . . . . . . . . . . . . 49
+             9.2.3.  Additional Event Notification Content for
+                     Printer Events . . . . . . . . . . . . . . . . . 49
+   10. Delivery Methods . . . . . . . . . . . . . . . . . . . . . . . 50
+   11. Operations for Notification. . . . . . . . . . . . . . . . . . 52
+       11.1. Subscription Creation Operations . . . . . . . . . . . . 52
+             11.1.1. Create-Job-Subscriptions Operation . . . . . . . 52
+             11.1.2. Create-Printer-Subscriptions operation . . . . . 55
+             11.1.3. Job Creation Operations - Extensions for
+                     Notification . . . . . . . . . . . . . . . . . . 56
+       11.2 Other Operations. . . . . . . . . . . . . . . . . . . . . 58
+             11.2.1. Restart-Job Operation - Extensions for
+                     Notification . . . . . . . . . . . . . . . . . . 58
+             11.2.2. Validate-Job Operation - Extensions for
+                     Notification . . . . . . . . . . . . . . . . . . 59
+             11.2.3. Get-Printer-Attributes - Extensions for
+                     Notification . . . . . . . . . . . . . . . . . . 59
+             11.2.4. Get-Subscription-Attributes operation. . . . . . 60
+             11.2.5. Get-Subscriptions operation. . . . . . . . . . . 63
+             11.2.6. Renew-Subscription operation . . . . . . . . . . 66
+             11.2.7. Cancel-Subscription operation. . . . . . . . . . 68
+   12. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . 70
+       12.1. successful-ok-ignored-subscriptions (0x0003) . . . . . . 70
+       12.2. client-error-ignored-all-subscriptions (0x0414). . . . . 71
+   13. Status Codes in Subscription Attributes Groups . . . . . . . . 71
+       13.1. client-error-uri-scheme-not-supported (0x040C) . . . . . 71
+       13.2. client-error-attributes-or-values-not-supported (0x040B) 71
+       13.3. client-error-too-many-subscriptions (0x0415) . . . . . . 72
+       13.4. successful-ok-too-many-events (0x0005) . . . . . . . . . 72
+       13.5. successful-ok-ignored-or-substituted-attributes (0x0001) 72
+   14. Encodings of Additional Attribute Tags . . . . . . . . . . . . 72
+   15. Conformance Requirements . . . . . . . . . . . . . . . . . . . 72
+       15.1. Conformance requirements for clients . . . . . . . . . . 73
+       15.2. Conformance requirements for Printers. . . . . . . . . . 73
+   16. Model for Notification with Cascading Printers (Informative) . 74
+   17. Distributed Model for Notification (Informative) . . . . . . . 75
+   18. Extended Notification Recipient (Informative). . . . . . . . . 76
+   19. Object Model for Notification (Normative). . . . . . . . . . . 77
+       19.1. Object relationships . . . . . . . . . . . . . . . . . . 78
+       19.2. Printer Object and Per-Printer Subscription Objects. . . 79
+       19.3. Job Object and Per-Job Subscription Objects. . . . . . . 79
+   20. Per-Job versus Per-Printer Subscription Objects (Normative). . 79
+   21. Normative References . . . . . . . . . . . . . . . . . . . . . 80
+
+
+
+Herriot & Hastings          Standards Track                     [Page 3]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   22. Informative References . . . . . . . . . . . . . . . . . . . . 80
+   23. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 81
+       23.1. Attribute Registrations. . . . . . . . . . . . . . . . . 82
+       23.2. Additional Enum Attribute Value Registrations within
+             the IPP registry . . . . . . . . . . . . . . . . . . . . 83
+       23.3. Operation Registrations. . . . . . . . . . . . . . . . . 83
+       23.4. Status code Registrations. . . . . . . . . . . . . . . . 83
+       23.5. Attribute Group tag Registrations. . . . . . . . . . . . 84
+       23.6. Registration of Events . . . . . . . . . . . . . . . . . 84
+       23.7. Registration of Event Notification Delivery Methods. . . 85
+             23.7.1. Requirements for Registration of Event
+                     Notification Delivery Methods. . . . . . . . . . 85
+             23.7.2. Registration Procedure . . . . . . . . . . . . . 86
+             23.7.3. Delivery Method Document Registrations . . . . . 87
+             23.7.4. Registration Template. . . . . . . . . . . . . . 88
+   24. Internationalization Considerations. . . . . . . . . . . . . . 89
+   25. Security Considerations. . . . . . . . . . . . . . . . . . . . 89
+       25.1. Client access rights . . . . . . . . . . . . . . . . . . 89
+       25.2. Printer security threats . . . . . . . . . . . . . . . . 91
+       25.3. Notification Recipient security threats. . . . . . . . . 91
+   26. Description of the base IPP documents (Informative). . . . . . 92
+   27. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 93
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 95
+
+Tables
+
+   Table 1  - Subscription Template Attributes. . . . . . . . . . . . 20
+   Table 2  - Subscription Description Attributes . . . . . . . . . . 35
+   Table 3  - Printer Description Attributes Associated with
+              Notification. . . . . . . . . . . . . . . . . . . . . . 39
+   Table 4  - Operation-id assignments. . . . . . . . . . . . . . . . 40
+   Table 5  - Attributes in Event Notification Content. . . . . . . . 45
+   Table 6  - Additional Event Notification Content for Job Events. . 46
+   Table 7  - Combinations of Events and Subscribed Events for
+              "job-impressions-completed" . . . . . . . . . . . . . . 46
+   Table 8  - Additional Event Notification Content for Printer
+              Events. . . . . . . . . . . . . . . . . . . . . . . . . 46
+   Table 9  - Printer Name in Event Notification Content. . . . . . . 48
+   Table 10 - Event Name in Event Notification Content. . . . . . . . 48
+   Table 11 - Event Time in Event Notification Content. . . . . . . . 48
+   Table 12 - Job Name in Event Notification Content. . . . . . . . . 49
+   Table 13 - Job State in Event Notification Content . . . . . . . . 49
+   Table 14 - Printer State in Event Notification Content . . . . . . 50
+   Table 15 - Information about the Delivery Method . . . . . . . . . 51
+   Table 16 - Printer Conformance Requirements for Operations . . . . 74
+
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 4]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+Figures
+
+   Figure 1 - Model for Notification. . . . . . . . . . . . . . . . .  9
+   Figure 2 - Model for Notification with Cascading Printers. . . . . 75
+   Figure 3 - Opaque Use of a Notification Server Transparent to the
+              Client. . . . . . . . . . . . . . . . . . . . . . . . . 76
+   Figure 4 - Use of an Extended Notification Recipient transparent
+              to the Printer. . . . . . . . . . . . . . . . . . . . . 77
+   Figure 5 - Object Model for Notification . . . . . . . . . . . . . 78
+
+1.  Introduction
+
+   This IPP notification specification is an OPTIONAL extension to
+   Internet Printing Protocol/1.1: Model and Semantics [RFC2911,
+   RFC2910].  See Appendix 29 for a description of the base IPP
+   documents.  This document in combination with the following documents
+   is intended to meet the most important notification requirements
+   described in [RFC3997]:
+
+      Internet Printing Protocol (IPP):  "Job Progress Attributes"
+      [RFC3381]
+
+      Internet Printing Protocol (IPP):  "The 'ippget' Delivery Method
+      for Event Notifications" [RFC3996]
+
+   This specification REQUIRES that clients and Printers support the
+   'ippget' Pull Delivery Method [RFC3996].  Conforming client and
+   Printer implementations MAY support additional Push or Pull Delivery
+   Methods as well.  Note: this document does not define any Delivery
+   Methods itself, but it does define the rules for conformance for
+   Delivery Method Documents and their registration with IANA (see
+   section 23.7.3).
+
+   Refer to the Table of Contents for the layout of this document.
+
+1.1.  Notification Overview
+
+   This document defines operations that a client can perform in order
+   to create Subscription Objects in a Printer and carry out other
+   operations on them.  A Subscription Object represents a Subscription
+   abstraction.  The Subscription Object specifies that when one of the
+   specified Events occurs, the Printer delivers an asynchronous Event
+   Notification to the specified Notification Recipient via the
+   specified Delivery Method (i.e., protocol).
+
+   When a client (called a Subscribing Client) performs an operation
+   that creates a Subscription Object, the operation contains one or
+   more Subscription Template Attributes Groups.  Each such group holds
+
+
+
+Herriot & Hastings          Standards Track                     [Page 5]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   information used by the Printer to initialize a newly created
+   Subscription Object.  The Printer creates one Subscription Object for
+   each Subscription Template Attributes Group in the operation.  This
+   group is like the Job Template Attributes group defined in [RFC2911].
+   The following is an example of the information included in a
+   Subscription Template Attributes Group (see section 5 for details on
+   the Subscription Object attributes):
+
+   1. The names of Subscribed Events that are of interest to the
+      Notification Recipient.
+
+   2. The address (URL) of one Notification Recipient for a Push
+      Delivery Method or the method for a Pull Delivery Method.
+
+   3. The Delivery Method (i.e., the protocol) which the Printer uses to
+      deliver the Event Notification.
+
+   4. Some opaque data that the Printer delivers to the Notification
+      Recipient in the Event Notification.  For example, the
+      Notification Recipient might use this opaque data as a forwarding
+      address for the Event Notification.
+
+   5. The charset to use in text fields within an Event Notification
+
+   6. The natural language to use in the text fields of the Event
+      Notification
+
+   7. The requested lease time in seconds for the Subscription Object
+
+   An operation that creates a Subscription Object is called a
+   Subscription Creation Operation.  These operations include the
+   following operations (see section 11.1 for further details):
+
+      -  Job Creation operation: When a client performs such an
+         operation (Print-Job, Print-URI, and Create-Job), a client can
+         include zero or more Subscription Template Attributes Groups in
+         the request.  The Printer creates one Subscription Object for
+         each Subscription Template Attributes Group in the request, and
+         the Printer associates each such Subscription Object with the
+         newly created Job.  This document extends these operations'
+         definitions in [RFC2911] by adding Subscription Template
+         Attributes Groups in the request and Subscription Attributes
+         Groups in the response.
+
+      -  Create-Job-Subscriptions operation: A client can include one or
+         more Subscription Template Attributes Groups in the request.
+         The Printer creates one Subscription Object for each
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 6]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         Subscription Template Attributes Group and associates each with
+         the job that is the target of this operation.
+
+      -  Create-Printer-Subscriptions operation: A client can include
+         one or more Subscription Template Attributes Groups in the
+         request.  The Printer creates one Subscription Object for each
+         Subscription Template Attributes Group and associates each with
+         the Printer that is the target of this operation.
+
+   For each of the above operations:
+
+      -  the Printer associates a Subscription Object with the Printer
+         or a specific Job.  When a Subscription Object is associated
+         with a Job Object, it is called a Per-Job Subscription Object.
+         When a Subscription Object is associated with a Printer Object,
+         it is called a Per-Printer Subscription Object.
+
+      -  the response contains one Subscription Attributes Group for
+         each Subscription Template Attributes Group in the request and
+         in the same order.  When the Printer successfully creates a
+         Subscription Object, its corresponding Subscription Attributes
+         Group contains the "notify-subscription-id" attribute.  This
+         attribute uniquely identifies the Subscription Object and is
+         analogous to a "job-id" for a Job object.  Some operations
+         described below use the "notify-subscription-id" to identify
+         the target Subscription Object.
+
+   This document defines the following additional operations (see
+   section 11.2 for further details):
+
+   -  Restart-Job operation: When a client performs the Restart-Job
+      operation [RFC2911], the Printer re-uses the same Job and its
+      Subscription Objects.
+
+   -  Validate-Job operation: When a client performs this operation, a
+      client can include zero or more Subscription Template Attributes
+      Groups in the request.  The Printer determines if it could create
+      one Subscription Object for each Subscription Template Attributes
+      Group in the request.  This document extends this operation's
+      definition in [RFC2911] by adding Subscription Template Attributes
+      Groups in the request and Subscription Attributes Groups in the
+      response.
+
+   -  Get-Subscription-Attributes operation: This operation allows a
+      client to obtain the specified attributes of a target Subscription
+      Object.
+
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 7]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   -  Get-Subscriptions operation: This operation allows a client to
+      obtain the specified attributes of all Subscription Objects
+      associated with the Printer or a specified Job.
+
+   -  Renew-Subscription operation: This operation renews the lease on
+      the target Per-Printer Subscription Object before it expires.  A
+      newly created Per-Printer Subscription Object receives an initial
+      lease.  It is the duty of the client to use this operation
+      frequently enough to preserve a Per-Printer Subscription Object.
+      The Printer deletes a Per-Printer Subscription Object when its
+      lease expires.  A Per-Job Subscription Object last exactly as long
+      as its associated Job Object and thus doesn't have a lease.
+
+   -  Cancel-Subscription operation: This operation (1) cancels the
+      lease on the specified Per-Printer Subscription Object and thereby
+      deletes the Per-Printer Subscription Object or (2) deletes the
+      Per-Job Subscription Object.
+
+   When an Event occurs, the Printer finds all Subscription Objects
+   listening for the Event (see section 9 for details on finding such
+   Subscription Objects).  For each such Subscription Object, the
+   Printer:
+
+   a) generates an Event Notification with information specified in
+      section 9, AND
+
+   b) either:
+
+      i)  If the Delivery Method is a Push Delivery Method as indicated
+          by the presence of the Subscription Object's "notify-
+          recipient-uri" attribute, delivers the Event Notification
+          using the Delivery Method and target address identified in the
+          Subscription Object's "notify-recipient-uri" attribute, OR
+
+      ii) If the Delivery Method is a Pull Delivery Method as indicated
+          by the presence of the Subscription Object's "notify-pull-
+          method" attribute, saves Event Notification for a time period
+          called the Event Life defined by the Delivery Method, i.e.,
+          the Notification Recipient is expected to fetch the Event
+          Notifications.
+
+2.  Models for Notification
+
+2.1.  Model for Simple Notification (Normative)
+
+   As part of a Subscription Creation Operation, an IPP Printer (i.e.,
+   located in an output device or a server) creates one or more
+   Subscription Objects.  In a Subscription Creation Operation, the
+
+
+
+Herriot & Hastings          Standards Track                     [Page 8]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   client specifies the Notification Recipient to which the Printer is
+   to deliver Event Notifications.  A Notification Recipient can be the
+   Subscribing Client or a third party.
+
+   Figure 1 shows the Notification model for a simple Client-Printer
+   relationship.
+
+   embedded printer:
+
+                                        output device or server
+   PDA, desktop, or server                 +---------------+
+        +--------+                         |  ###########  |
+        | client |-----Subscription ---------># Printer #  |
+        +--------+  Creation Operation     |  # Object  #  |
+     +------------+                        |  #####|#####  |
+     |Notification|                        +-------|-------+
+     |Recipient   |<----IPP Event Notifications----+
+     +------------+    (Job and/or Printer Events)
+
+                  Figure 1 - Model for Notification
+
+2.2.  Additional Models for Notification (Informative)
+
+   Additional models have been proposed (see Appendices 16, 17, and 18).
+
+3.  Terminology
+
+   This section defines terminology used throughout this document.
+   Other terminology is defined in [RFC2911].
+
+3.1.  Conformance Terminology
+
+   Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
+   NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
+   conformance as defined in RFC 2119 [RFC2119] and [RFC2911] section
+   12.1.  If an implementation supports the extension defined in this
+   document, then these terms apply; otherwise, they do not.  These
+   terms define conformance to this document only; they do not affect
+   conformance to other documents, unless explicitly stated otherwise.
+
+   Note: a feature that is OPTIONAL in this document becomes REQUIRED if
+   the Printer implements a Delivery Method that REQUIRES the feature.
+
+   READ-ONLY - an adjective used in an attribute definition to indicate
+   that an IPP Printer MUST NOT allow the attribute's value to be
+   modified.
+
+
+
+
+
+Herriot & Hastings          Standards Track                     [Page 9]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+3.2.  Other Terminology
+
+   This document uses the same terminology as [RFC2911], such as
+   "client", "Printer", "attribute", "attribute value", "keyword",
+   "operation", "request", "response", "administrator", "operator", and
+   "support".  In addition, the following terms are defined for use in
+   this document and the Delivery Method Documents:
+
+   Compound Event Notification - two or more Event Notifications that a
+   Printer delivers together as a single request or response.  The
+   Delivery Method Document specifies whether the Delivery Method
+   supports Compound Event Notifications.
+
+   Delivery Method - the mechanism by which the Printer delivers an
+   Event Notification.
+
+   Delivery Method Document - a document, separate from this document,
+   that defines a Delivery Method.
+
+   Event - some occurrence (either expected or unexpected) within the
+   printing system of a change of state, condition, or configuration of
+   a Job or Printer object.  An Event occurs only at one instant in time
+   and does not span the time the physical Event takes place.  For
+   example, jam-occurred and jam-cleared are two distinct, instantaneous
+   Events, even though the jam may last for a while.
+
+   Event Life - For a Pull Delivery Method, the length of time in
+   seconds after an Event occurs during which the Printer will retain
+   that Event for delivery in an Event Notification.  After the Event
+   Life expires, the Printer will no longer deliver an Event
+   Notification for that Event in such a response.
+
+   Event Notification - the information about an Event that the Printer
+   delivers when an Event occurs.
+
+   Event Notification Attributes Group - The attributes group which is
+   used to deliver an Event Notification in a request (Push Delivery
+   Methods) or a response (Pull Delivery Methods).
+
+   Human Consumable Event Notification - localized text for human
+   consumption only.  There is no standardized format and thus programs
+   should not try to parse this text.
+
+   Job Creation operation - One of the operations that creates a Job
+   object:  Print-Job, Print-URI and Create-Job.  The Restart-Job
+   operation [RFC2911] is not considered a Job Creation operation, since
+   the Printer re-uses the existing Job object.  The Validate-Job
+   operation is not considered a Job Creation operation because no Job
+
+
+
+Herriot & Hastings          Standards Track                    [Page 10]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   object is created.  Therefore, when a statement also applies to
+   either the Restart-Job and/or the Validate-Job operation, they are
+   mentioned explicitly.
+
+   Job Event - an Event caused by some change in a particular job on the
+   Printer, e.g., 'job-completed'.
+
+   Machine Consumable Event Notification - bytes for program
+   consumption.  The bytes are formatted according to the Delivery
+   Method document.
+
+   Notification - when not in the phrases 'Event Notification' and
+   'Notification Recipient' - the concepts of this specification, i.e.,
+   Events, Subscription Objects, and Event Notifications.
+
+   Notification Recipient - the entity to which the Printer delivers an
+   Event Notification.  For Push Delivery Methods, the IPP Printer sends
+   the Notifications to a Notification Recipient.  For Pull Delivery
+   Methods, the Notification Recipient is acting in the role of an IPP
+   client and requests Event Notifications and so the terms "client" and
+
+   "Notification Recipient" are used interchangeably with such Delivery
+   Methods.  For example, see [RFC3996].
+
+   Per-Job Subscription Object - A Subscription Object that is
+   associated with a single Job.  The Create-Job-Subscriptions operation
+   and Job Creation operations create such an object.
+
+   Per-Printer Subscription Object - A Subscription Object that is
+   associated with the Printer as a whole.  The Create-Printer-
+   Subscriptions operation creates such an object.
+
+   Printer Event - an Event caused by some change in the Printer that is
+   not specific to a job, e.g., 'printer-state-changed'.
+
+   Pull Delivery Method - The Printer saves Event Notifications for some
+   event life time and expects the Notification Recipient to request
+   Event Notifications.  The Printer delivers the Event Notifications in
+   a response to such a request.
+
+   Push Delivery Method -The Printer delivers the Event Notification
+   shortly after an Event occurs.
+
+   Subscribed Event - an Event that the Subscribing Client expresses
+   interest in by making it a value of the "notify-events" attribute on
+   a Subscription Object.
+
+   Subscribed Job Event - a Subscribed Event that is a Job Event.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 11]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Subscribed Printer Event - a Subscribed Event that is a Printer
+   Event.
+
+   Subscribing Client - The client that creates the Subscription Object.
+
+   Subscription Attributes Group - The attributes group in a response
+   that contains Subscription Object attributes.
+
+   Subscription Creation Operation - An operation that creates a
+   Subscription Object:  Job Creation operations, Create-Job-
+   Subscriptions operation, Create-Printer-Subscriptions operation.  In
+   the context of a Job Creation operation, a Subscription Creation
+   Operation is the part of the Job Creation operation that creates one
+   or more Subscription objects.  The Restart-Job operation [RFC2911] is
+   not considered a Subscription Creation Operation, since the Printer
+   re-uses the Job's existing Subscription Objects, rather than creating
+   any new Subscription Objects.
+
+   Subscription Creation Request - The request portion of a Subscription
+   Creation Operation.
+
+   Subscription Description Attributes - Subscription Object attributes
+   that a Printer supplies during a Subscription Creation Operation.
+
+   Subscription Object - An object containing a set of attributes that
+   indicate:  the Notification Recipient (for Push Delivery Method
+   only), the Delivery Method, the Subscribed Events that cause the
+   Printer to deliver an Event Notification, and the information to
+   include in an Event Notification.
+
+   Subscription Template Attributes - Subscription Object attributes
+   that a client can supply in a Subscription Creation Operation and
+   associated Printer Object attributes that specify supported and
+   default values for the Subscription Object attributes.
+
+   Subscription Template Attributes Group - The attributes group in a
+   request that contains Subscription Object attributes that are
+   Subscription Template Attributes.
+
+4.  Object Relationships
+
+   This section defines the object relationships between the Printer,
+   Job, and Subscription Objects.  It does not define the
+   implementation.  For an illustration of these relationships, see
+   Appendix 19.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 12]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+4.1.  Printer and Per-Printer Subscription Objects
+
+   1. A Printer object can be associated with zero or more Per-Printer
+      Subscription Objects.
+
+   2. Each Per-Printer Subscription Object is associated with exactly
+      one Printer object.
+
+4.2.  Printer, Job and Per-Job Subscription Objects
+
+   1. A Printer object is associated with zero or more Job objects.
+
+   2. Each Job object is associated with exactly one Printer object.
+
+   3. A Job object is associated with zero or more Per-Job Subscription
+      Objects.
+
+   4. Each Per-Job Subscription Object is associated with exactly one
+      Job object.
+
+5.  Subscription Object
+
+   A Subscribing Client creates a Subscription Object with a
+   Subscription Creation Operation in order to indicate its interest in
+   certain Events.  See section 11 for a description of these
+   operations.  When an Event occurs, the Subscription Object specifies
+   to the Printer where to deliver Event Notifications for Push Delivery
+   Methods only, how to deliver them, and what to include in them.  See
+   section 9 for details on the contents of an Event Notification.
+
+   Using the IPP Job Template attributes as a model (see [RFC2911]
+   section 4.2), the attributes of a Subscription Object are divided
+   into two categories: Subscription Template Attributes and
+   Subscription Description Attributes.
+
+   Subscription Template attributes are, in turn, like the Job Template
+   attributes, divided into
+
+   1. Subscription Object attributes that a client can supply in a
+      Subscription Creation Request and
+
+   2. their associated Printer Object attributes that specify supported
+      and default values for the Subscription Object attributes
+
+   The remainder of this section specifies general rules for
+   Subscription Template Attributes and describes each attribute in a
+   Subscription Object.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 13]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+5.1.  Rules for Support of Subscription Template Attributes
+
+   Subscription Template Attributes are fundamental to the Notification
+   model described in this specification.  The client supplies these
+   attributes in Subscription Creation Operations and the Printer uses
+   these attributes to populate a newly created Subscription Object.
+
+   Subscription Objects attributes that are Subscription Template
+   Attributes conform to the following rules:
+
+   1. Each attribute's name starts with the prefix string "notify-" and
+      this document calls such attributes "notify-xxx".
+
+   2. For each "notify-xxx" Subscription Object attribute defined in
+      column 1 of Table 1 in section 5.3, Table 1 specifies
+      corresponding Printer attributes: "notify-xxx-default", "notify-
+      xxx-supported", "yyy-supported" and "notify-max-xxx-supported"
+      defined in column 2 of Table 1.  Note "xxx" stands for the same
+      string in each case and "yyy" stands for some other string.
+
+   3. If a Printer supports "notify-xxx" in column 1 of Table 1, then
+      the Printer MUST support all associated attributes specified in
+      column 2 of Table 1.  For example, Table 1 shows that if the
+      Printer supports "notify-events", it MUST support "notify-events-
+      default", "notify-events-supported" and "notify-max-events-
+      supported".
+
+   4. If a Printer does not support "notify-xxx" in column 1 of Table 1,
+      then the Printer MUST NOT support any associated "notify-yyy"
+      attributes specified in column 2 of Table 1.  For example, Table 1
+      shows that if the Printer doesn't support "notify-events", it MUST
+      NOT support "notify-events-default", "notify-events-supported" and
+      "notify-max-events-supported".  Note this rule does not apply to
+      attributes whose names do not start with the string "notify-" and
+      are thus defined in another object and used by other attributes.
+
+   5. Most "notify-xxx" attributes have a corresponding "yyy-supported"
+      attribute that specifies the supported values for "notify-xxx".
+      Column 2 of Table 1 specifies the name of each "yyy-supported"
+      attribute.  The naming rules of IPP/1.1 (see [RFC2911]) are used
+      when "yyy-supported" is "notify-xxx-supported".
+
+   6. Some "notify-xxx" attributes have a corresponding "notify-xxx-
+      default" attribute that specifies the value for "notify-xxx" if
+      the client does not supply it.  Column 2 of Table 1 specifies the
+      name of each "notify-xxx-default" attribute.  The naming rules of
+      IPP/1.1 (see [RFC2911]) are used.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 14]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   If a client wishes to present an end user with a list of supported
+   values from which to choose, the client SHOULD query the Printer for
+   its supported value attributes.  The client SHOULD also query the
+   default value attributes.  If the client then limits selectable
+   values to only those values that are supported, the client can
+   guarantee that the values supplied by the client in the create
+   request all fall within the set of supported values at the Printer.
+   When querying the Printer, the client MAY enumerate each attribute by
+   name in the Get-Printer-Attributes Request, or the client MAY just
+   supply the 'subscription-template' group name in order to get the
+   complete set of supported attributes (both supported and default
+   attributes - see section 11.2.3).
+
+5.2.  Rules for Processing Subscription Template Attributes
+
+   This section defines a detailed set of rules that a Printer follows
+   when it processes Subscription Template Attributes in a Subscription
+   Creation Request.  These rules are similar to the rules for
+   processing Operation attributes in [RFC2911].  That is, the Printer
+   may or may not support an attribute and a client may or may not
+   supply the attribute.  Some combinations of these cases are OK.
+   Others return warnings or errors, and perhaps a list of unsupported
+   attributes.
+
+   A Printer MUST implement the following behavior for processing
+   Subscription Template Attributes in a Subscription Creation Request:
+
+   1. If a client supplies a "notify-xxx" attribute from column 1 of
+      Table 1 and the Printer supports it and its value, the Printer
+      MUST populate the attribute on the created Subscription Object.
+
+   2. If a client supplies a "notify-xxx" attribute from column 1 of
+      Table 1 and the Printer doesn't support it or its value, the
+      Printer MUST NOT populate the attribute on the created
+      Subscription Object with it.  The Printer MUST do one of the
+      following:
+
+      a) If the value of the "notify-xxx" attribute is unsupported, the
+         Printer MUST return the attribute with its value in the
+         Subscription Attributes Group of the response.
+
+      b) If "notify-xxx" is an unsupported attribute, the Printer MUST
+         return the attribute in the Subscription Attributes Group of
+         the response with the 'unsupported' out-of-band value.
+
+      Note:  The rules of this step are the same as for Unsupported
+      Attributes [RFC2911] section 3.1.7.  except that the unsupported
+      attributes are returned in the Subscription Attributes Group
+
+
+
+Herriot & Hastings          Standards Track                    [Page 15]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      rather than the Unsupported Attributes Group because Subscription
+      Creation Operations can create more than one Subscription Object).
+
+   3. If a client is REQUIRED to supply a "notify-xxx" attribute from
+      column 1 of Table 1 and the Printer doesn't support the supplied
+      value, the Printer MUST NOT create a Subscription Object.  The
+      rules for Unsupported Attributes in step #2 still apply.
+
+   4. If a client does not supply a "notify-xxx" attribute from column 1
+      of Table 1 and the attribute is REQUIRED for the client to supply,
+      the Printer MUST reject the Subscription Creation Operation
+      (including Job Creation operations) without creating a
+      Subscription Object, and MUST return in the response:
+
+      a) the status code 'client-error-bad-request' AND
+
+      b) no Subscription Attribute Groups.
+
+   5. If a client does not supply a "notify-xxx" attribute from column 1
+      of Table 1 that is OPTIONAL for the client to supply, and column 2
+      of Table 1 either:
+
+      a) specifies a "notify-xxx-default" attribute, the Printer MUST
+         behave as if the client had supplied the "notify-xxx-default"
+         attribute (see step #1) and populate the Subscription object
+         with the value of the "notify-xxx-default" attribute as part of
+         the Subscription Creation operation (unlike Job Template
+         attributes where the Printer does not populate the Job object
+         with defaults - see [RFC2911]) OR
+
+      b) does not specify a "notify-xxx-default" attribute, the Printer
+         MUST populate the "notify-xxx" attribute on the Subscription
+         Object according to the definition of the "notify-xxx"
+         attribute in a section 5.3.  For some attributes, the "notify-
+         xxx" is populated with the value of some other attribute, and
+         for others, the "notify-xxx" is NOT populated on the
+         Subscription object at all.
+
+   6. A Printer MUST create a Subscription Object for each Subscription
+      Template Attributes group in a request unless the Printer:
+
+      a) encounters some attributes in a Subscription Template
+         Attributes Group that require the Printer not to create the
+         Subscription Object OR
+
+      b) would create a Per-Job Subscription Object when it doesn't have
+         space for another Per-Job Subscription Object OR
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 16]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      c) would create a Per-Printer Subscription Object when it doesn't
+         have space for another Per-Printer Subscription Object.
+
+   7. A response MUST contain one Subscription Attributes Group for each
+      Subscription Template Attributes Group in the request (and in the
+      same order) whether the Printer creates a Subscription Object from
+      the Subscription Template Attributes Group or not.  However, the
+      attributes in each Subscription Attributes Group can be in any
+      order.
+
+   8. The Printer MUST populate each Subscription Attributes Group of
+      the response such that each contains:
+
+      a) the "notify-subscription-id" attribute (see section 5.4.1), if
+         and only if the Printer creates a Subscription Object.
+
+      b) the "notify-lease-duration" attribute (see section 5.3.8), if
+         and only if the Printer creates a Per-Printer Subscription
+         Object.  The value of this attribute is the value of the
+         Subscription Object's "notify-lease-duration" attribute.  This
+         value MAY be different from the client-supplied value (see
+         section 5.3.8).  If a client supplies this attribute in the
+         creation of a Per-Job Subscription Object, it MUST appear in
+         this group with the out-of-band value 'unsupported' to indicate
+         that the Printer doesn't support it in this context.
+
+      c) all of the unsupported Subscription Template Attributes from
+         step #2.  Note, they are not returned in the Unsupported
+         Attributes Group in order to separate the unsupported
+         attributes for each Subscription Object.
+
+      d) the "notify-status-code" attribute if the Printer does not
+         create the Subscription Object or if there are unsupported
+         attributes from step #2.  The possible values of the "notify-
+         status-code" attribute are shown below (see section 13 for more
+         details).  The Printer returns the first value in the list
+         below that describes the status.
+
+         'client-error-uri-scheme-not-supported':  the Subscription
+            Object was not created because the scheme of the "notify-
+            recipient-uri" attribute is not supported.  See section 13.1
+            for more details about this status code.  See step #3 in
+            this section for the case that causes this error, and the
+            resulting step #6a) that causes the Printer not to create
+            the Subscription Object.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 17]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         'client-error-attributes-or-values-not-supported':  the
+            Subscription Object was not created because the method of
+            the "notify-pull-method" attribute is not supported.  See
+            section 13.1 for more details about this status code.  See
+            step #3 in this section for the case that causes this error,
+            and the resulting step #6a) that causes the Printer not to
+            create the Subscription Object.
+
+         'client-error-too-many-subscriptions':  the Subscription
+            Object was not created because the Printer has no space for
+            additional Subscription Objects.  The client MAY try again
+            later.  See section 13.3 for more details about this status
+            code.  See steps #6b) and #6c) in this section for the cases
+            that causes this error.
+
+         'successful-ok-too-many-events':  the Subscription Object was
+            created without the "notify-events" values included in this
+            Subscription Attributes Group because the "notify-events"
+            attribute contains too many values.  See section 13.4 for
+            more details about this status code.  See step #2 in this
+            section and section 5.3.3 for the cases that cause this
+            status code.
+
+         'successful-ok-ignored-or-substituted-attributes':  the
+            Subscription Object was created but some supplied
+            Subscription Template Attributes are unsupported.  These
+            unsupported attributes are also in the Subscription
+            Attributes Group.  See section 13.5 for more details about
+            this status code.  See step #2 in this section for the cases
+            that cause this status code.
+
+   9. The Printer MUST validate all Subscription Template Attributes and
+      MUST return all unsupported attributes and values in the
+      corresponding Subscription Attributes Group of the response (see
+      step #2) unless it determines that it could not create additional
+      Subscription Objects because of condition #6b) or condition #6c).
+      Then, the Printer NEED NOT validate these additional Subscription
+      Template Attributes and the client MUST NOT expect to find
+      unsupported attributes from step #2 in such additional
+      Subscription Attribute Groups.
+
+5.3.  Subscription Template Attributes
+
+   This section contains the Subscription Template Attributes defined
+   for the Subscription and Printer objects.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 18]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 1 below shows the Subscription Template Attributes and has two
+   columns:
+
+   -  Attribute in Subscription Object: the name and attribute syntax of
+      each Subscription Object Attribute that is a Subscription Template
+      Attribute
+
+   -  Default and Supported Printer Attributes: the default attribute
+      and supported Printer attributes that are associated with the
+      attribute in column 1.
+
+   The "notify-recipient-uri" attribute is for use with Push Delivery
+   Methods.  The "notify-pull-method" attribute is for use with Pull
+   Delivery Methods.
+
+   For Push Delivery Methods, a Printer MUST support all attributes in
+   Table 1 below except for "notify-pull-method" and "notify-attributes"
+   (and "notify-pull-method-supported" and "notify-attributes-
+   supported").  For Pull Delivery Methods, a Printer MUST support all
+   attributes in Table 1 below except for "notify-recipient-uri" and
+   "notify-attributes" (and "notify-schemes-supported" and "notify-
+   attributes-supported").  If a Printer supports both Push and Pull
+   Delivery Methods, then it MUST support both "notify-recipient-uri"
+   and "notify-pull-method" attributes.
+
+   For Pull Delivery Methods, a client MUST supply "notify-recipient-
+   uri" and MAY omit any of the rest of the attributes in column 1 of
+   Table 1 in a Subscription Creation Request.  For Push Delivery
+   Methods, a client MUST supply "notify-pull-method" and MAY omit any
+   of the rest of the attributes in column 1 of Table 1 in a
+   Subscription Creation Request.  A client MUST NOT supply both
+   "notify-recipient-uri" and "notify-pull-method" attributes in the
+   same Subscription Creation Request.
+
+   Note:  The Default and Supported Printer attributes listed in column
+   2 of Table 1 do not have separate sections in this specification
+   defining their semantics.  Instead, the section for the corresponding
+   Subscription Object attribute (column 1 of Table 1) contains the
+   semantics of these Printer attributes.  This approach follows the
+   precedence of the Job Template attributes in section 4.2 of [RFC2911]
+   where the corresponding "xxx-default" and "xxx-supported" Printer
+   attributes are defined in the same section as the "xxx" Job
+   attribute.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 19]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 1 - Subscription Template Attributes
+
+   Attribute in Subscription     Default and Supported Printer
+   Object                        Attributes
+
+   notify-recipient-uri (uri) *  notify-schemes-supported  (1setOf
+                                 uriScheme)
+   notify-pull-method (type2     notify-pull-method-supported (1setOf
+   keyword) **                   type2 keyword)
+   notify-events (1setOf type2   notify-events-default (1setOf type2
+   keyword)                      keyword)
+                                 notify-events-supported (1setOf type2
+                                 keyword)
+                                 notify-max-events-supported
+                                 (integer(2:MAX))
+
+   notify-attributes (1setOf     notify-attributes-supported (1setOf
+   type2 keyword)                type2 keyword)
+   notify-user-data
+   (octetString(63))
+   notify-charset (charset)      charset-supported (1setOf charset)
+   notify-natural-language       generated-natural-language-supported
+   (naturalLanguage)             (1setOf naturalLanguage)
+   notify-lease-duration         notify-lease-duration-default
+   (integer(0:MAX))              (integer(0:67108863))
+                                 notify-lease-duration-supported
+                                 (1setOf (integer(0: 67108863) |
+                                 rangeOfInteger(0:67108863)))
+   notify-time-interval
+   (integer(0:MAX))
+
+   * "notify-recipient-uri" is for Push Delivery Methods only.
+   ** "notify-pull-method" is for Pull Delivery Methods only.
+
+5.3.1.  notify-recipient-uri (uri)
+
+   This attribute's value is a URL, which is a special case of a URI.
+   Its value consists of a scheme and an address.  The address specifies
+   the Notification Recipient and the scheme specifies the Push Delivery
+   Method for each Event Notification associated with this Subscription
+   Object.
+
+   If a Printer supports any Push Delivery Methods, a Printer MUST
+   support this attribute and return the value as supplied by the client
+   (no case conversion or other canonicalization) in any operation
+   response that includes this attribute.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 20]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   For a Push Delivery Method, a client MUST supply this attribute in a
+   Subscription Creation Operation.  Thus there is no need for a default
+   Printer attribute.
+
+   The URI scheme of the value of this attribute on a Subscription
+   object MUST be a value of the "notify-schemes-supported (1setOf
+   uriScheme)" Printer attribute (see section 5.3.1.1).  Note: According
+   to [RFC2396] the ":" terminates the scheme and so is not part of the
+   scheme.  Therefore, values of the "notify-schemes-supported" Printer
+   attribute do not include the ":" character.
+
+   If the client supplies an unsupported scheme in the value of this
+   attribute, then the Printer MUST NOT create the Subscription Object
+   and MUST return the "notify-status-code" attribute with the 'client-
+   error-uri-scheme-not-supported' value in the Subscription Attributes
+   Group in the response.
+
+5.3.1.1.  notify-schemes-supported  (1setOf uriScheme)
+
+   This attribute contains the URI schemes supported in the "notify-
+   recipient-uri" Subscription Template attribute.  See sections 5.1 and
+   5.2 for the behavior of "xxx-supported" Subscription Template Printer
+   attributes.
+
+5.3.2.  notify-pull-method (type2 keyword)
+
+   This attribute's value is a type2 keyword indicating which Pull
+   Delivery Method is to be used.
+
+   Since a Printer MUST support the 'ippget' Pull Delivery Method
+   [RFC3996] (see section 15), a Printer MUST support this attribute and
+   return the value as supplied by the client in any operation response
+   that includes this attribute.
+
+   For a Pull Delivery Method, a client MUST supply this attribute in a
+   Subscription Creation Operation.  Thus there is no need for a default
+   Printer attribute.
+
+   The keyword value of this attribute on a Subscription object MUST be
+   a value of the "notify-pull-method-supported (1setOf type2 keyword)"
+   Printer attribute.
+
+   If the client supplies an unsupported method in the value of this
+   attribute, then the Printer MUST NOT create the Subscription Object
+   and MUST return the "notify-status-code" attribute with the 'client-
+   error-attributes-or-values-not-supported' value in the Subscription
+   Attributes Group in the response.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 21]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+5.3.2.1.  notify-pull-method-supported (1setOf type2 keyword)
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-supported"
+   Subscription Template Printer attributes.
+
+5.3.3.  notify-events (1setOf type2 keyword)
+
+   This attribute contains a set of Subscribed Events.  When an Event
+   occurs and it "matches" a value of this attribute, the Printer
+   delivers an Event Notification using information in the Subscription
+   Object.  The details of "matching" are described subsection 5.3.3.5.
+
+   A Printer MUST support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in
+   Subscription Creation Operation, the Printer MUST populate this
+   attribute on the Subscription Object with its "notify-events-default"
+   attribute value.
+
+   Each keyword value of this attribute on a Subscription Object MUST be
+   a value of the  "notify-events-supported (1setOf type2 keyword)"
+   Printer attribute.
+
+   The number of values of this attribute MUST NOT exceed the value of
+   the "notify-max-events-supported" attribute.  A Printer MUST support
+   at least 2 values per Subscription Object.  If the number of values
+   supplied by a client in a Subscription Creation Operation exceeds the
+   value of this attribute, the Printer MUST treat extra values as
+   unsupported values and MUST use the value of 'successful-ok-too-
+   many-events' for the "notify-status-code" attribute in the
+   Subscription Attributes Group of the response.
+
+5.3.3.1.  notify-events-default (1setOf type2 keyword)
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-default"
+   Subscription Template Printer attributes.
+
+5.3.3.2.  notify-events-supported (1setOf type2 keyword)
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-supported"
+   Subscription Template Printer attributes.
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 22]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+5.3.3.3.  notify-max-events-supported (integer(2:MAX))
+
+   This attribute specified the maximum number of events that the
+   Printer supports for the "notify-events" Subscription Template
+   attribute.  See sections 5.1 and 5.2 for the behavior of "xxx-
+   supported" Subscription Template Printer attributes.
+
+5.3.3.4.  Standard Values for Subscribed Events
+
+   Each value of this attribute is a keyword and it specifies a
+   Subscribed Event that represents certain changes.  Some keywords
+   represent a subset of changes of another keyword, e.g., 'job-
+   completed' is an Event value which is a sub-value of 'job-state-
+   change'.  See section 5.3.3.5 for the case where this attribute
+   contains both a value and a sub-value.
+
+   The values in this section are divided into three categories: No
+   Events, Job Events and Printer Events.
+
+   A Printer MUST support the Events indicated as "REQUIRED" and MAY
+   support the Events indicated as "OPTIONAL".
+
+5.3.3.4.1.  No Events
+
+   The standard and only keyword value for No Events is:
+
+   'none':  REQUIRED - no Event Notifications for any Events.  As the
+      sole value of "notify-events-supported", this value means that the
+      Printer does not support the delivery of Event Notifications.  As
+      the sole value of "notify-events-default", this value means that a
+      client MUST specify the "notify-events" attribute in order for a
+      Subscription Creation Operation to succeed.  If the Printer
+      receives this value as the sole value of a Subscription Creation
+      Operation, it does not create a Subscription Object.  If a Printer
+      receives this value with other values of a Subscription Creation
+      Operation, the Printer MUST treat this value as an unsupported
+      value.
+
+5.3.3.4.2.  Subscribed Printer Events
+
+   The standard keyword values for Subscribed Printer Events are:
+
+   'printer-state-changed':  REQUIRED - the Printer changed state from
+      any state to any other state.  Specifically, the value of the
+      Printer's "printer-state", "printer-state-reasons" or "printer-
+      is-accepting-jobs" attributes changed.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 23]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      This Subscribed Event value has the following sub-values:
+      'printer-restarted' and 'printer-shutdown'.  A client can listen
+      for any of these sub-values if it doesn't want to listen to all
+      printer-state changes:
+
+         'printer-restarted':  OPTIONAL - when the printer is powered
+            up.
+
+         'printer-shutdown':  OPTIONAL - when the device is being
+            powered down.
+
+         'printer-stopped:  REQUIRED - when the printer stops printing,
+            i.e., the value of the "printer-state" Printer attribute
+            becomes 'stopped'.
+
+   'printer-config-changed':  OPTIONAL - when the configuration of a
+      Printer has changed, i.e., the value of the "printer-message-
+      from-operator" or any "configuration" Printer attribute has
+      changed.  A "configuration" Printer attribute is an attribute
+      which can change value because of some human interaction either
+      direct or indirect, and which is not covered by one of the other
+      Events in this section.  Examples of "configuration" Printer
+      attributes are any of the Job Template attributes, such as "xxx-
+      supported", "xxx-ready" and "xxx-default".  The client has to
+      perform a Get-Printer-Attributes to find out the new values of
+      these changed attributes.  This Event is useful for GUI clients
+      and drivers to update the available printer capabilities to the
+      user.
+
+      This Event value has the following sub-values: 'printer-media-
+      changed' and 'printer-finishings-changed'.  A client can listen
+      for any of these sub-values if it doesn't want to listen to all
+      printer-configuration changes:
+
+         'printer-media-changed':  OPTIONAL - when the media loaded on
+            a printer has been changed, i.e., the "media-ready"
+            attribute has changed.  This Event includes two cases: an
+            input tray that goes empty and an input tray that receives
+            additional media of the same type or of a different type.
+            The client must check the "media-ready" Printer attribute
+            (see [RFC2911] section 4.2.11) separately to find out what
+            changed.
+
+         'printer-finishings-changed':  OPTIONAL - when the finisher on
+            a printer has been changed, i.e., the "finishings-ready"
+            attribute has changed.  This Event includes two cases: a
+            finisher that goes empty and a finisher that is refilled
+            (even if it is not full).  The client must check the
+
+
+
+Herriot & Hastings          Standards Track                    [Page 24]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+            "finishings-ready" Printer attribute separately to find out
+            what changed.
+
+   'printer-queue-order-changed': OPTIONAL - the order of jobs in the
+      Printer's queue has changed, so that an application that is
+      monitoring the queue can perform a Get-Jobs operation to determine
+      the new order.  This Event does not include when a job enters the
+      queue (the 'job-created' Event covers that) and does not include
+      when a job leaves the queue (the 'job-completed' Event covers
+      that).
+
+5.3.3.4.3.  Subscribed Job Events
+
+   The standard keyword values for Subscribed Job Events are:
+
+   'job-state-changed':  REQUIRED - the job has changed from any state
+      to any other state.  Specifically, the Printer delivers this Event
+      whenever the value of the "job-state" attribute or "job-state-
+      reasons" attribute changes.  When a Job is removed from the Job
+      Retention or Job History phases (see [RFC2911] section 4.3.7.1),
+      no Event is generated.
+
+      This Event value has the following sub-values: 'job-created',
+      'job-completed' and 'job-stopped'.  A client can listen for any of
+      these sub-values if it doesn't want to listen to all 'job-state
+      changes'.
+
+      'job-created':  REQUIRED - the Printer has accepted a Job
+         Creation operation, a Restart-Job operation [RFC2911], or any
+         job operation that creates a Job object from an existing Job
+         object.  The Printer populates the job's "time-at-creation"
+         attribute value (see [RFC2911] section 4.3.14.1).  The Printer
+         puts the job in the 'pending', 'pending-held' or 'processing'
+         states.
+
+      'job-completed':  REQUIRED - the job has reached one of the
+         completed states, i.e., the value of the job's "job-state"
+         attribute has changed to: 'completed', 'aborted', or
+         'canceled'.  The Job's "time-at-completed" and "date-time-at-
+         completed" (if supported) attributes are set (see [RFC2911]
+         section 4.3.14).  When a Job completes, a Notification
+         Recipient MAY query the Job using the Get-Job-Attributes
+         operation.  To allow such a query, the Printer retains the Job
+         in the Job Retention and/or the Job History phases (see
+         [RFC2911] section 4.3.7.1) for a suitable amount of time that
+         depends on implementation and the Delivery Methods supported.
+         The Printer also delivers this Event when a Job is removed with
+         the Purge-Job operation (see [RFC2911] section 3.2.9).  In this
+
+
+
+Herriot & Hastings          Standards Track                    [Page 25]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         case, the Event Notification MUST report the 'job-state' as
+         'canceled' and the Job object is no longer present for query.
+
+      'job-stopped:  OPTIONAL - when the job stops printing, i.e.,
+         the value of the "job-state" Job attribute becomes
+         'processing-stopped'.
+
+   'job-config-changed':  OPTIONAL - when the configuration of a job has
+      changed, i.e., the value of the "job-message-from-operator" or any
+      of the "configuration" Job attributes have changed.  A
+      "configuration" Job attribute is an attribute that can change
+      value because of some human interaction either direct or indirect.
+      Examples of "configuration" Job attributes are any of the job
+      template attributes and the "job-name" attribute.  The client
+      performs a Get-Job-Attributes to find out the new values of the
+      changed attributes.  This Event is useful for GUI clients and
+      drivers to update the job information to the user.
+
+   'job-progress': OPTIONAL - when the Printer has completed Printing a
+      sheet.  See the separate [RFC3381] specification for additional
+      attributes that a Printer MAY deliver in an Event Notification
+      caused by this Event.  The "notify-time-interval" attribute
+      affects this Event by causing the Printer NOT to deliver an Event
+      Notification every time a 'job-progress' Events occurs.  See
+      section 5.3.9 for full details.
+
+5.3.3.5.  Rules for Matching of Subscribed Events
+
+   When an Event occurs, the Printer MUST find each Subscription object
+   whose "notify-events" attribute "matches" the Event.  The rules for
+   "matching" of Subscribed Events are described separately for Printer
+   Events and for Job Events.  This section also describes some special
+   cases.
+
+5.3.3.5.1.  Rules for Matching of Printer Events
+
+   Given that the Printer causes Printer Event E to occur, for each
+   Per-Job or Per-Printer Subscription S in the Printer, if E equals a
+   value of this attribute in S or E is a sub-value of a value of this
+   attribute in S, the Printer MUST generate an Event Notification.
+
+   Consider the example.  There are three Subscription Objects each with
+   the Subscribed Printer Event 'printer-state-changed'.  Subscription
+   Object A is a Per-Printer Subscription Object.  Subscription Object B
+   is a Per-Job Subscription Object for Job 1, and Subscription Object C
+   is a Per-Job Subscription Object for Job 2.  When the Printer enters
+   the 'stopped' state, the Printer delivers an Event Notification to
+   the Notification Recipients of Subscription Objects A, B, and C
+
+
+
+Herriot & Hastings          Standards Track                    [Page 26]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   because this is a Printer Event.  Note if Job 1 has already
+   completed, the Printer would not deliver an Event Notification for
+   its Subscription Object, even if Job 1 is retained in the Job
+   Retention and/or the Job History phases (see [RFC2911] section
+   4.3.7.1).
+
+5.3.3.5.2.  Rules for Matching of Job Events
+
+   Given that Job J causes Job Event E to occur:
+
+   1. For each Per-Printer Subscription S in the Printer, if E equals a
+      value of this attribute in S or E is a sub-value of a value of
+      this attribute in S, the Printer MUST generate an Event
+      Notification.
+
+   2. For each Per-Job Subscription S associated with Job J, if E equals
+      a value of this attribute in S or E is a sub-value of a value of
+      this attribute in S, the Printer MUST generate an Event
+      Notification.
+
+   3. For each Per-Job Subscription S that is NOT associated Job J, if E
+      equals a value of this attribute in S or E is a sub-value of a
+      value of this attribute in, the Printer MUST NOT generate an Event
+      Notification from S.
+
+   Consider the example: There are three Subscription Objects listening
+   for the Job Event 'job-completed'.  Subscription Object A is a Per-
+   Printer Subscription Object.  Subscription Object B is a Per-Job
+   Subscription Object for Job 1, and Subscription Object C is a Per-Job
+   Subscription Object for Job 2.  In addition, Per-Printer Subscription
+   Object D is listening for the Job Event 'job-state-changed'.  When
+   Job 1 completes, the Printer delivers an Event Notification to the
+   Notification Recipient of Subscription Object A (because it is Per-
+   Printer) and Subscription Object B because it is a Per-Job
+   Subscription Object associated with the Job generating the Event.
+   The Printer also delivers an Event Notification to the Notification
+   Recipient of Subscription Object D because 'job-completed' is a sub-
+   value of 'job-state-changed' - the value that Subscription Object D
+   is listening for.  The Printer does not deliver an Event Notification
+   to the Notification Recipients of Subscription Object C because it is
+   a Per-Job Subscription Object associated with some Job other than the
+   Job generating the Event.
+
+5.3.3.5.3.  Special Cases for Matching Rules
+
+   This section contains two rules for the special case where a single
+   Event produces multiple Event Notifications destined for the same
+   Notification Recipient.  These two rules clarify whether a Printer
+
+
+
+Herriot & Hastings          Standards Track                    [Page 27]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   should send multiple Event Notifications or consolidate them into a
+   single Event Notification.
+
+   If an Event matches Subscribed Events in two different Subscription
+   Objects and the Printer would deliver two identical Event
+   Notifications (except for the "notify-subscription-id" attribute) to
+   the same Notification Recipient using the same Delivery Method, the
+   Printer MUST deliver both Event Notifications.  That is, the Printer
+   MUST NOT try to consolidate seemingly identical Event Notifications
+   that occur in separate Subscription objects.  Incidentally, the
+   Printer MUST NOT reject Subscription Creation Operations that would
+   create this scenario.
+
+   Consider the example: At the time a Job completes, there are two
+   Per-Printer Subscription Objects A and B with the same Notification
+   Recipient R.  Subscription Object A has the Subscribed Job Event
+   'job-state-changed'.  Subscription Object B has the Subscribed Job
+   Event 'job-completed'.  Both Subscription Objects match the Event
+   'job-completed'.  The Printer delivers two Event Notifications to the
+   Notification Recipient R.  One with the value of  'job-state-changed'
+   for the "notify-subscribed-event" attribute and the other with the
+   value of  'job-completed' for the "notify-subscribed-event"
+   attribute.
+
+   If an Event matches two Subscribed Events in a single Subscription
+   object (e.g., a value and its sub-value), a Printer MAY deliver one
+   Event Notification for each matched value in the Subscription Object
+   or it MAY deliver only a single Event Notification.  The rules in
+   sections 5.3.3.5.1 and 5.3.3.5.2 are purposefully flexible about the
+   number of Event Notifications sent when Event E matches two or more
+   values in a Subscription Object.
+
+   Consider the example: At the time a Job completes, a Subscription
+   Object A has two Subscribed Job Events 'job-state-changed' and 'job-
+   completed'.  Both Subscribed Job Events match the Event 'job-
+   completed'.  The Printer delivers either one or two Event
+   Notifications to the Notification Recipient of Subscription Object A,
+   depending on implementation.  If it delivers two Event Notifications,
+   one has the value of  'job-state-changed' for the "notify-
+   subscribed-event" attribute, and the other has the value of 'job-
+   completed' for the "notify-subscribed-event" attribute.  If it
+   delivers one Event Notification, it has the value of either 'job-
+   state-changed' or 'job-completed' for the "notify-subscribed-event"
+   attribute, depending on implementation.  The algorithm for choosing
+   such a value is implementation dependent.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 28]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+5.3.4.  notify-attributes (1setOf type2 keyword)
+
+   This attribute contains a set of attribute names.  When a Printer
+   delivers a Machine Consumable Event Notification, it includes a fixed
+   set of attributes (see section 9.1).  If this attribute is present
+   and the Event Notification is Machine Consumable, the Printer also
+   includes the attributes specified by this attribute.
+
+   A Printer MAY support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in
+   Subscription Creation Operation or the Printer does not support this
+   attribute, the Subscription Object either (1) MAY contain the
+   "notify-attributes" attribute with a 'none' value or (2) NEED NOT
+   contain the attribute at all.  There is no "notify-attributes-
+   default" Printer attribute.
+
+   Each keyword value of this attribute on a Subscription Object MUST be
+   a value of the "notify-attributes-supported (1setOf type2 keyword)"
+   Printer attribute (see section 5.3.4.1).  The "notify-attributes-
+   supported" MAY contain any Printer attribute, Job attribute or
+   Subscription Object attribute that the Printer supports in an Event
+   Notification.  It MUST NOT contain any of the attributes in Section
+   9.1 that a Printer automatically puts in an Event Notification; it
+   would be redundant.  If a client supplies an attribute in Section
+   9.1, the Printer MUST treat it as an unsupported attribute value of
+   the "notify-attributes" attribute.
+
+   The following rules apply to each keyword value N of the "notify-
+   attributes" attribute: If the value N names:
+
+   a) a Subscription attribute, the Printer MUST use the attribute N in
+      the Subscription Object that is being used to generate the Event
+      Notification.
+
+   b) a Job attribute and the Printer is generating an Event
+      Notification from a Per-Job Subscription Object S, the Printer
+      MUST use the attribute N in the Job object associated with S.
+
+   c) a Job attribute and the Printer is generating an Event
+      Notification from a Per-Printer Subscription Object and the Event
+      is:
+
+      -  a Job Event, the Printer MUST use the attribute N in the Job
+         object that caused the Event.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 29]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      -  a Printer Event, the Printer MUST use the attribute N in the
+         active Job.
+
+   If a Printer supports this attribute and a Subscription Object
+   contains this attribute and the Delivery Method generates a Machine
+   Consumable Event Notification, the Printer MUST include in each Event
+   Notification:
+
+   a) the attributes specified in section 9.1 and
+
+   b) each attribute named by this attribute.
+
+   The Printer MUST NOT use this attribute to generate a Human
+   Consumable Event Notification.
+
+5.3.4.1.  notify-attributes-supported (1setOf type2 keyword)
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-supported"
+   Subscription Template Printer attributes.
+
+5.3.5.  notify-user-data (octetString(63))
+
+   This attribute contains opaque data that some Delivery Methods
+   include in each Machine Consumable Event Notification.  The opaque
+   data might contain, for example:
+
+   -  the identity of the Subscriber
+
+   -  a path or index to some Subscriber information
+
+   -  a key that identifies to the Notification Recipient the ultimate
+      recipient of the Event Notification
+
+   -  the id for a Notification Recipient that had previously registered
+      with an Instant Messaging Service
+
+   A Printer MUST support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in the
+   Subscription Creation Operation, the Subscription Object either (1)
+   MAY contain the "notify-user-data" attribute with a zero length value
+   or (2) NEED NOT contain the attribute at all.  There is no "notify-
+   user-data-default" Printer attribute.
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 30]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   There is no "notify-user-data-supported" Printer attribute.  Rather,
+   any octetString whose length does not exceed 63 octets is a supported
+   value.  If the length exceeds 63 octets, the Printer MUST treat it as
+   an unsupported value.
+
+5.3.6.  notify-charset (charset)
+
+   This attribute specifies the charset to be used in the Event
+   Notification content sent to the Notification Recipient, whether the
+   Event Notification content is Machine Consumable or Human Consumable.
+
+   A Printer MUST support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in
+   Subscription Creation Operation or supplies an unsupported value, the
+   Printer MUST populate this attribute in the Subscription Object with
+   the value of the "attributes-charset" operation attribute, which is a
+   REQUIRED attribute in all IPP requests (see [RFC2911]).  If the value
+   of the "attributes-charset" attribute is unsupported, the Printer
+   MUST populate this attribute in the Subscription Object with the
+   value of the Printer's "charset-configured" attribute.  There is no
+   "notify-charset-default" Printer attribute.
+
+   The value of this attribute on a Subscription Object MUST be a value
+   of the "charset-supported (1setOf charset)" Printer attribute.
+
+5.3.7.  notify-natural-language (naturalLanguage)
+
+   This attribute specifies the natural language to be used in any human
+   consumable text in the Event Notification content sent to the
+   Notification Recipient, whether the Event Notification content is
+   Machine Consumable or Human Consumable.
+
+   A Printer MUST support this attribute.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in
+   Subscription Creation Operation or supplies an unsupported value, the
+   Printer MUST populate this attribute in the Subscription Object with
+   the value of the "attributes-natural-language" operation attribute,
+   which is a REQUIRED attribute in all IPP requests (see [RFC2911]
+   section 3.1.4).  If the value of the "attributes-natural-language"
+   attribute is unsupported, the Printer MUST populate this attribute in
+   the Subscription Object with the value of the Printer's "natural-
+   language-configured" attribute (see [RFC2911] section 4.4.19).  There
+   is no "notify-natural-language-default" Printer attribute.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 31]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   The value of this attribute on a Subscription Object MUST be a value
+   of the "generated-natural-language-supported (1setOf type2
+   naturalLanguage)" Printer attribute (see [RFC2911] section 4.4.20).
+
+5.3.8.  notify-lease-duration (integer(0:67108863))
+
+   This attribute specifies the duration of the lease (in seconds)
+   associated with the Per-Printer Subscription Object at the time the
+   Subscription Object was created or the lease was renewed.  The
+   duration of the lease is infinite if the value is 0, i.e., the lease
+   never expires.  See section 5.4.3 on "notify-lease-expiration-time
+   (integer(0:MAX))" for more details.
+
+   This attribute is not present on a Per-Job Subscription Object
+   because the Subscription Object lasts exactly as long as the
+   associated Job object.  See discussion of the 'job-completed' event
+   in section 5.3.3.4.3 about retention of the Job object after
+   completion.
+
+   A Printer MUST support this attribute.
+
+   For a Subscription Object Creation operation of a Per-Job
+   Subscription Object, the client MUST NOT supply this attribute.  If
+   the client does supply this attribute, the Printer MUST treat it as
+   an unsupported attribute.
+
+   For a Subscription Creation Operation of a Per-Printer Subscription
+   Object or a Renew-Subscription operation, a client MAY supply this
+   attribute.  If the client does not supply this attribute, the Printer
+   MUST populate this attribute with its "notify-lease-duration-default"
+   (0:67108863) attribute value.  If the client supplies this attribute
+   with an unsupported value, the Printer MUST populate this attribute
+   with a supported value, and this value SHOULD be as close as possible
+   to the value requested by the client.  Note: this rule implies that a
+   Printer doesn't assign the value of 0 (infinite) unless the client
+   requests it.
+
+   After the Printer has populated this attribute with a supported
+   value, the value represents the "granted duration" of the lease in
+   seconds and the Printer updates the value of the Subscription
+   Object's "notify-lease-expiration-time" attribute as specified in
+   section 5.4.3.
+
+   The value of this attribute on a Subscription Object MUST be a value
+   of the "notify-lease-duration-supported" (1setOf (integer(0:67108863)
+   | rangeOfInteger(0:67108863))) Printer attribute.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 32]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   A Printer MAY require authentication in order to return the value of
+   0 (the lease never expires) as one of the values of "notify-lease-
+   duration-supported", and to allow 0 as a value of the "notify-lease-
+   duration" attribute.
+
+   Note:  The maximum value 67,108,863 is 2 raised to the 26 power minus
+   1 and is about 2 years in seconds.  The value is considerably less
+   than MAX so that there is virtually no chance of an overflow when the
+   Printer adds it to the Printer's "printer-up-time" attribute value
+   (see [RFC2911] section 4.4.29) to produce the "notify-lease-
+   expiration-time" Subscription Description attribute value (see
+   section 5.4.3).
+
+5.3.8.1.  notify-lease-duration-default (integer(0:67108863))
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-default"
+   Subscription Template Printer attributes.
+
+5.3.8.2. notify-lease-duration-supported (1setOf (integer(0: 67108863) |
+         rangeOfInteger(0:67108863)))
+
+   See sections 5.1 and 5.2 for the behavior of "xxx-supported"
+   Subscription Template Printer attributes.
+
+5.3.9.  notify-time-interval (integer(0:MAX))
+
+   The 'job-progress' Event occurs each time that a Printer completes a
+   sheet.  Some Notification Recipients do not want to receive an Event
+   Notification every time this Event occurs.  This attribute allows a
+   Subscribing Client to request how often it wants to receive Event
+   Notifications for 'job-progress' Events.  The value of this attribute
+   MAY be any nonnegative integer (0,MAX) indicating the minimum number
+   of seconds between 'job-progress' Event Notifications.
+
+   The Printer MUST support this attribute if and only if the Printer
+   supports the 'job-progress' Event.
+
+   A client MAY supply this attribute in a Subscription Creation
+   Operation.  If the client does not supply this attribute in the
+   Subscription Creation Operation, the Subscription Object either (1)
+   MAY contain the "notify-time-interval" attribute with a '0' value or
+   (2) NEED NOT contain this attribute at all.  There is no "notify-
+   time-interval-default" Printer attribute.
+
+   There is no "notify-time-interval-supported" Printer attribute.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 33]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   If the 'job-progress' Event occurs and a Subscription Object contains
+   the 'job-progress' Event as a value of the 'notify-events' attribute,
+   there are two cases to consider:
+
+   1. This attribute is not present on the Subscription Object or has
+      the value of 0.  The Printer MUST generate and deliver an Event
+      Notification (as is the case with other Events).
+
+   2. This attribute is present with a nonzero value of N:
+
+      a) If the Printer has not sent an Event Notification for the
+         'job-progress' Event for the associated Subscription Object
+         within the past N seconds, the Printer MUST deliver an Event
+         Notification for the Event that just occurred.  Note when the
+         Printer completes the first page of a Job, this rule implies
+         that the Printer delivers an Event Notification for a Per-Job
+         Subscription Object.
+
+      b) Otherwise, the Printer MUST NOT generate or deliver an Event
+         Notification for the associated Subscription Object.  The
+         Printer MUST NOT increase the value of the "notify-sequence-
+         number" Subscription Object attribute (i.e., the sequence of
+         values of the "notify-sequence-number" attribute counts the
+         Event Notifications that the Printer sent and not the Events
+         that do not cause an Event Notification to be sent).
+
+   It is RECOMMENDED that a Subscribing Client use this attribute when
+   it subscribes to the 'job-progress' Event, and that the value be
+   sufficiently large to limit the frequency with which the Printer
+   delivers Event Notifications requests.
+
+   This attribute MUST NOT effect any Events other than 'job-progress'.
+
+5.4.  Subscription Description Attributes
+
+   Subscription Description Attributes are those attributes that a
+   Printer adds to a Subscription Object at the time of its creation.
+
+   A Printer MUST support all attributes in this Table 2.
+
+   A client MUST NOT supply the attributes in Table 2 in a Subscription
+   Template Attributes Group of a Subscription Creation Operation.
+   There are no corresponding default or supported attributes.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 34]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 2 - Subscription Description Attributes
+
+      Subscription Object attributes:
+
+      notify-subscription-id (integer(1:MAX))
+      notify-sequence-number (integer(0:MAX))
+      notify-lease-expiration-time (integer(0:MAX))
+      notify-printer-up-time (integer(1:MAX))
+      notify-printer-uri (uri)
+      notify-job-id (integer(1:MAX))
+      notify-subscriber-user-name (name(MAX))
+
+5.4.1.  notify-subscription-id  (integer (1:MAX))
+
+   This attribute identifies a Subscription Object instance with a
+   number that is unique within the context of the Printer.  The Printer
+   generates this value at the time it creates the Subscription Object.
+
+   A Printer MUST support this attribute.
+
+   The Printer MAY assign the value of this attribute sequentially as it
+   creates Subscription Objects.  However, if there is no security on
+   Subscription objects, sequential assignment exposes the system to a
+   passive traffic monitoring threat.
+
+   The Printer SHOULD avoid re-using recent values of this attribute
+   during continuous operation of the Printer as well as across power
+   cycles.  Then a Subscribing Client is unlikely to find that a stale
+   reference accesses a new Subscription Object.
+
+   The 0 value is not permitted in order to allow for compatibility with
+   "job-id" and with MIB table index values, which are recommended not
+   to be 0.
+
+5.4.2.  notify-sequence-number (integer (0:MAX))
+
+   The value of this attribute indicates the number of times that the
+   Printer has generated and attempted to deliver an Event Notification
+   for this Subscription object.  When an Event Notification contains
+   this attribute, the Notification Recipient can determine whether it
+   missed some Event Notifications (i.e., numbers skipped) or received
+   duplicates (i.e., same number twice).
+
+   A Printer MUST support this attribute.
+
+   When the Printer creates a Subscription Object, it MUST populate this
+   attribute with a value of 0.  This value indicates that the Printer
+   has not sent any Event Notifications for this Subscription Object.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 35]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Each time the Printer delivers a newly generated Event Notification,
+   it MUST increase the value of this attribute by 1.  For some Delivery
+   Methods, the Printer MUST include this attribute in each Event
+   Notification, and the value MUST be the value after it is increased
+   by 1.  That is, the value of this attribute in the first Event
+   Notification after Subscription object creation MUST be 1, the second
+   MUST be 2, etc.  If a Delivery Method is defined such that the
+   Notification Recipient returns a response, the Printer can re-try
+   delivering an Event Notification a certain number of times with the
+   same sequence number when the Notification Recipient fails to return
+   a response.
+
+   If a Subscription Object lasts long enough to reach the value of MAX,
+   its next value MUST be 0, i.e., it wraps.
+
+5.4.3.  notify-lease-expiration-time (integer(0:MAX))
+
+   This attribute specifies the time in the future when the lease on the
+   Per-Printer Subscription Object will expire, i.e., the "printer-up-
+   time" value at which the lease will expire.  If the value is 0, the
+   lease never expires.
+
+   A Printer MUST support this attribute.
+
+   When the Printer creates a Per-Job Subscription Object, this
+   attribute MUST NOT be present - the Subscription Object lasts exactly
+   as long as the associated Job object.  See also the discussion of the
+   'job-completed' event in section 5.3.3.4.3 about retention of the Job
+   object after completion so that a Notification Recipient can query
+   the Job object after receiving the 'job-completed' Event
+   Notification.
+
+   When the Printer creates a Per-Printer Subscription Object, it
+   populates this attribute with a value that is the sum of the values
+   of the Printer's "printer-up-time" attribute and the Subscription
+   Object's "notify-lease-duration" attribute with the following
+   exception.  If the value of the Subscription Object's "notify-lease-
+   duration" attribute is 0 (i.e., no expiration time), then the value
+   of this attribute MUST be set to 0 (i.e., no expiration time).
+
+   When the Printer powers up, it MUST populate this attribute in each
+   persistent Subscription Object with a value using the algorithm in
+   the previous paragraph.
+
+   When the "printer-up-time" equals the value of this attribute, the
+   Printer MUST delete the Subscription Object.  A client can extend a
+   lease of a Per-Printer Subscription Object with the Renew-
+   Subscription operation (see section 11.2.6).
+
+
+
+Herriot & Hastings          Standards Track                    [Page 36]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Note: In order to compute the number of seconds remaining in a lease
+   for a Per-Printer Subscription Object, a client can subtract the
+   Subscription's "notify-printer-up-time" attribute (see section 5.4.4)
+   from the Subscription's "notify-lease-expiration-time" attribute.
+
+5.4.4.  notify-printer-up-time (integer(1:MAX))
+
+   This attribute is an alias for the Printer's "printer-up-time"
+   attribute " (see [RFC2911] section 4.4.29).  In other words, when
+   this attribute is queried with the Get-Subscriptions or Get-
+   Subscription-Attributes operations (see sections 11.2.4 and 11.2.5),
+   the value returned is the current value of the Printer's "printer-
+   up-time" attribute, rather than the time at which the Subscription
+   Object was created.
+
+   A Printer MUST support this attribute.
+
+   When the Printer creates a Per-Job Subscription Object, this
+   attribute MUST NOT be present.  When the Printer creates a Per-
+   Printer Subscription Object, this attribute MUST be present.
+
+   Note: this attribute exists in a Per-Printer Subscription Object so
+   that a client using the Get-Subscription-Attributes or Get-
+   Subscription operations can convert the Per-Printer Subscription's
+   "notify-lease-expiration-time" attribute to wall clock time with one
+   request.  If the value of the "notify-lease-expiration-time"
+   attribute is not 0 (i.e., no expiration time), then the difference
+   between the "notify-lease-expiration-time" attribute and the
+   "notify-printer-up-time" is the remaining number of seconds on the
+   lease from the current time.
+
+5.4.5.  notify-printer-uri (uri)
+
+   This attribute identifies the Printer object that created this
+   Subscription Object.
+
+   A Printer MUST support this attribute.
+
+   During a Subscription Creation Operation, the Printer MUST populate
+   this attribute with the value of the "printer-uri" operation
+   attribute in the request.  From the Printer URI, the client can, for
+   example, determine what security scheme was used.
+
+5.4.6.  notify-job-id (integer(1:MAX))
+
+   This attribute specifies whether the containing Subscription Object
+   is a Per-Job or Per-Printer Subscription Object, and for Per-Job
+   Subscription Objects, it specifies the associated Job.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 37]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   A Printer MUST support this attribute.
+
+   If this attribute is not present, the Subscription Object MUST be a
+   Per-Printer Subscription.  If this attribute is present, the
+   Subscription Object MUST be a Per-Job Subscription Object and this
+   attribute MUST identify the Job with which the Subscription Object is
+   associated.
+
+   Note: This attribute could be useful to a Notification Recipient that
+   receives an Event Notification generated from a Per-Job Subscription
+   Object and caused by a Printer Event.  The Event Notification gives
+   access to the Printer and the Subscription Object.  The Event
+   Notification gives access to the associated Job only via this
+   attribute.  See discussion of the 'job-completed' event in section
+   5.3.3.4.3 about retention of the Job object after completion so that
+   a Notification Recipient can query the Job object after receiving the
+   'job-completed' Event Notification.
+
+5.4.7.  notify-subscriber-user-name (name(MAX))
+
+   This attribute contains the name of the user who performed the
+   Subscription Creation Operation.
+
+   A Printer MUST support this attribute.
+
+   The Printer MUST populates this attribute with the most authenticated
+   printable name that it can obtain from the authentication service
+   over which the Subscription Creation Operation was received.  The
+   Printer uses the same mechanism for determining the value of this
+   attribute as it does for a Job's "job-originating-user-name" (see
+   [RFC2911] section 4.3.6).
+
+   Note:  To help with authentication, a Subscription Object may have
+   additional private attributes about the user, e.g., a credential of a
+   principal.  Such private attributes are implementation-dependent and
+   not defined in this document.
+
+6.  Printer Description Attributes Related to Notification
+
+   This section defines the Printer Description attributes that are
+   related to Notification.  Table 3 lists the Printer Description
+   attributes, indicates the Printer support required for conformance,
+   and whether or not the attribute is READ-ONLY (see section 3.1):
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 38]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 3 - Printer Description Attributes Associated with Notification
+
+   Printer object attributes:                   REQUIRED     READ-ONLY
+
+   printer-state-change-time (integer(1:MAX))   No           Yes
+   printer-state-change-date-time (dateTime)    No           Yes
+
+6.1.  printer-state-change-time (integer(1:MAX))
+
+   This OPTIONAL attribute records the most recent time at which the
+   'printer-state-changed' Printer Event occurred whether or not any
+   Subscription objects were listening for this event.  This attribute
+   helps a client or operator to determine how long the Printer has been
+   in its current state.
+
+   A Printer MAY support this attribute and if so, the attribute MUST be
+   READ-ONLY.
+
+   On power-up, the Printer MUST populate this attribute with the value
+   of its "printer-up-time" attribute, so that it always has a value.
+   Whenever the 'printer-state-changed' Printer Event occurs, the
+   Printer MUST update this attribute with the value of the Printer's
+   "printer-up-time" attribute.
+
+6.2.  printer-state-change-date-time (dateTime)
+
+   This OPTIONAL attribute records the most recent time at which the
+   'printer-state-changed' Printer Event occurred whether or not there
+   were any Subscription Objects listening for this event.  This
+   attribute helps a client or operator to determine how long the
+   Printer has been in its current state.
+
+   A Printer MAY support this attribute and if so, the attribute MUST be
+   READ-ONLY.
+
+   On power-up, the Printer MUST populate this attribute with the value
+   of its "printer-current-time" attribute, so that it always has a
+   value (see [RFC2911] section 4.4.30 on "printer-current-time").
+   Whenever the 'printer-state-changed' Printer Event occurs, the
+   Printer MUST update this attribute with the value of the Printer's
+   "printer-current-time" attribute.
+
+7.  New Values for Existing Printer Description Attributes
+
+   This section contains those attributes for which additional values
+   are added.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 39]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+7.1.  operations-supported (1setOf type2 enum)
+
+   The following "operation-id" values are added in order to support the
+   new operations defined in this document:
+
+   Table 4 - Operation-id assignments
+
+   Value       Operation Name
+
+   0x0016      Create-Printer-Subscriptions
+   0x0017      Create-Job-Subscriptions
+   0x0018      Get-Subscription-Attributes
+   0x0019      Get-Subscriptions
+   0x001A      Renew-Subscription
+   0x001B      Cancel-Subscription
+
+8.  Attributes Only in Event Notifications
+
+   This section contains those attributes that exist only in Event
+   Notifications and do not exist in any objects.
+
+8.1.  notify-subscribed-event (type2 keyword)
+
+   This attribute indicates the Subscribed Event that caused the Printer
+   to deliver this Event Notification.  This attribute exists only in
+   Event Notifications.
+
+   This attribute MUST contain one of the values of the "notify-events"
+   attribute in the Subscription Object, i.e., one of the Subscribed
+   Event values.  Its value is the Subscribed Event that "matches" the
+   Event that caused the Printer to deliver this Event Notification.
+   This Subscribed Event value may be identical to the Event or the
+   Event may be a sub-value of the Subscribed Event.  For example, the
+   'job-completed' Event (which is a sub-event of the 'job-state-
+   changed' event) would cause the Printer to deliver an Event
+   Notification for either the 'job-completed' or 'job-state-changed'
+   Subscribed Events and to deliver the 'job-completed' or 'job-state-
+   changed' value for this attribute, respectively.  See section 5.3.3.5
+   for the "matching" rules of Subscribed Events and for additional
+   examples.
+
+   The Delivery Method Document specifies whether the Printer includes
+   the value of this attribute in an Event Notification.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 40]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+8.2.  notify-text (text(MAX))
+
+   This attribute contains a Human Consumable text message (see section
+   9.2).  This message describes the Event and is encoded as plain text,
+   i.e., 'text/plain' with the charset specified by Subscription
+   Object's "notify-charset" attribute.
+
+   Note: this attribute contains a text message only and must not
+   contain any encoding information, such as 'text/plain'.  The
+   'text/plain' encoding is implicit and thus the charset must be
+   specified by an alternate mechanism, namely the "notify-charset"
+   attribute.
+
+   The Delivery Method Document specifies whether the Printer includes
+   this attribute in an Event Notification.
+
+9.  Event Notification Content
+
+   This section defines the Event Notification content that the Printer
+   delivers when an Event occurs.
+
+   When an Event occurs, the Printer MUST find each Subscription object
+   whose "notify-events" attribute "matches" the Event.  See section
+   5.3.3.5 for details on "matching".  For each matched Subscription
+   Object, the Printer MUST create an Event Notification with the
+   content and format that the Delivery Method Document specifies.  The
+   content contains the value of attributes specified by the Delivery
+   Method Document.  The Printer obtains the values immediately after
+   the Event occurs.  For example, if the "printer-state" attribute
+   changes from 'idle' to 'processing', the Event 'printer-state-
+   changed' occurs and the Printer puts various attributes into the
+   Event Notification, including "printer-up-time" and "printer-state"
+   with the values that they have immediately after the Event occurs,
+   i.e., the value of  "printer-state" is 'processing'.
+
+   Event Notification Ordering:
+
+   When a Printer delivers Event Notifications, the Event Notifications
+   from any given Subscription Object MUST be in time stamp order, i.e.,
+   in order of increasing "printer-up-time" attribute value in the Event
+   Notification (see Table 5).  These Event Notifications MAY be
+   interleaved with those from other Subscription Objects, as long as
+   those others are also in time stamp order.  The Printer MUST observe
+   these ordering requirements whether delivering multiple pending
+   Events as multiple separate Event Notifications or together in a
+   single Compound Event Notification.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 41]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   If a Subscribing Client wants the Printer to deliver certain Event
+   Notifications in time stamp order, the Subscribing Client uses a
+   single Subscription Object.  Even so, depending on the underlying
+   transport, the actual order that a Notification Recipient receives
+   separate Event Notifications may differ from the order sent by the
+   Printer (e.g., email).
+
+   Example:  Consider two Per-Printer Subscription Objects: SO1 and SO2.
+   SO1 requests 'job-state-changed' events and SO2 requests 'printer-
+   state-changed' events.  The number in parens is the time stamp.  The
+   following Event Notification sequences are the only ones that conform
+   to the ordering requirements for the Printer to deliver the Event
+   Notifications:
+
+      (a) SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO1:
+      'job-completed' (1009), SO2: 'printer-stopped' (1005)
+
+      (b) SO1: 'job-created' (1000), SO1: 'job-stopped' (1005), SO2:
+      'printer-stopped' (1005), SO1: 'job-completed' (1009)
+
+      (c) SO1: 'job-created' (1000), SO2: 'printer-stopped' (1005), SO1:
+      'job-stopped' (1005), SO1: 'job-completed' (1009)
+
+      (d) SO2: 'printer-stopped (1005), SO1: 'job-created' (1000), SO1:
+      'job-stopped' (1005), SO1: 'job-completed' (1009)
+
+   Examples (b) and (c) are interleaved; examples (a) and (d) are not
+   interleaved and are not appropriate for some Delivery Methods.
+
+   If two different Events occur simultaneously, or nearly so (e.g.,
+   "printer-up-time" has the same value for both), the Printer MUST
+   create a separate Event Notification for each Event, even if the
+   associated Subscription Object is the same for both Events.  However,
+   the Printer MAY combine these distinct Event Notifications into a
+   single Compound Event Notification if the Delivery Method supports
+   Compound Event Notifications.  For example, suppose that two nearly-
+   simultaneously Events represent two successive 'printer-state-
+   changed' Events, one from 'idle' to 'processing' and another from
+   'processing' to 'stopped'.  These two Events have the same name but
+   are different instances of the Event.  Then the Printer MUST create a
+   separate Event Notification for each Event and SHOULD accurately
+   report the "printer-state" of the first Event as 'processing' and the
+   second Event as 'stopped'.
+
+   If a Subscription Object contains more than one Subscribed Event, and
+   several Events occur in quick succession each matching a different
+   Subscribed Event in the Subscription Object, the Printer MUST NOT
+   generate a single Event Notification from several of these Events,
+
+
+
+Herriot & Hastings          Standards Track                    [Page 42]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   but MAY combine distinct Event Notifications into a single Compound
+   Event Notification if the Delivery Method supports Compound Event
+   Notifications.
+
+   After the Printer has created the Event Notification, the Printer
+   delivers it via either a:
+
+      Push Delivery Method: The Printer delivers the Event Notification
+      shortly after an Event occurs.  For some Push Delivery Methods,
+      the Notification Recipient MUST deliver a response; for others it
+      MUST NOT deliver a response.
+
+      Pull Delivery Method: The Printer saves Event Notifications for
+      some Event Life and expects the Notification Recipient to request
+      Event Notifications.  The Printer returns the Event Notifications
+      in a response to such a request.
+
+   If an error that meets the following conditions occurs, the Printer
+   MUST cancel the Subscription Object.
+
+   a) the error occurs during the delivering of an Event Notification
+      generated from Subscription Object S AND
+
+   b) the error would continue to occur every time the Printer delivers
+      an Event Notification generated from Subscription Object S in the
+      future.
+
+   For example, if the address of the "notify-recipient-uri" of
+   Subscription Object A references a non-existent target and the
+   Printer determines this fact, it MUST delete Subscription Object A.
+
+   The next two sections describe the values that a Printer delivers in
+   the content of Machine Consumable and Human Consumable Event
+   Notifications, respectively.
+
+   The tables in the sub-sections of this section contain the following
+   columns:
+
+   a) Source Value: the name of the attribute that supplies the value
+      for the Event Notification.  Asterisks in this field refer to a
+      note below the table.
+
+   b) Delivers: if the Printer supports the value (column 1) on the
+      Source Object (column 3) the Delivery Method MUST specify:
+
+         MUST: that the Printer MUST deliver the value.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 43]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         SHOULD: either that the Printer MUST deliver the value or that
+         the value is incompatible with the Delivery Method.
+
+         MAY: that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT,
+         or NEED NOT deliver the value.  The Delivery Method specifies
+         the level of conformance for the Printer.
+
+   c) Source Object: the object from which the source value comes.  If
+      the object is "Event Notification", the Printer fabricates the
+      value when it delivers the Event Notification.  See section 8.
+
+9.1.  Content of Machine Consumable Event Notifications
+
+   This section defines the attributes that a Delivery Method MUST
+   mention in a Delivery Method Document when specifying the Machine
+   Consumable Event Notification's contents.
+
+   This document does not define the order of attributes in Event
+   Notifications.  However, Delivery Method Documents MAY define the
+   order of some or all of the attributes.
+
+   A Delivery Method Document MUST specify additional attributes (if
+   any) that a Printer implementation delivers in a Machine Consumable
+   Event Notification.
+
+   Notification Recipients MUST be able to accept Event Notifications
+   containing attributes they do not recognize.  What a Notification
+   Recipient does with an unrecognized attribute is implementation-
+   dependent.  Notification Recipients MAY attempt to display
+   unrecognized attributes anyway or MAY ignore them.
+
+   The next three sections define the attributes in Event Notification
+   Contents that are:
+
+      1. for all Events
+
+      2. for Job Events only
+
+      3. for Printer Events only
+
+9.1.1.  Event Notification Content Common to All Events
+
+   This section lists the attributes that a Delivery Method Document
+   MUST specify for all Events.
+
+   Table 5 lists potential values in each Event Notification.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 44]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 5 - Attributes in Event Notification Content
+
+   Source Value                               Delivers   Source Object
+
+   notify-subscription-id (integer(1:MAX))    MUST       Subscription
+   notify-printer-uri (uri)                   MUST       Subscription
+   notify-subscribed-event (type2 keyword)    MUST       Event
+                                                         Notification
+   printer-up-time (integer(MIN:MAX))         MUST       Printer
+   printer-current-time (dateTime) *          MUST       Printer
+   notify-sequence-number (integer (0:MAX))   SHOULD     Subscription
+   notify-charset (charset)                   SHOULD     Subscription
+   notify-natural-language (naturalLanguage)  SHOULD     Subscription
+   notify-user-data (octetString(63)) **      SHOULD     Subscription
+   notify-text (text)                         SHOULD     Event
+                                                         Notification
+   attributes from the "notify-attributes"    MAY        Printer
+   attribute ***
+   attributes from the "notify-attributes"    MAY        Job
+   attribute ***
+   attributes from the "notify-attributes"    MAY        Subscription
+   attribute ***
+
+   *A Printer MUST deliver this value only if and only if it supports
+   the Printer's "printer-current-time" attribute.
+
+   ** If the Subscription Object does not contain a "notify-user-data"
+   attribute and the Delivery Method Document REQUIRES the Printer to
+   deliver the "notify-user-data" source value in the Event
+   Notification, the Printer MUST deliver an octet-string of length 0.
+
+   *** The last three rows represent additional attributes that a client
+   MAY request via the  "notify-attributes" attribute.  A Printer MAY
+   support the "notify-attributes" attribute.  The Delivery Method MUST
+   say that the Printer MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, or NEED
+   NOT support the "notify-attributes" attribute and specific values of
+   this attribute.  The Delivery Method MAY say that support for the
+   "notify-attributes" is conditioned on support of the attribute by the
+   Printer or it MAY say that Printer MUST support the "notify-
+   attributes" attribute if the Printer supports the Delivery Method.
+
+9.1.2.  Additional Event Notification Content for Job Events
+
+   This section lists the additional attributes that a Delivery Method
+   Document MUST specify for Job Events.  See Table 6.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 45]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 6 - Additional Event Notification Content for Job Events
+
+   Source Value                                  Delivers  Source
+                                                            Object
+
+   job-id (integer(1:MAX))                       MUST      Job
+   job-state (type1 enum)                        MUST      Job
+   job-state-reasons (1setOf type2 keyword)      MUST      Job
+   job-impressions-completed (integer(0:MAX)) *  MUST      Job
+
+   *  The Printer MUST deliver the "job-impressions-completed" attribute
+   in an Event Notification only for the combinations of Events and
+   Subscribed Events shown in Table 7.
+
+   Table 7 - Combinations of Events and Subscribed Events for "job-
+   impressions-completed"
+
+   Job Event              Subscribed Job Event
+
+   'job-progress'         'job-progress'
+   'job-completed'        'job-completed'
+   'job-completed'        'job-state-changed'
+
+9.1.3.  Additional Event Notification Content for Printer Events
+
+   This section lists the additional attributes that a Delivery Method
+   Document MUST specify for Printer Events.  See Table 8.
+
+   Table 8 - Additional Event Notification Content for Printer Events
+
+   Source Value                             Delivers   Source Object
+
+   printer-state (type1 enum)               MUST       Printer
+   printer-state-reasons (1setOf type2      MUST       Printer
+   keyword)
+   printer-is-accepting-jobs (boolean)      MUST       Printer
+
+9.2.  Content of Human Consumable Event Notification
+
+   This section defines the information that a Delivery Method MUST
+   mention in a Delivery Method Document when specifying the Human
+   Consumable Event Notifications contents or the value of the "notify-
+   text" attribute.
+
+   Such a Delivery Method MUST specify the following information and a
+   Printer SHOULD deliver it:
+
+   a) the Printer name (see Table 9)
+
+
+
+Herriot & Hastings          Standards Track                    [Page 46]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   b) the time of the Event (see Table 11)
+
+   c) for Printer Events only:
+
+      i) the Event (see Table 10) and/or Printer state information (see
+         Table 14)
+
+   d) for Job Events only:
+
+      i) the job identity (see Table 12)
+
+      ii) the Event (see Table 10) and/or Job state information (see
+          Table 13)
+
+   The subsections of this section specify the attributes that a Printer
+   MUST use to obtain this information.
+
+   A Delivery Method Document MUST specify additional information (if
+   any) that a Printer implementation delivers in a Human Consumable
+   Event Notification or in the "notify-text" attribute.
+
+   A client MUST NOT request additional attributes via the "notify-
+   attributes" attribute because this attribute works only for Machine
+   Consumable Event Notifications.
+
+   Notification Recipients MUST NOT expect to be able to parse the Human
+   Consumable Event Notification contents or the value of the "notify-
+   text" attribute.
+
+   The next three sections define the attributes in Event Notification
+   Contents that are:
+
+      a) for all Events
+      b) for Job Events only
+      c) for Printer Events only
+
+9.2.1.  Event Notification Content Common to All Events
+
+   This section lists the source of the information that a Delivery
+   Method MUST specify for all Events.
+
+   There is a separate table for each piece of information.  Each row in
+   the table represents a source value for the information and the
+   values are listed in order of preference, with the first one being
+   the preferred one.  An implementation SHOULD use the source value
+   from the earliest row in each table.  It MAY use the source value
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 47]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   from another row instead, or it MAY combine the source values from
+   several rows.  An implementation is free to determine the best way to
+   present this information.
+
+   In all tables of this section, all rows contain a "MAY" in order to
+   state that the Delivery Method specifies the conformance.
+
+   Table 9 lists the source of the information for the Printer Name.
+   The "printer-name" is more user-friendly unless the Notification
+   Recipient is in a place where the Printer name is not meaningful.
+   For example, an implementation could have the intelligence to deliver
+   the value of the "printer-name" attribute to a Notification Recipient
+   that can access the Printer via value of the "printer-name" attribute
+   and otherwise deliver the value of the "notify-printer-uri"
+   attribute.
+
+   Table 9 - Printer Name in Event Notification Content
+
+   Source Value                            Delivers   Source Object
+
+   printer-name (name(127))                MAY        Printer
+   notify-printer-uri (uri)                MAY        Subscription
+
+
+   Table 10 lists the source of the information for the Event name.  A
+   Printer MAY combine this information with state information described
+   for Jobs in Table 13 or for Printers in Table 14.
+
+   Table 10 - Event Name in Event Notification Content
+
+   Source Value                             Delivers    Source Object
+
+   notify-subscribed-event (type2 keyword)  MAY         Subscription
+
+   Table 11 lists the source of the information for the time that the
+   Event occurred.  A Printer can deliver this value only if it supports
+   the Printer's "printer-current-time" attribute.  If a Printer does
+   not support the "printer-current-time" attribute, it MUST NOT deliver
+   the "printer-up-time" value instead, since it is not an allowed
+   option for human consumable information.
+
+   Table 11 - Event Time in Event Notification Content
+
+   Source Value                            Delivers   Source Object
+
+   printer-current-time (dateTime)         MAY        Printer
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 48]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+9.2.2.  Additional Event Notification Content for Job Events
+
+   This section lists the source of the additional information that a
+   Delivery Method MUST specify for Job Events.
+
+   Table 12 lists the source of the information for the job name.  The
+   "job-name" is likely more meaningful to a user than "job-id".
+
+   Table 12 - Job Name in Event Notification Content
+
+   Source Value                           Delivers    Source Object
+
+   job-name (name(MAX))                   MAY         Job
+   job-id (integer(1:MAX))                MAY         Job
+
+   Table 13 lists the source of the information for the job state.  If a
+   Printer supports the "job-state-message" and "job-detailed-state-
+   message" attributes, it SHOULD use those attributes for the job state
+   information, otherwise, it should fabricate such information from the
+   "job-state" and "job-state-reasons".  For some Events, a Printer MAY
+   combine this information with Event information.
+
+   Table 13 - Job State in Event Notification Content
+
+   Source Value                                     Delivers  Source
+                                                               Object
+
+   job-state-message (text(MAX))                    MAY       Job
+   job-detailed-status-messages (1setOf text(MAX))  MAY       Job
+   job-state (type1 enum)                           MAY       Job
+   job-state-reasons (1setOf type2 keyword)         MAY       Job
+
+9.2.3.  Additional Event Notification Content for Printer Events
+
+   This section lists the source of the additional information that a
+   Delivery Method MUST specify for Printer Events.
+
+   Table 14 lists the source of the information for the printer state.
+   If a Printer supports the "printer-state-message", it SHOULD use that
+   attribute for the job state information, otherwise it SHOULD
+   fabricate such information from the "printer-state" and "printer-
+   state-reasons".  For some Events, a Printer MAY combine this
+   information with Event information.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 49]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 14 - Printer State in Event Notification Content
+
+   Source Value                                    Delivers   Source
+                                                               Object
+
+   printer-state-message (text(MAX))               MAY        Printer
+   printer-state (type1 enum)                      MAY        Printer
+   printer-state-reasons (1setOf type2 keyword)    MAY        Printer
+   printer-is-accepting-jobs (boolean)             MAY        Printer
+
+10.  Delivery Methods
+
+   A Delivery Method is the mechanism, i.e., protocol, by which the
+   Printer delivers an Event Notification to a Notification Recipient.
+   There are several potential Delivery Methods for Event Notifications,
+   standardized, as well as proprietary.  This specification REQUIRES
+   that the 'ippget' Pull Delivery Method [RFC3996] be supported.
+   Conforming implementations MAY support additional Push or Pull
+   Delivery Methods as well.  This document does not define any of these
+   delivery mechanisms.  Each Delivery Method MUST be defined in a
+   Delivery Method Document that is separate from this document.  New
+   Delivery Methods will be created as needed using an extension to the
+   registration procedures defined in [RFC2911].  Such documents are
+   registered with IANA (see section 23.7.3).
+
+   The following sorts of Delivery Methods are possible:
+
+   -  The Notification Recipient polls for Event Notifications at
+      intervals directed by the Printer
+
+   -  The Printer delivers Event Notifications to the Notification
+      Recipient using http as the transport.
+
+   -  The Printer delivers an email message.
+
+   This section specifies how to define a Delivery Method Document and
+   what to put in such a document.
+
+   A Delivery Method Document MUST contain an exact copy of the
+   following paragraph, caption and table.  In addition, column 2 of the
+   table in the Delivery Method Document MUST contain answers to
+   questions in column 1 for the Delivery Method.  Also, the Delivery
+   Method document MUST contain a reference to this document and call
+   that reference [RFC3995] because the table contains an [RFC3995]
+   reference.
+
+   If a Printer supports this Delivery Method, the following are its
+   characteristics.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 50]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 15 - Information about the Delivery Method
+
+   Document Method Conformance Requirement     Delivery Method
+                                               Realization
+
+   1.  What is the URL scheme name for the Push Delivery Method or the
+       keyword method name for the Pull Delivery Method?
+
+   2.  Is the Delivery Method REQUIRED, RECOMMENDED, or OPTIONAL for an
+       IPP Printer to support?
+
+   3.  What transport and delivery protocols does the Printer use to
+       deliver the Event Notification Content, i.e., what is the entire
+       network stack?
+
+   4.  Can several Event Notifications be combined into a Compound Event
+       Notification?
+
+   5.  Is the Delivery Method initiated by the Notification Recipient
+       (pull), or by the Printer (push)?
+
+   6.  Is the Event Notification content Machine Consumable or Human
+       Consumable?
+
+   7.  What section in this document answers the following question?
+       For a Machine Consumable Event Notification, what is the
+       representation and encoding of values defined in section 9.1 of
+       [RFC3995] and the conformance requirements thereof?  For a Human
+       Consumable Event Notification, what is the representation and
+       encoding of pieces of information defined in section 9.2 of
+       [RFC3995] and the conformance requirements thereof?
+
+   8.  What are the latency and reliability of the transport and
+       delivery protocol?
+
+   9.  What are the security aspects of the transport and delivery
+       protocol, e.g., how it is handled in firewalls?
+
+   10.  What are the content length restrictions?
+
+   11.  What are the additional values or pieces of information that a
+        Printer delivers in an Event Notification content and the
+        conformance requirements thereof?
+
+   12.  What are the additional Subscription Template and/or
+        Subscription Description attributes and the conformance
+        requirements thereof?
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 51]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   13.  What are the additional Printer Description attributes and the
+        conformance requirements thereof?
+
+11.  Operations for Notification
+
+   This section defines all of the operations for Notification.  Section
+   7.1 assigns the "operation-id" for each operation.  The following two
+   sub-sections define Subscription Creation Operations, and other
+   operations.
+
+11.1.  Subscription Creation Operations
+
+   This section defines the Subscription Creation Operations.  The first
+   section on Create-Job-Subscriptions gives most of the information.
+   The other Subscription Creation Operations refer to the section on
+   Create-Job-Subscriptions, even though the Create-Job-Subscriptions
+   operation is the only OPTIONAL operation in this document (see
+   section 12).
+
+   A Printer MUST support Create-Printer-Subscriptions and the
+   Subscription Template Attributes Group in Job Creation operations.
+   It MAY support Create-Job-Subscriptions operations.
+
+11.1.1.  Create-Job-Subscriptions Operation
+
+   The operation creates one or more Per-Job Subscription Objects.  The
+   client supplies one or more Subscription Template Attributes Groups
+   each containing one or more of Subscription Template Attributes
+   (defined in section 5.3).
+
+   Except for errors, the Printer MUST create exactly one Per-Job
+   Subscription Object from each Subscription Template Attributes Group
+   in the request, even if the newly created Subscription Object would
+   have identical behavior to some existing Subscription Object.  The
+   Printer MUST associate each newly created Per-Job Subscription Object
+   with the target Job, which is specified by the "notify-job-id"
+   operation attribute.
+
+   The Printer MUST accept the request in any of the target job's 'not-
+   completed' states, i.e., 'pending', 'pending-held', 'processing', or
+   'processing-stopped'.  The Printer MUST NOT change the job's "job-
+   state" attribute because of this operation.  If the target job is in
+   any of the 'completed' states, i.e., 'completed', 'canceled', or
+   'aborted, then the Printer MUST reject the request and return the
+   'client-error-not-possible' status code; the response MUST NOT
+   contain any Subscription Attribute Groups.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 52]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Access Rights:  To create Per-Job Subscription Objects, the
+   authenticated user (see [RFC2911] section 8.3) performing this
+   operation MUST (1) be the job owner, (2) have Operator or
+   Administrator access rights for this Printer (see [RFC2911] sections
+   1 and 8.5), or (3) be otherwise authorized by the Printer's
+   administrator-configured security policy to create Per-Job
+   Subscription Objects for the target job.  Otherwise the Printer MUST
+   reject the operation and return: the 'client-error-forbidden',
+   'client-error-not-authenticated', or 'client-error-not-authorized'
+   status code as appropriate.
+
+11.1.1.1.  Create-Job-Subscriptions Request
+
+   The following groups of attributes are part of the Create-Job-
+   Subscriptions Request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.1.
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+   Requesting User Name:
+      The "requesting-user-name" attribute SHOULD be supplied by the
+      client as described in [RFC2911] section 8.3.
+
+11.1.1.1.1.  notify-job-id (integer(1:MAX))
+
+   The client MUST supply this attribute and it MUST specify the Job
+   object to associate the Per-Job Subscription with.  The value of
+   "notify-job-id" MUST be the value of the "job-id" of the associated
+   Job object.  If the client does not supply this attribute, the
+   Printer MUST reject this request with a 'client-error-bad-request'
+   status code.
+
+   Group 2-N: Subscription Template Attributes
+
+      For each occurrence of this group:
+
+         The client MUST supply one or more Subscription Template
+         Attributes in any order.  See section 5.3 for a description of
+         each such attribute.  See section 5.2 for details on processing
+         these attributes.
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 53]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.1.1.2.  Create-Job-Subscriptions Response
+
+   The Printer MUST return to the client the following sets of
+   attributes as part of a Create-Job-Subscriptions response:
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      In addition to the REQUIRED status code returned in every
+      response, the response OPTIONALLY includes a "status-message"
+      (text(255)) and/or a "detailed-status-message" (text(MAX))
+      operation attribute as described in [RFC2911] sections 13 and
+      3.1.6.
+
+      In this group, the Printer can return any status codes defined in
+      [RFC2911] and section 12.  The following is a description of the
+      important status codes:
+
+      successful-ok: the Printer created all Subscription Objects
+         requested (see [RFC2911]).
+
+      successful-ok-ignored-subscriptions: the Printer created some
+         Subscription Objects requested but some failed.  The
+         Subscription Attributes Groups with a "notify-status-code"
+         attribute are the ones that failed (see section 12.1).
+
+      client-error-ignored-all-subscriptions: the Printer created no
+         Subscription Objects requested and all failed.  The
+         Subscription Attributes Groups with a "notify-status-code"
+         attribute are the ones that failed (see section 12.2).
+
+      client-error-not-possible: For this operation and other Per-Job
+         Subscription operations, this error can occur because the
+         specified Job has already completed (see [RFC2911], whether or
+         not the Job is retained in the Job Retention and/or Job History
+         phases (see [RFC2911] section 4.3.7.1).
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 for details on returning Unsupported
+      Attributes.  This group does not contain any unsupported
+      Subscription Template Attributes; they are returned in the
+      Subscription Attributes Group (see below).
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 54]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Group 3-N: Subscription Attributes
+
+      These groups MUST be returned unless the Printer is unable to
+      interpret the entire request, e.g., the "status-code" parameter
+      returned in Group 1 has the value: 'client-error-bad-request'.
+
+      "notify-status-code" (type2 enum):
+         Indicates the status of this subscription (see section 13 for
+         the status code definitions).  Section 5.2 defines when this
+         attribute MUST be present in this group.
+
+      See section 5.2 for details on the contents of each occurrence of
+      this group.
+
+11.1.2.  Create-Printer-Subscriptions operation
+
+   The operation is identical to Create-Job-Subscriptions with
+   exceptions noted in this section.
+
+   The operation creates Per-Printer Subscription Objects instead of
+   Per-Job Subscription Objects, and associates each newly created Per-
+   Printer Subscription Object with the Printer specified by the
+   operation target rather than with a specific Job.
+
+   The Printer MUST accept the request in any of its states, i.e.,
+   'idle', 'processing', or 'stopped'.  The Printer MUST NOT change its
+   "printer-state" attribute because of this operation.
+
+   Access Rights:  To create Per-Printer Subscription Objects, the
+   authenticated user (see [RFC2911] section 8.3) performing this
+   operation MUST have (1) Operator or Administrator access rights for
+   this Printer (see [RFC2911] sections 1 and 8.5), or (2) be otherwise
+   authorized by the Printer's administrator-configured security policy
+   to create Per-Printer Subscription Objects for this Printer.
+   Otherwise, the Printer MUST reject the operation and return: the
+   'client-error-forbidden', 'client-error-not-authenticated', or
+   'client-error-not-authorized' status code as appropriate.
+
+11.1.2.1.  Create-Printer-Subscriptions Request
+
+   The groups are identical to the Create-Job-Subscriptions (see section
+   11.1.1.1) except that the Operation Attributes group MUST NOT contain
+   the  "notify-job-id" attribute.  If the client does supply the
+   "notify-job-id" attribute, then the Printer MUST treat it as any
+   other unsupported Operation attribute and MUST return it in the
+   Unsupported Attributes group.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 55]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.1.2.2.  Create-Printer-Subscriptions Response
+
+   The groups are identical to the Create-Job-Subscriptions (see section
+   11.1.1.2).
+
+11.1.3.  Job Creation Operations - Extensions for Notification
+
+   This document extends the Job Creation operations (see section 3.2)
+   to create Subscription Objects as a part of the operation.
+
+   The Job Creation operations are identical to Create-Job-Subscriptions
+   operation with exceptions noted in this section.
+
+   Unlike the Create-Job-Subscriptions operation, a Job Creation
+   operation associates the newly created Subscription Objects with the
+   Job object created by this operation.  The operation succeeds if and
+   only if the Job creation succeeds.  If the Printer does not create
+   some or all of the requested Subscription Objects, the Printer MUST
+   return a  'successful-ok-ignored-subscriptions' status-code instead
+   of a 'successful-ok' status-code, but the Printer MUST NOT reject the
+   operation because of a failure to create Subscription Objects.
+
+   If the Job Creation operation includes a Job Template group, the
+   client MUST supply it after the Operation Attributes group and before
+   the first Subscription Template Attributes Group.
+
+   If a Printer does not support this Notification specification, then
+   it MUST treat the Subscription Attributes Group like an unknown group
+   and ignore it (see [RFC2911] section 5.2.2).  Because the Printer
+   ignores the Subscription Attributes Group, it doesn't return them in
+   the response either, thus indicating to the client that the Printer
+   doesn't support Notification.
+
+   After completion of a successful Job Creation operation, the Printer
+   generates a 'job-created' event (see section 5.3.3.4.3).
+
+   Access Rights:  To create Per-Job Subscription Objects, the
+   authenticated user (see [RFC2911] section 8.3) performing this
+   operation MUST either have permission to create Jobs on the Printer
+   or have Operator or Administrator access rights for this Printer (see
+   [RFC2911] sections 1 and 8.5).  Otherwise the Printer MUST reject the
+   operation and return: the 'client-error-forbidden', 'client-error-
+   not-authenticated', or 'client-error-not-authorized' status code as
+   appropriate.
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 56]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.1.3.1.  Job Creation Request
+
+   The groups for this operation are sufficiently different from the
+   Create-Job-Subscriptions operation that they are all presented here.
+   The following groups of attributes are supplied as part of a Job
+   Creation Request:
+
+   Group 1: Operation Attributes
+
+      Same as defined in [RFC2911] for Print-Job, Print-URI, and
+      Create-Job requests.
+
+   Group 2: Job Template Attributes
+
+      The client OPTIONALLY supplies a set of Job Template attributes as
+      defined in [RFC2911] section 4.2.
+
+   Group 3 to N: Subscription Template Attributes
+
+      The same as Group 2-N in Create-Job-Subscriptions.  See section
+      11.1.1.1.
+
+   Group N+1: Document Content  (Print-Job only)
+
+      The client MUST supply the document data to be processed.
+
+11.1.3.2.  Job Creation Response
+
+   The Printer MUST return to the client the following sets of
+   attributes as part of a Print-Job, Print-URI, and Create-Job
+   Response:
+
+   Group 1: Operation Attributes
+
+      Status Message:
+
+         As defined in [RFC2911] for Print-Job, Print-URI, and Create-
+         Job requests.
+
+         In this group, the Printer can return any status codes defined
+         in [RFC2911] and section 12.  The following is a description of
+         the important status codes:
+
+         successful-ok: the Printer created the Job and all
+            Subscription Objects requested (see [RFC2911].
+
+         successful-ok-ignored-subscriptions: the Printer created
+            the Job and not all of the Subscription Objects requested
+
+
+
+Herriot & Hastings          Standards Track                    [Page 57]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+            (see section 12.1).  This status-code hides 'successful-ok-
+            xxx' status-codes that could reveal problems in Job
+            creation.  The Printer MUST NOT return the 'client-error-
+            ignored-all-subscriptions' status code for Job Creation
+            operations because the Printer returns an error status-code
+            only when it fails to create a Job.
+
+         Natural Language and Character Set:
+            The "attributes-charset" and "attributes-natural-language"
+            attributes as described in [RFC2911] section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 for details on returning Unsupported
+      Attributes.  This group does not contain any unsupported
+      Subscription Template Attributes; they are returned in the
+      Subscription Attributes Group (see below).
+
+   Group 3: Job Object Attributes
+
+      The "job-id" of the Job Object just created, etc., as defined in
+      [RFC2911] for Print-Job, Print-URI, and Create-Job requests.
+
+   Group 4 to N: Subscription Attributes
+
+      These groups MUST be returned if and only if the client supplied
+      Subscription Template Attributes and the operation was accepted.
+
+      See section 5.2 for details on the contents of each occurrence of
+      this group.
+
+11.2.  Other Operations
+
+   This section defines other operations on Subscription objects.
+
+11.2.1.  Restart-Job Operation - Extensions for Notification
+
+   The Restart-Job operation [RFC2911] is neither a Job Creation
+   operation nor a Subscription Creation operation (see section 3.2).
+
+   For the Restart-Job operation, the client MUST NOT supply any Job
+   Subscription Attributes Groups.  The Printer MUST treat any supplied
+   Job Subscription Attributes as unsupported attributes.
+
+   For this operation, the Printer does not return a job-id or any
+   Subscription Attributes groups because the Printer reuses the
+   existing Job object with the same job-id and the existing Per-Job
+   Subscription Objects with the same subscription-ids.  However, after
+
+
+
+Herriot & Hastings          Standards Track                    [Page 58]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   successful completion of this operation, the Printer generates a
+   'job-created' event (see section 5.3.3.4.3).
+
+11.2.2.  Validate-Job Operation - Extensions for Notification
+
+   A client can test whether one or more Subscription Objects could be
+   created using the Validate-Job operation.  The client supplies one or
+   more Subscription Template Attributes Groups (defined in section
+   5.3), just as in a Job Creation request.
+
+   A Printer MUST support this extension to this operation.
+
+   The Printer MUST accept requests that are identical to the Job
+   Creation request defined in section 11.1.3.1, except that the request
+   MUST NOT contain document data.
+
+   The Printer MUST return the same groups and attributes as the Print-
+   Job operation (section 11.1.3.1) with the following exceptions.  The
+   Printer MUST NOT return a Job Object Attributes Group because no Job
+   is created.  The Printer MUST NOT return the "notify-subscription-id"
+   attribute in any Subscription Attribute Group because no Subscription
+   Object is created.
+
+   If the Printer would succeed in creating a Subscription Object, the
+   corresponding Subscription Attributes Group either has no 'status-
+   code' attribute or a 'status-code' attribute with a value of
+   'successful-ok-too-many-events' or 'successful-ok-ignored-or-
+   substituted-attributes' (see sections 5.2 and 13).  The status-codes
+   have the same meaning as in Job Creation except the results state
+   what "would happen".
+
+   The Printer MUST validate Subscription Template Attributes Groups in
+   the same manner as the Job Creation operations.
+
+11.2.3.  Get-Printer-Attributes - Extensions for Notification
+
+   This operation is extended so that it returns Printer attributes
+   defined in this document.
+
+   A Printer MUST support this extension to this operation.
+
+   In addition to the requirements of [RFC2911] section 3.2.5, a Printer
+   MUST support the following additional values for the "requested-
+   attributes" Operation attribute in this operation and return such
+   attributes in the Printer Object Attributes group of its response.
+
+   1. Subscription Template Attributes: Each supported attribute in
+      column 2 of Table 1.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 59]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   2. New Printer Description Attributes: Each supported attribute in
+      section 6.
+
+   3. New Group Name: The 'subscription-template' group name, which
+      names all supported Subscription Template Attribute in column 2 of
+      Table 1.  This group name is also used in the Get-Subscription-
+      Attributes and Get-Subscriptions operation with an analogous
+      meaning.
+
+   4. Extended Group Name: The 'all' group name, which names all Printer
+      attributes according to [RFC2911] section 3.2.5.  In this
+      extension 'all' names all attributes specified in [RFC2911] plus
+      those named in items 1 and 2 of this list.
+
+11.2.4.  Get-Subscription-Attributes operation
+
+   This operation allows a client to request the values of the
+   attributes of a Subscription Object.
+
+   A Printer MUST support this operation.
+
+   This operation is almost identical to the Get-Job-Attributes
+   operation (see [RFC2911] section 3.3.4).  The only differences are
+   that the operation is directed at a Subscription Object rather than a
+   Job object, and the returned attribute group contains Subscription
+   Object attributes rather than Job object attributes.
+
+   Access Rights:  The authenticated user (see [RFC2911] section 8.3)
+   performing this operation MUST (1) be the Subscription Object owner,
+   (2) have Operator or Administrator access rights for this Printer
+   (see [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
+   the Printer's administrator-configured security policy to query the
+   Subscription Object for the target job.  Otherwise the Printer MUST
+   reject the operation and return: the 'client-error-forbidden',
+   'client-error-not-authenticated', or 'client-error-not-authorized'
+   status code as appropriate.  Furthermore, the Printer's security
+   policy MAY limit which attributes are returned, in a manner similar
+   to the Get-Job-Attributes operation (see [RFC2911] end of section
+   3.3.4.2).
+
+11.2.4.1.  Get-Subscription-Attributes Request
+
+   The following groups of attributes are part of the Get-Subscription-
+   Attributes request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+
+
+
+Herriot & Hastings          Standards Track                    [Page 60]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in section [RFC2911] 3.1.4.1.
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+   Requesting User Name:
+      The "requesting-user-name" attribute SHOULD be supplied by the
+      client as described in [RFC2911] section 8.3.
+
+11.2.4.1.1.  "notify-subscription-id" (integer (1:MAX))
+
+   The client MUST supply this attribute.  The Printer MUST support this
+   attribute.  This attribute specifies the Subscription Object from
+   which the client is requesting attributes.  If the client omits this
+   attribute, the Printer MUST reject this request with the 'client-
+   error-bad-request' status code.
+
+11.2.4.1.2.  "requested-attributes" (1setOf keyword)
+
+   The client OPTIONALLY supplies this attribute.  The Printer MUST
+   support this attribute.  This attribute specifies the attributes of
+   the specified Subscription Object that the Printer MUST return in the
+   response.  Each value of this attribute is either an attribute name
+   (defined in sections 5.3 and 5.4) or an attribute group name.  The
+   attribute group names are:
+
+   -  'subscription-template': all attributes that are both defined in
+      section 5.3 and present on the specified Subscription Object
+      (column 1 of Table 1).
+
+   -  'subscription-description': all attributes that are both defined
+      in section 5.4 and present on the specified Subscription Object
+      (Table 2).
+
+   -  'all': all attributes that are present on the specified
+      Subscription Object.
+
+   A Printer MUST support all these group names.
+
+      If the client omits this attribute, the Printer MUST respond as if
+      this attribute had been supplied with a value of 'all'.
+
+11.2.4.2.  Get-Subscription-Attributes Response
+
+   The Printer returns the following sets of attributes as part of the
+   Get-Subscription-Attributes Response:
+
+
+
+Herriot & Hastings          Standards Track                    [Page 61]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      Same as [RFC2911].
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.  The
+      "attributes-natural-language" MAY be the natural language of the
+      Subscription Object, rather than the one requested.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 and section 3.2.5.2 for details on
+      returning Unsupported Attributes.
+
+      The response NEED NOT contain the "requested-attributes" operation
+      attribute with any supplied keyword values that were requested by
+      the client but are not supported by the IPP object.  If the
+      Printer object does return unsupported attributes referenced in
+      the "requested-attributes" operation attribute, the values of the
+      "requested-attributes" attribute returned MUST include only the
+      unsupported keywords that were requested by the client.  If the
+      client had requested a group name, such as 'all', the resulting
+      unsupported attributes returned MUST NOT include attribute keyword
+      names described in the standard but not supported by the
+      implementation.
+
+   Group 3: Subscription Attributes
+
+      This group contains a set of attributes with their current values.
+      Each attribute returned in this group:
+
+   a) MUST be specified by the "requested-attributes" attribute in the
+      request, AND
+
+   b) MUST be present on the specified Subscription Object AND
+
+   c) MUST  NOT be restricted by the security policy in force.  For
+      example, a Printer MAY prohibit a client who is not the creator of
+      a Subscription Object from seeing some or all of its attributes.
+      See [RFC2911] end of section 3.3.4.2 and section 8.
+
+      The Printer can return the attributes of the Subscription Object
+      in any order.  The client MUST accept the attributes in any order.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 62]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.2.5.  Get-Subscriptions operation
+
+   This operation allows a client to retrieve the values of attributes
+   of all Subscription Objects belonging to a Job or Printer.
+
+   A Printer MUST supported this operation.
+
+   This operation is similar to the Get-Subscription-Attributes
+   operation, except that this Get-Subscriptions operation returns
+   attributes from possibly more than one object.
+
+   This operation is similar to the Get-Jobs operation (see [RFC2911]
+   section 3.2.6), except that the operation returns Subscription
+   Objects rather than Job objects.
+
+   Access Rights:  To query Per-Job Subscription Objects of the
+   specified job (client supplied the "notify-job-id" operation
+   attribute - see section 11.2.5.1.1), the authenticated user (see
+   [RFC2911] section 8.3) performing this operation MUST (1) be the
+   Subscription Object owner, (2) have Operator or Administrator access
+   rights for this Printer (see [RFC2911] sections 1 and 8.5), or (3) be
+   otherwise authorized by the Printer's administrator-configured
+   security policy to query the Subscription Object for the target job.
+   To query Per-Printer Subscription Objects of the Printer (client
+   omits the "notify-job-id" operation attribute - see section
+   11.2.5.1.1), the authenticated user (see [RFC2911] section 8.3)
+   performing this operation MUST (1) have Operator or Administrator
+   access rights for this Printer (see [RFC2911] sections 1 and 8.5), or
+   (2) be otherwise authorized by the Printer's administrator-configured
+   security policy to query Per-Printer Subscription Objects for the
+   target Printer.  Otherwise the Printer MUST reject the operation and
+   return: the 'client-error-forbidden', 'client-error-not-
+   authenticated', or 'client-error-not-authorized' status code as
+   appropriate.  Furthermore, the Printer's security policy MAY limit
+   which attributes are returned, in a manner similar to the Get-Jobs
+   and Get-Printer-Attributes operations (see [RFC2911] end of sections
+   3.2.6.2 and 3.2.5.2).
+
+11.2.5.1.  Get-Subscriptions Request
+
+   The following groups of attributes are part of the Get-Subscriptions
+   request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.1.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 63]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+   Requesting User Name:
+      The "requesting-user-name" attribute SHOULD be supplied by the
+      client as described in [RFC2911] section 8.3.
+
+11.2.5.1.1.  "notify-job-id" (integer(1:MAX))
+
+   If the client specifies this attribute, the Printer returns the
+   specified attributes of all Per-Job Subscription Objects associated
+   with the Job whose "job-id" attribute value equals the value of this
+   attribute.  If the client does not specify this attribute, the
+   Printer returns the specified attributes of all Per-Printer
+   Subscription Objects.  Note: there is no way to get all Per-Job
+
+   Subscriptions known to the Printer in a single operation.  A Get-Jobs
+   operation followed by a Get-Subscriptions operation for each Job will
+   return all Per-Job Subscriptions.
+
+11.2.5.1.2.  "limit" (integer(1:MAX))
+
+   The client OPTIONALLY supplies this attribute.  The Printer MUST
+   support this attribute.  It is an integer value that determines the
+   maximum number of Subscription Objects that a client will receive
+   from the Printer even if the "my-subscriptions" attribute constrains
+   which Subscription Objects are returned.  The limit is a "stateless
+   limit" in that if the value supplied by the client is 'N', then only
+   the first 'N' Subscription Objects are returned in the Get-
+   Subscriptions Response.  There is no mechanism to allow for the next
+   'M' Subscription Objects after the first 'N' Subscription Objects.
+   If the client does not supply this attribute, the Printer responds
+   with all applicable Subscription Objects.
+
+11.2.5.1.3.  "requested-attributes" (1setOf type2 keyword)
+
+   The client OPTIONALLY supplies this attribute.  The Printer MUST
+   support this attribute.  This attribute specifies the attributes of
+   the specified Subscription Objects that the Printer MUST return in
+   the response.  Each value of this attribute is either an attribute
+   name (defined in sections 5.3 and 5.4) or an attribute group name
+   (defined in section 11.2.4.1).  If the client omits this attribute,
+   the Printer MUST respond as if the client had supplied this attribute
+   with the one value: 'notify-subscription-id'.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 64]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.2.5.1.4.  "my-subscriptions" (boolean)
+
+   The client OPTIONALLY supplies this attribute.  The Printer MUST
+   support this attribute.  If the value is 'false', the Printer MUST
+   consider the Subscription Objects from all users as candidates.  If
+   the value is 'true', the Printer MUST return the Subscription Objects
+   created by the requesting user of this request.  If the client does
+   not supply this attribute, the Printer MUST respond as if the client
+   had supplied the attribute with a value of 'false'.  The means for
+   authenticating the requesting user and matching the Subscription
+   Objects is similar to that for Jobs which is described in [RFC2911]
+   section 8.
+
+11.2.5.2 Get-Subscriptions Response
+
+   The Printer returns the following sets of attributes as part of the
+   Get-Subscriptions Response:
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      Same as [RFC2911].
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.
+
+   Group 2: Unsupported Attributes
+
+      Same as for Get-Subscription-Attributes.
+
+   Groups 3 to N: Subscription Attributes
+
+      The Printer responds with one Subscription Attributes Group for
+      each requested Subscription Object (see the "notify-job-id"
+      attribute in the Operation Attributes Group of this operation).
+
+      The Printer returns Subscription Objects in any order.
+
+      If the "limit" attribute is present in the Operation Attributes
+      group of the request, the number of Subscription Attributes Groups
+      in the response MUST NOT exceed the value of the "limit"
+      attribute.
+
+      It there are no Subscription Objects associated with the specified
+      Job or Printer, the Printer MUST return zero Subscription
+      Attributes Groups and it MUST NOT treat this case as an error,
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 65]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      i.e., the status-code MUST be 'successful-ok' unless something
+      else causes the status code to have some other value.
+
+      See the Group 3 response (Subscription Attributes Group) of the
+      Get-Subscription-Attributes operation (section 11.2.4.2) for the
+      attributes that a Printer returns in this group.
+
+11.2.6.  Renew-Subscription operation
+
+   This operation allows a client to request the Printer to extend the
+   lease on a Per-Printer Subscription Object.
+
+   The Printer MUST support this operation.
+
+   The Printer MUST accept this request for a Per-Printer Subscription
+   Object in any of the target Printer's states, i.e., 'idle',
+   'processing', or 'stopped', but MUST NOT change the Printer's
+   "printer-state" attribute.
+
+   The Printer MUST reject this request for a Per-Job Subscription
+   Object because it has no lease (see section 5.4.3).  The status code
+   returned MUST be 'client-error-not-possible'.
+
+   Access Rights: The authenticated user (see [RFC2911] section 8.3)
+   performing this operation MUST (1) be the owner of the Per-Printer
+   Subscription Object, (2) have Operator or Administrator access rights
+   for the Printer (see [RFC2911] sections 1 and 8.5), or (3) be
+   otherwise authorized by the Printer's administrator-configured
+   security policy to renew Per-Printer Subscription Objects for the
+   target Printer.  Otherwise, the Printer MUST reject the operation and
+   return: the 'client-error-forbidden', 'client-error-not-
+   authenticated', or 'client-error-not-authorized' status code as
+   appropriate.
+
+11.2.6.1.  Renew-Subscription Request
+
+   The following groups of attributes are part of the Renew-Subscription
+   Request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.1.
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 66]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Requesting User Name:
+      The "requesting-user-name" (name(MAX)) attribute SHOULD be
+      supplied by the client as described in [RFC2911] section 8.3.
+
+11.2.6.1.1.  "notify-subscription-id" (integer (1:MAX))
+
+   The client MUST supply this attribute.  The Printer MUST support this
+   attribute.  This attribute specifies the Per-Printer Subscription
+   Object whose lease the Printer MUST renew.  If the client omits this
+   attribute, the Printer MUST reject this request with the 'client-
+   error-bad-request' status code.
+
+   Group 2: Subscription Template Attributes
+
+11.2.6.1.2.  "notify-lease-duration" (integer(0:MAX))
+
+   The client MAY supply this attribute.  It indicates the number of
+   seconds to renew the lease for the specified Subscription Object.  A
+   value of 0 requests an infinite lease (which MAY require Operator
+   access rights).  If the client omits this attribute, the Printer MUST
+   use the value of the Printer's "notify-lease-duration-default"
+   attribute.  See section 5.3.8 for more details.
+
+11.2.6.2.  Renew-Subscription Response
+
+   The Printer returns the following sets of attributes as part of the
+   Renew-Subscription Response:
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      Same as [RFC2911].
+
+      The following are some of the status codes returned (see
+      [RFC2911]:
+
+         successful-ok: The operation successfully renewed the lease
+            on the Subscription Object for the requested duration.
+
+         successful-ok-ignored-or-substituted-attributes: The
+            operation successfully renewed the lease on the Subscription
+            Object for some duration other than the amount requested.
+
+         client-error-not-possible: The operation failed because the
+            "notify-subscription-id" Operation attribute identified a
+            Per-Job Subscription Object.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 67]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+         client-error-not-found: The operation failed because the
+            "notify-subscription-id" Operation attribute identified a
+            non-existent Subscription Object.
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.  The
+      "attributes-natural-language" MAY be the natural language of the
+      Subscription Object, rather than the one requested.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 for details on returning Unsupported
+      Attributes.
+
+   Group 3: Subscription Attributes
+
+      The Printer MUST return the following Subscription Attribute:
+
+11.2.6.2.1.  "notify-lease-duration" (integer(0:MAX))
+
+   The value of this attribute MUST be the number of seconds that the
+   Printer has granted for the lease of the Subscription Object (see
+   section 5.3.8 for details, such as the value of this attribute when
+   the Printer doesn't support the requested value).
+
+11.2.7.  Cancel-Subscription operation
+
+   This operation allows a client to delete a Subscription Object and
+   stop the Printer from delivering more Event Notifications.  Once
+   performed, there is no way to reference the Subscription Object.
+
+   A Printer MUST supported this operation.
+
+   The Printer MUST accept this request in any of the target Printer's
+   states, i.e., 'idle', 'processing', or 'stopped', but MUST NOT change
+   the Printer's "printer-state" attribute.
+
+   If the specified Subscription Object is a Per-Job Subscription
+   Object, the Printer MUST accept this request in any of the target
+   Job's states, but MUST NOT change the Job's "job-state" attribute or
+   affect the Job.
+
+   Note:  There is no way to change any attributes on a Subscription
+   Object, except the "notify-lease-duration" attribute (using the
+   Renew-Subscription operation).  In order to change other attributes,
+   a client performs a Subscription Creation Operation and Cancel-
+   Subscription operation on the old Subscription Object.  If the client
+
+
+
+Herriot & Hastings          Standards Track                    [Page 68]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   wants to avoid missing Event Notifications, it performs the
+   Subscription Creation Operation first.  If this order would create
+   too many Subscription Objects on the Printer, the client reverses the
+   order.
+
+   Access Rights: The authenticated user (see [RFC2911] section 8.3)
+   performing this operation MUST (1) be the owner of the Subscription
+   Object, (2) have Operator or Administrator access rights for the
+   Printer (see [RFC2911] sections 1 and 8.5), or (3) be otherwise
+   authorized by the Printer's administrator-configured security policy
+   to cancel the target Subscription Object.  Otherwise, the Printer
+   MUST reject the operation and return: the 'client-error-forbidden',
+   'client-error-not-authenticated', or 'client-error-not-authorized'
+   status code as appropriate.
+
+11.2.7.1.  Cancel-Subscription Request
+
+   The following groups of attributes are part of the Cancel-
+   Subscription Request:
+
+   Group 1: Operation Attributes
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.1.
+
+   Target:
+      The "printer-uri" attribute which defines the target for this
+      operation as described in [RFC2911] section 3.1.5.
+
+   Requesting User Name:
+      The "requesting-user-name" attribute SHOULD be supplied by the
+      client as described in [RFC2911] section 8.3.
+
+11.2.7.1.1.  "notify-subscription-id" (integer (1:MAX))
+
+   The client MUST supply this attribute.  The Printer MUST support this
+   attribute.  This attribute specifies the Subscription Object that the
+   Printer MUST cancel.  If the client omits this attribute, the Printer
+   MUST reject this request with the 'client-error-bad-request' status
+   code.
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 69]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+11.2.7.2.  Cancel-Subscription Response
+
+   The Printer returns the following sets of attributes as part of the
+   Cancel-Subscription Response:
+
+   Group 1: Operation Attributes
+
+   Status Message:
+      Same as [RFC2911].
+
+         The following are some of the status codes returned (see
+         [RFC2911]:
+
+         successful-ok: The operation successfully canceled
+            (deleted) the Subscription Object.
+
+         client-error-not-found: The operation failed because the
+            "notify-subscription-id" Operation attribute identified a
+            non-existent Subscription Object.
+
+   Natural Language and Character Set:
+      The "attributes-charset" and "attributes-natural-language"
+      attributes as described in [RFC2911] section 3.1.4.2.  The
+      "attributes-natural-language" MAY be the natural language of the
+      Subscription Object, rather than the one requested.
+
+   Group 2: Unsupported Attributes
+
+      See [RFC2911] section 3.1.7 for details on returning Unsupported
+      Attributes.
+
+12.  Status Codes
+
+   The following status codes are defined as extensions for Notification
+   and are returned as the value of the "status-code" parameter in the
+   Operation Attributes Group of a response (see [RFC2911] section
+   3.1.6.1).  Operations in this document can also return the status
+   codes defined in section 13 of [RFC2911].  The 'successful-ok' status
+   code is an example of such a status code.
+
+12.1.  successful-ok-ignored-subscriptions (0x0003)
+
+   The Subscription Creation Operation was unable to create all
+   requested Subscription Objects.
+
+   For a Create-Job-Subscriptions or Create-Printer-Subscriptions
+   operation, this status code means that the Printer created one or
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 70]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   more Subscription Objects, but not all requested Subscription
+   Objects.
+
+   For a Job Creation operation, this status code means that the Printer
+   created the Job along with zero or more Subscription Objects.  The
+   Printer returns this status code even if other job attributes are
+   unsupported or in conflict.  That is, if an IPP Printer finds a
+   warning that would allow it to return 'successful-ok-ignored-
+   subscriptions' and either 'successful-ok-ignored-or-substituted-
+   attributes' and/or 'successful-ok-conflicting-attributes', it MUST
+   return 'successful-ok-ignored-subscriptions'.
+
+12.2.  client-error-ignored-all-subscriptions (0x0414)
+
+   This status code is the same as 'successful-ok-ignored-subscriptions'
+   except that only the Create-Job-Subscriptions and Create-Printer-
+   Subscriptions operation return it.  They return this status code only
+   when the Printer creates zero Subscription Objects.
+
+13.  Status Codes in Subscription Attributes Groups
+
+   This section contains values of the "notify-status-code" (type2 enum)
+   attribute that the Printer returns in a Subscription Attributes Group
+   in a response when the corresponding Subscription Object:
+
+   1. is not created or
+
+   2. is created and some of the client-supplied attributes are not
+      supported.
+
+   The following sections are ordered in decreasing order of importance
+   of the status-codes.
+
+13.1.  client-error-uri-scheme-not-supported (0x040C)
+
+   This status code is defined in [RFC2911].  This document extends its
+   meaning and allows it to be in a Subscription Attributes Group of a
+   response.
+
+   The scheme of the client-supplied URI in a "notify-recipient-uri"
+   Subscription Template Attribute in a Subscription Creation Operation
+   is not supported.  See section 5.3.1.
+
+13.2.  client-error-attributes-or-values-not-supported (0x040B)
+
+   This status code is defined in [RFC2911].  This document extends its
+   meaning and allows it to be in a Subscription Attributes Group of a
+   response.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 71]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   The method of the client-supplied keyword in a "notify-pull-method"
+   Subscription Template Attribute in a Subscription Creation Operation
+   is not supported.  See section 5.3.2.
+
+13.3.  client-error-too-many-subscriptions (0x0415)
+
+   The number of Subscription Objects supported by the Printer would be
+   exceeded if this Subscription Object were created (see section 5.2).
+
+13.4.  successful-ok-too-many-events (0x0005)
+
+   The client supplied more Events in the "notify-events" operation
+   attribute of a Subscription Creation Operation than the Printer
+   supports, as indicated in its "notify-max-events-supported" Printer
+   attribute (see section 5.3.3).
+
+13.5.  successful-ok-ignored-or-substituted-attributes (0x0001)
+
+   This status code is defined in [RFC2911].  This document extends its
+   meaning to include unsupported Subscription Template Attributes and
+   it can appear in a Subscription Attributes Group.
+
+14.  Encodings of Additional Attribute Tags
+
+   This section assigns values to two attributes tags as extensions to
+   the encoding defined in [RFC2910]).
+
+   The "subscription-attributes-tag" delimits Subscription Template
+   Attributes Groups in requests and Subscription Attributes Groups in
+   responses.
+
+   The "event-notification-attributes-tag" delimits Event Notifications
+   in Delivery Methods that use an IPP-like encoding.
+
+   The following table specifies the values for the delimiter tags:
+
+      Tag Value (Hex)   Meaning
+
+      0x06              "subscription-attributes-tag"
+      0x07              "event-notification-attributes-tag"
+
+15.  Conformance Requirements
+
+   It is OPTIONAL for IPP clients and Printers to implement this Event
+   Notification specification.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 72]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+15.1.  Conformance requirements for clients
+
+   If this Event Notification specification is implemented by a client,
+   the client MUST support the 'ippget' Pull Delivery Method and meet
+   the conformance requirements as defined in [RFC3996] for clients.  A
+   client MAY support additional Delivery Methods.
+
+15.2.  Conformance requirements for Printers
+
+   If this Event Notification specification is implemented by a Printer,
+   the Printer MUST:
+
+   -  meet the Conformance Requirements detailed in section 5 of
+      [RFC2911].
+
+   -  support the Subscription Template Attributes Group in requests and
+      the Subscription Attributes Group in responses.
+
+   -  support all of the following attributes:
+
+      a. REQUIRED Subscription Object attributes in section 5.
+      b. REQUIRED Printer Description object attributes in section 6.
+      c. REQUIRED attributes in Event Notification content in section 8.
+
+   -  support the 'ippget' Pull Delivery Method and meet the conformance
+      requirements as defined in [RFC3996] for Printers.  The Printer
+      MAY support additional Push and Pull Delivery Methods.
+
+   -  deliver Event Notifications that conform to the requirements of
+      section 9 and the requirements of the Delivery Method Document for
+      each supported Delivery Method (the conformance requirements for
+      Delivery Method Documents is specified in section 10).
+
+   -  for all of the Job Creation Operations that the Printer supports,
+      MUST support the REQUIRED extensions for notification defined in
+      section 11.1.3.
+
+   -  meet the conformance requirements for operations as described in
+      Table 16 and meet the requirements for Printers as specified in
+      the indicated sub-sections of section 11:
+
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 73]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Table 16 - Printer Conformance Requirements for Operations
+
+   Operation                                         Printer
+                                                     Conformance
+                                                     Requirements
+
+   Create-Printer-Subscriptions (section 11.1.2)     REQUIRED
+   Create-Job-Subscriptions (section 11.1.1)         OPTIONAL
+   Get-Subscription-Attributes (section 11.2.3)      REQUIRED
+   Get-Subscriptions (section 11.2.5)                REQUIRED
+   Renew-Subscription (section 11.2.6)               REQUIRED
+   Cancel-Subscription (section 11.2.7)              REQUIRED
+
+16.  Model for Notification with Cascading Printers (Informative)
+
+   With this model (see Figure 2 below), there is an intervening Print
+   server between the human user and the output-device.  So the system
+   effectively has two Printer objects.  There are two cases to
+   consider.
+
+   1. When the Printer 1 (in the server) generates Events, the system
+      behaves like the client and Printer in Figure 1.  In this case,
+      Printer 1 delivers Event Notifications that are shown as Event
+      Notifications (A) of  Figure 2.
+
+   2. When the Printer 2 (in the output-device) generates Events, there
+      are two possible system configurations:
+
+      a) Printer 1 forwards the client-supplied Subscription Creation
+         Operations to the downstream Printer 2 and lets Printer 2
+         deliver the Event Notifications directly to the Notification
+         Recipients supplied by the Client (Event Notifications(C) in
+         the diagram).
+
+      b) Printer 1 performs the client-supplied Subscription Creation
+         Operations and also forwards the Subscription Creation
+         Operations to Printer 2 with the Notification Recipient changed
+         to be the Printer 1.  When an Event occurs in Printer 2,
+         Printer 2 delivers the Event Notification (B) to Notification
+         Recipient of Printer 1, which relays the received Event
+         Notification (B) to the client-supplied Notification Recipient
+         (as Event Notifications(A) in the diagram).  Note, when a
+         client performs a Subscription Creation Operation, Printer 1
+         need not forward the Subscription Creation Operation to Printer
+         2 if it would create a duplicate Subscription Object on Printer
+         2.
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 74]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Note: when Printer 1 is forwarding Subscription Creation Operations
+   to Printer 2, it may request Printer 2 to create additional
+   Subscription Objects (called "piggy-backing").  Piggy-backing is
+   useful when:
+
+   -  Device A is configured to accept (IPP or non-IPP) requests from
+      other servers.
+
+   -  Server S wants to receive Job Events that the client didn't
+      request and Server S wants these Events for jobs it submits and
+      not for other jobs.
+
+                              server S                       device A
+                           +------------+                 +------------+
+                           |            |                 |            |
+   +--------+ Subscription | ###########|                 | ###########|
+   | client |--Creation ----># Printer #|  Subscription   | # Printer #|
+   +--------+  Operation   | # Object 1#|---Creation------|># Object 2#|
+                           | ###|#######|   Operation     | ####|#|####|
+                           +----|---^---+                 +-----|-|----+
+   +--------+     Event         |   |                           | |
+   |Notific-|<-Notifications(A)-+   +-- Event Notifications(B)--+ |
+   |ation Re|<-------------Event Notifications(C)-----------------+
+   |cipient |
+   +--------+
+
+         Figure 2 - Model for Notification with Cascading Printers
+
+17.  Distributed Model for Notification (Informative)
+
+   A Printer implementation could use some other remote notification
+   server to provide some or most of the service.  For example, the
+   remote notification server could deliver Event Notifications using
+   Delivery Methods that are not directly supported by the output device
+   or Printer object.  Or, the remote notification server could store
+   Subscription Objects (passed to it from the output device in response
+   to Subscription Creation requests), accept Events, format the Event
+   Notification in the natural language of the Notification Recipient,
+   and deliver the Event Notifications to the Notification Recipient(s).
+
+   Figure 3 shows this partitioning.  The interface between the output
+   device (or Printer object) and the remote notification server is
+   outside the scope of this document and is intended to be transparent
+   to the client and this document.
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 75]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+                                            ***********************
+                                            *
+                                            * Printer in combination
+                                            * with the distributed
+                                            * Notification Server)
+                                            *
+                                            * output device or server
+                                            * +---------------+
+      PDA, desktop, or server               * +  ###########  +
+           +--------+                       * |  #         #  |
+           | client |---IPP Subscription--------># Printer #  |
+           +--------+   Creation operation  * |  # Object  #  |
+                                            * |  #####|#####  |
+                                            * +-------|-------+
+                                            *         | Subscriptions
+                                            *         | OR Event
+        +------------+                      *         | Notifications
+        |Notification|   IPP-defined        *  +------v--------+
+        |Recipient   |<--Event Notifications---| Notification  |
+        +------------+                      *  | Server        |
+                                            *  +---------------+
+                                            *
+                                            *************************
+   *** = Implementation configuration opaque boundary
+
+     Figure 3 - Opaque Use of a Notification Server Transparent to the
+                                  Client
+
+18.  Extended Notification Recipient (Informative)
+
+   The model allows for an extended Notification Recipient that is
+   itself a notification server that forwards each Event Notification to
+   another recipient (called the Ultimate Notification Recipient in this
+   section).  The Delivery Method to the Ultimate Recipient is probably
+   different from the Delivery Method used by the Printer to the
+   extended Notification Recipient.
+
+   This extended Notification Recipient is transparent to the Printer
+   but not to the client.
+
+   When a client performs a Subscription Creation Operation, it
+   specifies the extended Notification Recipient as it would any
+   Notification Recipient.  In addition, the client specifies the
+   Ultimate Notification Recipient in the Subscription Creation
+   Operation in a manner specified by the extended Notification
+   Recipient.  Typically, it is either some bytes in the value of
+   "notify-user-data" or some additional parameter in the value of
+   "notify-recipient-uri".  The client also subscribes directly with the
+
+
+
+Herriot & Hastings          Standards Track                    [Page 76]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   extended Notification Recipient (by means outside this document),
+   since it is a notification server in its own right.
+
+   The IPP Printer treats the extended Notification Recipient like any
+   other Notification Recipient and the IPP Printer is not aware of the
+   forwarding.  The Delivery Method that the extended Notification
+   Recipient uses for delivering the Event Notification to the Ultimate
+   Notification Recipient is beyond the scope of this document and is
+   transparent to the IPP Printer.
+
+   Examples of this extended Notification Recipient are paging,
+   immediate messaging services, general notification services, and NOS
+   vendors' infrastructure.  Figure 4 shows this approach.
+
+      PDA, desktop, or server                    server or output device
+                                                      +---------------+
+          +--------+                                  |  ###########  |
+          | client |---Subscription Creation -----------># Printer #  |
+          +--------+       Operation                  |  # Object  #  |
+                                                      |  #####|#####  |
+   +------------+     +------------+   IPP-defined    +-------|-------+
+   |Ultimate    | any |Notification|<--Event Notifications----+
+   |Notification|<----|Recipient   |
+   |Recipient   |     +------------+
+   +------------+     (Notification Server)
+
+    Figure 4 - Use of an Extended Notification Recipient transparent to
+                                the Printer
+
+19.  Object Model for Notification (Normative)
+
+   This section describes the Notification object model that adds a
+   Subscription Object which together with the Job and Printer object
+   provide the complete Notification semantics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 77]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   The object relationships can be seen pictorially as:
+
+   Subscription Objects (Per-Printer Subscriptions)     Printer object
+   +----+                                               +------------+
+   | s1 |<--------------------------------------------->|            |
+   +----++                                              |            |
+    | s2 |<-------------------------------------------->|     p1     |
+    +----++                                             |            |
+     | s3 |<------------------------------------------->|            |
+     +----+                                             +------------+
+                    Job objects
+                    +---------+
+                    |         |
+     +----+         |   j1    |
+     | s4 |<------->|         |
+     +----+         |         |
+                    |         |    s4 is a Per-Job Subscription Object
+                    ++--------++
+                     |         |
+       +----+        |   j2    |
+       | s5 |<------>|         |
+       +----++       |         |
+        | s6 |<----->|         |    s5 and s6 are Per-Job Subscription
+        +----+       ++--------++                  Objects
+                      |         |
+                      |   j3    |
+                      |         |
+                      |         |         <----> indicates association
+                      +---------+
+
+               Figure 5 - Object Model for Notification
+
+   s1, s2, and s3 are Per-Printer Subscription Objects and can identify
+   Printer and/or Job Events.
+
+   s4, s5, and s6 are Per-Job Subscription Objects and can identify
+   Printer and/or Job Events.
+
+19.1.  Object relationships
+
+   This sub-section defines the object relationships between the
+   Printer, Job, and Subscription Objects by example.  Whether Per-
+   Printer Subscription Objects are actually contained in a Printer
+   object or are just bi-directionally associated with them in some way
+   is IMPLEMENTATION DEPENDENT and is transparent to the client.
+   Similarly, whether Per-Job Subscription Objects are actually
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 78]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   contained in a Job object or are just bi-directionally associated
+   with them in some way is IMPLEMENTATION DEPENDENT and is transparent
+   to the client.  The object relationships are defined as follows:
+
+19.2.  Printer Object and Per-Printer Subscription Objects
+
+   1. The Printer object contains (is associated with) zero or more
+      Per-Printer Subscription Objects (p1 contains s1-s3 Per-Printer
+      Subscription Objects).
+
+   2. Each Per-Printer Subscription Object (s1, s2, and s3) is contained
+      in (or is associated with) exactly one Printer object (p1).
+
+19.3.  Job Object and Per-Job Subscription Objects
+
+   1. A Job object (j1, j2, j3) is associated with zero or more Per-Job
+      Subscription Objects (s4-s6).  Job j1 is associated with Per-Job
+      Subscription Object s4, Job j2 is associated with Per-Job
+      Subscription Objects s5 and s6, and Job j3 is not associated with
+      any Per-Job Subscription Object.
+
+   2. Each Per-Job Subscription Object is associated with exactly one
+      Job object.
+
+20.  Per-Job versus Per-Printer Subscription Objects (Normative)
+
+   Per-Job and Per-Printer Subscription Objects are quite similar.
+   Either type of Subscription Object can subscribe to Job Events,
+   Printer Events, or both.  Both types of Subscription Objects can be
+   queried using the Get-Subscriptions and Get-Subscription-Attributes
+   operations and canceled using the Cancel-Subscription operation.
+   Both types of Subscription Objects create Subscription Objects which
+   have the same Subscription Object attributes defined.  However, there
+   are some semantic differences between Per-Job Subscription Objects
+   and Per-Printer Subscription Objects.  A Per-Job Subscription Object
+   is established by the client when submitting a job and after creating
+   the job using the Create-Job-Subscriptions operation by specifying
+   the "job-id" of the Job with the "notify-job-id" attribute.  A Per-
+   Printer Subscription Object is established between a client and a
+   Printer using the Create-Printer-Subscriptions operation.  Some
+   specific differences are:
+
+   1. A client usually creates one or more Per-Job Subscription Objects
+      as part of the Job Creation operations (Create-Job, Print-Job, and
+      Print-URI), rather than using the OPTIONAL Create-Job-
+      Subscriptions operation, especially since Printer implementations
+      NEED NOT support the Create-Job-Subscriptions operation, since it
+      is OPTIONAL.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 79]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   2. For Per-Job Subscription Objects, the Subscription Object is only
+      valid while the job is "not-complete" (see sections 5.4.3) while
+      for the Per-Printer Subscription Objects, the Subscription Object
+      is valid until the time (in seconds) that the Printer returned in
+      the "notify-lease-expiration-time" operation attribute.
+
+   3. Job Events in a Per-Job Subscription Object apply only to "one
+      job" (the Job created by the Job Creation operation or references
+      by the Create-Job-Subscriptions operation) while Job Events in a
+      Per-Printer Subscription Object apply to ALL jobs contained in the
+      IPP Printer.
+
+21.  Normative References
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119 , March 1997.
+
+   [RFC2396]         Berners-Lee, T., Fielding, R., and L. Masinter,
+                     "Uniform Resource Identifiers (URI): Generic
+                     Syntax", RFC 2396, August 1998.
+
+   [RFC2717]         Petke, R. and I. King, "Registration Procedures for
+                     URL Scheme Names", RFC 2717, November 1999.
+
+   [RFC2910]         Herriot, R., Butler, S., Moore, P., and R. Turner,
+                     "Internet Printing Protocol/1.1: Encoding and
+                     Transport", RFC 2910, September 2000.
+
+   [RFC2911]         deBry, R., Hastings, T., Herriot, R., Isaacson, S.,
+                     and P. Powell, "Internet Printing Protocol/1.1:
+                     Model and Semantics", RFC 2911, September 2000.
+
+   [RFC3381]         Hastings, T., Lewis, H., and R. Bergman, "IPP: Job
+                     Progress Attributes", RFC 3381,  September 2002.
+
+   [RFC3996]         Herriot, R., Hastings, T., and H. Lewis, "Internet
+                     Printing Protocol (IPP): The 'ippget' Delivery
+                     Method for Event Notifications", RFC 3996, March
+                     2005.
+
+22.  Informative References
+
+   [IANA-CON]        Narten, T. and H. Alvestrand, "Guidelines for
+                     Writing an IANA Considerations Section in RFCs",
+                     BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 80]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   [RFC2565]         Herriot, R., Butler, S., Moore, P., and R. Turner,
+                     "Internet Printing Protocol/1.0: Encoding and
+                     Transport", RFC 2565, April 1999.
+
+   [RFC2566]         deBry, R., Hastings, T., Herriot, R., Isaacson, S.,
+                     and P. Powell, "Internet Printing Protocol/1.0:
+                     Model and Semantics", RFC 2566, April 1999.
+
+   [RFC2567]         Wright, D., "Design Goals for an Internet Printing
+                     Protocol", RFC 2567, April 1999.
+
+   [RFC2568]         Zilles, S., "Rationale for the Structure and Model
+                     and Protocol for the Internet Printing Protocol",
+                     RFC 2568, April 1999.
+
+   [RFC2569]         Herriot, R., Hastings, T., Jacobs, N., and J.
+                     Martin, "Mapping between LPD and IPP Protocols",
+                     RFC 2569, April 1999.
+
+   [RFC2616]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                     Masinter, L., Leach, P., and T. Berners-Lee,
+                     "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
+                     June 1999.
+
+   [RFC3196]         Hastings, T., Manros, C., Zehler, P., Kugler, C.,
+                     and H. Holst, "Internet Printing Protocol/1.1:
+                     Implementer's Guide", RFC 3196, November 2001.
+
+   [RFC3997]         Hastings, T., Editor, deBry, R., and H. Lewis,
+                     "Internet Printing Protocol (IPP): Requirements for
+                     IPP Notifications", RFC 3997, March 2005.
+
+23.  IANA Considerations
+
+   This section contains the registration information that IANA added to
+   the IPP Registry according to the procedures defined in RFC 2911
+   [RFC2911] section 6 to cover the definitions in this document.  In
+   addition, this section defines how Events and Delivery Methods will
+   be registered when they are defined in other documents.  The
+   resulting registrations have been published in the
+   http://www.iana.org/assignments/ipp-registrations registry.
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 81]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+23.1.  Attribute Registrations
+
+   The following table lists all the attributes defined in this
+   document.  These have been registered according to the procedures in
+   RFC 2911 [RFC2911] section 6.2.
+
+   Subscription Template attributes:                 Reference  Section
+   ---------------------------------                 ---------  -------
+   notify-attributes (1setOf type2 keyword)          [RFC3995]  5.3.4
+   notify-attributes-supported (1setOf type2 keyword)
+                                                     [RFC3995]  5.3.4.1
+   notify-charset (charset)                          [RFC3995]  5.3.6
+   notify-events (1setOf type2 keyword)              [RFC3995]  5.3.3
+   notify-events-default (1setOf type2 keyword)      [RFC3995]  5.3.3.1
+   notify-events-supported (1setOf type2 keyword)    [RFC3995]  5.3.3.2
+   notify-lease-duration (integer(0:67108863))       [RFC3995]  5.3.8
+   notify-lease-duration-default (integer(0:67108863))
+                                                     [RFC3995]  5.3.8.1
+   notify-lease-duration-supported (1setOf (integer(0: 67108863) |
+          rangeOfInteger(0:67108863)))               [RFC3995]  5.3.8.2
+   notify-max-events-supported (integer(2:MAX))      [RFC3995]  5.3.3.3
+   notify-natural-language (naturalLanguage)         [RFC3995]  5.3.7
+   notify-pull-method (type2 keyword)                [RFC3995]  5.3.2
+   notify-pull-method-supported (1setOf type2 keyword)
+                                                     [RFC3995]  5.3.2.1
+   notify-recipient-uri (uri)                        [RFC3995]  5.3.1
+   notify-schemes-supported  (1setOf uriScheme)      [RFC3995]  5.3.1.1
+   notify-time-interval (integer(0:MAX))             [RFC3995]  5.3.9
+   notify-user-data (octetString(63))                [RFC3995]  5.3.5
+
+   Subscription Description Attributes:
+   notify-job-id (integer(1:MAX))                    [RFC3995]  5.4.6
+   notify-lease-expiration-time (integer(0:MAX))     [RFC3995]  5.4.3
+   notify-printer-up-time (integer(1:MAX))           [RFC3995]  5.4.4
+   notify-printer-uri (uri)                          [RFC3995]  5.4.5
+   notify-sequence-number (integer (0:MAX))          [RFC3995]  5.4.2
+   notify-subscriber-user-name (name(MAX))           [RFC3995]  5.4.7
+   notify-subscription-id  (integer (1:MAX))         [RFC3995]  5.4.1
+
+   Printer Description Attributes:
+   printer-state-change-date-time (dateTime)         [RFC3995]  6.2
+   printer-state-change-time (integer(1:MAX))        [RFC3995]  6.1
+
+   Attributes Only in Event Notifications
+   notify-subscribed-event (type2 keyword)           [RFC3995]  8.1
+   notify-text (text(MAX))                           [RFC3995]  8.2
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 82]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+23.2.  Additional Enum Attribute Value Registrations within the IPP
+       registry
+
+   The following table lists all the new enum attribute values defined
+   in this document.  These have been registered within the IPP registry
+   according to the procedures in RFC 2911 [RFC2911] section 6.1.
+
+   Attribute
+     Value      Name                                 Reference   Section
+     ------     -----------------------------        ---------   -------
+   operations-supported (1setOf type2 enum)          [RFC2911]   4.4.15
+     0x0016     Create-Printer-Subscriptions         [RFC3995]   7.1
+     0x0017     Create-Job-Subscriptions             [RFC3995]   7.1
+     0x0018     Get-Subscription-Attributes          [RFC3995]   7.1
+     0x0019     Get-Subscriptions                    [RFC3995]   7.1
+     0x001A     Renew-Subscription                   [RFC3995]   7.1
+     0x001B     Cancel-Subscription                  [RFC3995]   7.1
+
+23.3.  Operation Registrations
+
+   The following table lists all of the operations defined in this
+   document.  These have been registered according to the procedures in
+   RFC 2911 [RFC2911] section 6.4.
+
+   Operation Name                                    Reference   Section
+   ---------------------------------                 ---------   -------
+   Cancel-Subscription                               [RFC3995]   11.2.7
+   Create-Job - Extensions                           [RFC3995]   11.1.3
+   Create-Job-Subscriptions                          [RFC3995]   11.1.1
+   Create-Printer-Subscriptions                      [RFC3995]   11.1.2
+   Get-Printer-Attributes - Extensions               [RFC3995]   11.2.3
+   Get-Subscription-Attributes                       [RFC3995]   11.2.4
+   Get-Subscriptions                                 [RFC3995]   11.2.5
+   Print-Job - Extensions                            [RFC3995]   11.1.3
+   Print-URI - Extensions                            [RFC3995]   11.1.3
+   Renew-Subscription                                [RFC3995]   11.2.6
+   Validate-Job Operation - Extensions               [RFC3995]   11.2.2
+
+23.4.  Status code Registrations
+
+   The following table lists all the status codes defined in this
+   document.  These have been registered according to the procedures in
+   RFC 2911 [RFC2911] section 6.6.
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 83]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Value    Status Code Name                        Reference  Section
+   -----    ----------------------------            ---------  -------
+   0x0000:0x00FF - Successful:
+   0x0003   successful-ok-ignored-subscriptions     [RFC3995]  12.1
+   0x0005   successful-ok-too-many-events           [RFC3995]  13.4
+
+   0x0400:0x04FF - Client Error:
+   0x0414   client-error-ignored-all-subscriptions  [RFC3995]  12.2
+   0x0415   client-error-too-many-subscriptions     [RFC3995]  13.3
+
+23.5.  Attribute Group tag Registrations
+
+   The following table lists all the attribute group tags defined in
+   this document.  These have been registered according to the
+   procedures in RFC 2911 [RFC2911] section 6.5.
+
+   Value    Attribute Group Tag Name                 Reference  Section
+   -----    --------------------------------         --------   -------
+   0x06     subscription-attributes-tag              [RFC3995]  14
+   0x07     event-notification-attributes-tag        [RFC3995]  14
+
+23.6.  Registration of Events
+
+   The following table lists all the Events defined in this document as
+   type2 keywords to be used with the "notify-events", "notify-events-
+   default", and "notify-events-supported" Subscription Template
+   attributes (see section 5.3.3)).  Rather than creating a separate
+   section in the IPP Registry for Events, these event keywords have
+   been registered according to the procedures of [RFC2911] section 7.1
+   as additional keyword attribute values for use with the "notify-
+   events" Subscription Template attribute (see section 5.3.3), i.e.,
+   registered as keyword values for the "notify-events", "notify-
+   events-default", and "notify-events-supported" attributes:
+
+   Attribute (attribute syntax)
+     Value                                          Reference  Section
+     ---------------------                          ---------  -------
+   notify-events (1setOf type2 keyword)             [RFC3995]  5.3.3
+   notify-events-default (1setOf type2 keyword)     [RFC3995]  5.3.3.1
+   notify-events-supported (1setOf type2 keyword)   [RFC3995]  5.3.3.2
+   notify-subscribed-event (type2 keyword)          [RFC3995]  8.1
+     No Events:
+       none                                         [RFC3995]  5.3.3.4.1
+     Printer Events:
+       printer-state-changed                        [RFC3995]  5.3.3.4.2
+       printer-restarted                            [RFC3995]  5.3.3.4.2
+       printer-shutdown                             [RFC3995]  5.3.3.4.2
+       printer-stopped                              [RFC3995]  5.3.3.4.2
+
+
+
+Herriot & Hastings          Standards Track                    [Page 84]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+       printer-config-changed                       [RFC3995]  5.3.3.4.2
+       printer-media-changed                        [RFC3995]  5.3.3.4.2
+       printer-finishings-changed                   [RFC3995]  5.3.3.4.2
+       printer-queue-order-changed                  [RFC3995]  5.3.3.4.2
+     Job Events:
+       job-state-changed                            [RFC3995]  5.3.3.4.3
+       job-created                                  [RFC3995]  5.3.3.4.3
+       job-completed                                [RFC3995]  5.3.3.4.3
+       job-stopped                                  [RFC3995]  5.3.3.4.3
+       job-config-changed                           [RFC3995]  5.3.3.4.3
+       job-progress                                 [RFC3995]  5.3.3.4.3
+
+23.7.  Registration of Event Notification Delivery Methods
+
+   This section describes the requirements and procedures for
+   registration and publication of Event Notification Delivery Methods
+   and for the submission of such proposals.
+
+23.7.1.  Requirements for Registration of Event Notification Delivery
+         Methods
+
+   Registered IPP Event Notification Delivery Methods are expected to
+   follow a number of requirements described below.
+
+23.7.1.1.  Required Characteristics
+
+   A Delivery Method Document MUST either (1) contain all of the
+   semantics of the Delivery Method or (2) contain the IPP Delivery
+   Method registration requirements and a profile of some other protocol
+   that in combination is the Delivery Method (e.g., mailto).  The
+   Delivery Method Document (and any documents it requires) MUST define
+   either (1) a URL for a Push Delivery Method that the meets the
+   requirements of [RFC2717].  or (2) a keyword for a Pull Delivery
+   method.
+
+   IPP Event Notification Delivery Method Documents MUST meet the
+   requirements of this document (see sections 9 and 10).
+
+   In addition, a Delivery Method Document MUST contain the following
+   information:
+
+      Type of registration:  IPP Event Notification Delivery Method
+      Name of this delivery method:
+      Proposed URL scheme name of this Push Delivery Method or the
+      keyword name of this Pull Delivery Method:
+      Name of proposer:
+      Address of proposer:
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 85]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      Email address of proposer:
+      Is this delivery method REQUIRED or OPTIONAL for conformance to
+      the IPP Event Notification and Subscriptions document:
+      Is this delivery method defining Machine Consumable and/or Human
+      Consumable content:
+
+23.7.1.2.  Naming Requirements
+
+   Exactly one (URL scheme or keyword) name MUST be assigned to each
+   Delivery Method.
+
+   Each assigned name MUST uniquely identify a single Delivery Method.
+   All Push Delivery Method names MUST conform to the rules for URL
+   scheme names, according to [RFC2396] and [RFC2717] for schemes in the
+   IETF tree.  All Pull Delivery Method names MUST conform to the rules
+   for keywords according to [RFC2911].
+
+23.7.1.3.  Functionality Requirements
+
+   Delivery Methods MUST function as a protocol that is capable of
+   delivering (push or pull) IPP Event Notifications to Notification
+   Recipients.
+
+23.7.1.4.  Usage and Implementation Requirements
+
+   Use of a large number of Delivery Methods may hamper
+   interoperability.  However, the use of a large number of undocumented
+   and/or unlabeled Delivery Methods hampers interoperability even more.
+
+   A Delivery Method should therefore be registered ONLY if it adds
+   significant functionality that is valuable to a large community, OR
+   if it documents existing practice in a large community.  Note that
+   Delivery Methods registered for the second reason should be
+   explicitly marked as being of limited or specialized use and should
+   only be used with prior bilateral agreement.
+
+23.7.1.5.  Publication Requirements
+
+   Delivery Method Documents MUST be published in a standards track,
+   informational, or experimental RFCs.
+
+23.7.2.  Registration Procedure
+
+   The IPP WG is developing a small number of Delivery Methods which are
+   intended to be published as standards track RFCs.  However, some
+   parties may wish to register additional Delivery Methods in the
+   future.  This section describes the procedures for these additional
+   Delivery Methods.
+
+
+
+Herriot & Hastings          Standards Track                    [Page 86]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+23.7.2.1.  Present the proposal to the Community
+
+   First the Delivery Method Document MUST be an Internet-Draft with a
+   target category of standards track, informational, or experimental.
+   The same MUST be true for any documents that it references.
+
+   Deliver the proposed Delivery Method Document proposal to the
+   "ipp@pwg.org" mailing list.  This mailing list has been established
+   by [RFC2911] for reviewing proposed registrations and discussing
+   other IPP matters.  Proposed Delivery Method Documents are not
+   formally registered and MUST NOT be used until approved.
+
+   The intent of the public posting is to solicit comments and feedback
+   on the definition and suitability of the Delivery Method and the name
+   chosen for it over a four week period.
+
+23.7.2.2.  Delivery Method Reviewer
+
+   The Delivery Method Reviewer is the same person who has been
+   appointed by the IETF Application Area Director(s) as the IPP
+   Designated Expert according to [RFC2911] and [IANA-CON].  When the
+   four week period is over and the IPP Designated Expert is convinced
+   that consensus has been achieved, the IPP Designated Expert either
+   approves the request for registration or rejects it.  Rejection may
+   occur because of significant objections raised on the list or
+   objections raised externally.
+
+   Decisions made by the Reviewer must be posted to the ipp@pwg.org
+   mailing list within 14 days.  Decisions made by the Reviewer may be
+   appealed to the IESG.
+
+23.7.2.3.  IANA Registration
+
+   Provided that the Delivery Method registration proposal has either
+   passed review or has been successfully appealed to the IESG, the IANA
+   will be notified by the delivery method reviewer and asked to
+   register the Delivery Method and make it available to the community.
+
+23.7.3.  Delivery Method Document Registrations
+
+   Each Push Delivery Method Document defines a URI scheme.  Such a URI
+   scheme is used in a URI value of the "notification-recipient" (uri)
+   Subscription Template attribute (see section 5.3.1) and the uriScheme
+   value of the "notify-schemes-supported" (1setOf uriScheme 5.3.1.1)
+   Printer attribute(see section ).  Rather than creating a separate
+   section in the IPP Registry for Delivery Methods, Push Delivery
+   Methods will be registered as an additional value of the "notify-
+   schemes-supported" Printer attribute.  These uriScheme values will be
+
+
+
+Herriot & Hastings          Standards Track                    [Page 87]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   registered according to the procedures of [RFC2911] section 7.1 for
+   additional attribute values.  Therefore, the IPP Registry entry for a
+   Push Delivery Method will be of the form:
+
+   Attribute
+     Value                                        Ref.       Section
+     ---------------------                        --------   -------
+   notify-schemes-supported (1setOf uriScheme)    [RFC3995]  5.3.1.1
+     <scheme name>                                RFC xxxx   m.n
+
+   Each Pull Delivery Method Document defines a keyword method which is
+   registered as an additional value of the "notify-pull-method" and
+   "notify-pull-method-supported" Printer attributes.  These keyword
+   values will be registered according to the procedures of [RFC2911]
+   section 7.1 for additional attribute values.  Therefore, the IPP
+   Registry entry for a Pull Delivery Method will be of the form:
+
+   Attribute
+     Value                                        Ref.       Section
+     ---------------------                        --------   -------
+   notify-pull-method (type2 keyword)             [RFC3995]  5.3.2
+   notify-pull-method-supported (1setOf type2 keyword)
+                                                  [RFC3995]  5.3.2.1
+     <method keyword name>                        RFC xxxx    m.n
+
+23.7.4.  Registration Template
+
+   To: ipp@pwg.org
+   Subject: Registration of a new Delivery Method
+
+   Delivery Method name:
+
+   (All Push Delivery Method names must be suitable for use as the value
+   of a URL scheme in the IETF tree and all Pull Delivery Method names
+   must be suitable IPP keywords according to [RFC2911])
+
+   Published specification(s):
+
+   (A specification for the Delivery Method must be openly available
+   that accurately describes what is being registered.)
+
+   Person & email address to contact for further information:
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 88]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+24.  Internationalization Considerations
+
+   This IPP Notification specification continues support for the
+   internationalization of [RFC2911] of attributes containing text
+   strings and names.  Allowing a Subscribing Client to specify a
+   different natural language and charset for each Subscription Object
+   increases the internationalization support.
+
+   The Printer MUST be able to localize the content of Human Consumable
+   Event Notifications and to localize the value of "notify-text"
+   attribute in Machine Consumable Event Notifications that it delivers
+   to Notification Recipients.  For localization, the Printer MUST use
+   the value of the "notify-charset" attribute and the "notify-natural-
+   language" attribute in the Subscription Object supplied by the
+   Subscribing Client.
+
+25.  Security Considerations
+
+   Clients submitting Notification requests to the IPP Printer have the
+   same security issues as submitting an IPP/1.1 print job request (see
+   [RFC2911] section 3.2.1 and section 8).  The same mechanisms used by
+   IPP/1.1 can therefore be used by the client Notification submission.
+   Operations that require authentication can use the HTTP
+   authentication.  Operations that require privacy can use the HTTP/TLS
+   privacy.  As with IPP/1.1 Print Job Objects, if there is no security
+   on Subscription Objects, sequential assignment of subscription-ids
+   exposes the system to a passive traffic monitoring threat.
+
+25.1.  Client access rights
+
+   The Subscription Object access control model is the same as the
+   access control model for Job objects.  The client MUST have the
+   following access rights for the indicated Subscription operations:
+
+   1. Create-Job-Subscriptions (see section 11.1.1):  A Per-Job
+      Subscription object is associated with a Job.  To create Per-Job
+      Subscription Objects, the authenticated user (see [RFC2911]
+      section 8.3) performing this operation MUST (1) be the job owner,
+      (2) have Operator or Administrator access rights for this Printer
+      (see [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized
+      by the Printer's administrator-configured security policy to
+      create Per-Job Subscription Objects for the target job.
+
+   2. Create-Printer-Subscriptions (see section 11.1.2):  A Per-Printer
+      Subscription object is associated with the Printer.  To create
+      Per-Printer Subscription Objects, the authenticated user (see
+      [RFC2911] section 8.3) performing this operation MUST (1) have
+      Operator or Administrator access rights for this Printer (see
+
+
+
+Herriot & Hastings          Standards Track                    [Page 89]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+      [RFC2911] sections 1 and 8.5) or (2) be otherwise authorized by
+      the Printer's administrator-configured security policy to create
+      Per-Printer Subscription Objects for this Printer.
+
+   3. Get-Subscription-Attributes (see section 11.2.4):  The access
+      control model for this operation is the same as that of the Get-
+      Job-Attributes operation (see [RFC2911] section 3.3.4).  The
+      primary difference is that a Get-Subscription-Attributes operation
+      is directed at a Subscription Object rather than at a Job object,
+      and a returned attribute group contains Subscription Object
+      attributes rather than Job object attributes.  To query the
+      specified Subscription Object, the authenticated user (see
+      [RFC2911] section 8.3) performing this operation MUST (1) be the
+      Subscription Object owner, (2) have Operator or Administrator
+      access rights for this Printer (see [RFC2911] sections 1 and 8.5),
+      or (3) be otherwise authorized by the Printer's administrator-
+      configured security policy to query the Subscription Object for
+      the target job.  Furthermore, the Printer's security policy MAY
+      limit which attributes are returned, in a manner similar to the
+      Get-Job-Attributes operation (see [RFC2911] end of section
+      3.3.4.2).
+
+   4. Get-Subscriptions (see section 11.2.5):  The access control model
+      for this operation is the same as that of the Get-Jobs operation
+      (see [RFC2911] section 3.2.6).  The primary difference is that the
+      operation is directed at Subscription Objects rather than at Job
+      objects, and the returned attribute groups contain Subscription
+      Object attributes rather than Job object attributes.  To query
+      Per-Job Subscription Objects of the specified job (client supplied
+      the "notify-job-id" operation attribute - see section 11.2.5.1.1),
+      the authenticated user (see [RFC2911] section 8.3) performing this
+      operation MUST (1) be the Subscription Object owner, (2) have
+      Operator or Administrator access rights for this Printer (see
+      [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
+      the Printer's administrator-configured security policy to query
+      the Subscription Object for the target job.  To query Per-Printer
+      Subscription Objects of the Printer (client omits the "notify-
+      job-id" operation attribute - see section 11.2.5.1.1), the
+      authenticated user (see [RFC2911] section 8.3) performing this
+      operation MUST (1) have Operator or Administrator access rights
+      for this Printer (see [RFC2911] sections 1 and 8.5), or (2) be
+      otherwise authorized by the Printer's administrator-configured
+      security policy to query Per-Printer Subscription Objects for the
+      target Printer.  Furthermore, the Printer's security policy MAY
+      limit which attributes are returned, in a manner similar to the
+      Get-Job-Attributes operation (see [RFC2911] end of section
+      3.2.6.2).
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 90]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   5. Renew-Subscriptions (see section 11.2.6):  The authenticated user
+      (see [RFC2911] section 8.3) performing this operation MUST (1) be
+      the owner of the Per-Printer Subscription Object, (2) have
+      Operator or Administrator access rights for the Printer (see
+      [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
+      the Printer's administrator-configured security policy to renew
+      Per-Printer Subscription Objects for the target Printer
+
+   6. Cancel-Subscription (see section 11.2.7):  The authenticated user
+      (see [RFC2911] section 8.3) performing this operation MUST (1) be
+      the owner of the Subscription Object, (2) have Operator or
+      Administrator access rights for the Printer (see [RFC2911]
+      sections 1 and 8.5), or (3) be otherwise authorized by the
+      Printer's administrator-configured security policy to cancel the
+      target Subscription Object.
+
+   The standard security concerns (delivery to the right user, privacy
+   of content, tamper proof content) apply to each Delivery Method.
+   Some Delivery Methods are more secure than others.  Each Delivery
+   Method Document MUST discuss its Security Considerations.
+
+25.2.  Printer security threats
+
+   Notification trap door:  If a Printer supports the OPTIONAL "notify-
+   attributes" Subscription Template attribute (see section 5.3.4) where
+   the client can request that the Printer return any specified Job,
+   Printer, and Subscription object attributes, the Printer MUST apply
+   the same security policy to these requested attributes in the Get-
+   Notifications request as it does for the Get-Jobs, Get-Job-
+   Attributes, Get-Printer-Attributes, and Get-Subscription-Attributes
+   requests.
+
+25.3.  Notification Recipient security threats
+
+   Unwanted Events Notifications (spam):  For any Push Delivery Method,
+   by far the biggest security concern is the abuse of notification:
+   delivering unwanted Event Notifications to third parties (i.e.,
+   spam).  The problem is made worse by notification addresses that may
+   be redistributed to multiple parties.  There exist scenarios where
+   third party notification is used (see Scenario #2 and #3 in
+   [RFC3997]).  Any fully secure solution would require active agreement
+   of all recipients before delivering anything.
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 91]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+26.  Description of the base IPP documents (Informative)
+
+   The base set of IPP documents includes:
+
+   Design Goals for an Internet Printing Protocol [RFC2567]
+   Rationale for the Structure and Model and Protocol for the Internet
+      Printing Protocol [RFC2568]
+   Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
+   Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
+   Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
+   Mapping between LPD and IPP Protocols [RFC2569]
+
+   The "Design Goals for an Internet Printing Protocol" document takes a
+   broad look at distributed printing functionality, and it enumerates
+   real-life scenarios that help to clarify the features that need to be
+   included in a printing protocol for the Internet.  It identifies
+   requirements for three types of users: end users, operators, and
+   administrators.  It calls out a subset of end user requirements that
+   are satisfied in IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator
+   operations have been added to IPP/1.1 [RFC2911, RFC2910].
+
+   The "Rationale for the Structure and Model and Protocol for the
+   Internet Printing Protocol" document describes IPP from a high level
+   view, defines a roadmap for the various documents that form the suite
+   of IPP specification documents, and gives background and rationale
+   for the IETF IPP working group's major decisions.
+
+   The "Internet Printing Protocol/1.1: Model and Semantics" document
+   describes a simplified model with abstract objects, their attributes,
+   and their operations.  The model introduces a Printer and a Job.  The
+   Job supports multiple documents per Job.  The model document also
+   addresses how security, internationalization, and directory issues
+   are addressed.
+
+   The "Internet Printing Protocol/1.1: Encoding and Transport" document
+   is a formal mapping of the abstract operations and attributes defined
+   in the model document onto HTTP/1.1 [RFC2616].  It also defines the
+   encoding rules for a new Internet MIME media type called
+   "application/ipp".  This document also defines the rules for
+   transporting over HTTP a message body whose Content-Type is
+   "application/ipp".  This document defines the 'ipp' scheme for
+   identifying IPP printers and jobs.
+
+   The "Internet Printing Protocol/1.1: Implementer's Guide" document
+   gives insight and advice to implementers of IPP clients and IPP
+   objects.  It is intended to help them understand IPP/1.1 and some of
+   the considerations that may assist them in the design of their client
+   and/or IPP object implementations.  For example, a typical order of
+
+
+
+Herriot & Hastings          Standards Track                    [Page 92]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   The "Mapping between LPD and IPP Protocols" document gives some
+   advice to implementers of gateways between IPP and LPD (Line Printer
+   Daemon) implementations.
+
+27.  Contributors
+
+   The following people made significant contributions to the design and
+   review of this specification:
+
+   Scott A.  Isaacson
+   Novell, Inc.
+   122 E 1700 S
+   Provo, UT  84606
+
+   Phone: 801-861-7366
+   Fax:   801-861-2517
+   EMail: sisaacson@novell.com
+
+
+   Roger deBry
+   Utah Valley State College
+   Orem, UT 84058
+
+   Phone: 801-863-8848
+   EMail: debryro@uvsc.edu
+
+
+   Jay Martin
+   Underscore Inc.
+   9 Jacqueline St.
+   Hudson, NH 03051-5308
+
+   Phone: 603-889-7000
+   Fax:   775-414-0245
+   EMail: jkm@underscore.com
+
+
+   Michael Shepherd
+   Xerox Corporation
+   800 Phillips Road  MS 128-51E
+   Webster, NY  14450
+
+   Phone: 716-422-2338
+   Fax:   716-265-8871
+   EMail: mshepherd@usa.xerox.com
+
+
+
+Herriot & Hastings          Standards Track                    [Page 93]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+   Ron Bergman
+   Ricoh Printing Systems America
+   1757 Tapo Canyon Road
+   Simi Valley, CA 93063-3394
+
+   Phone: 805-578-4421
+   Fax:   805-578-4001
+   EMail: ron.bergman@rpsa.ricoh.com
+
+Authors' Addresses
+
+   Robert Herriot
+   Global Workflow Solutions
+   706 Colorado Ave.
+   Palo Alto, CA 94303
+
+   Phone:  650-324-4000
+   EMail:  bob@herriot.com
+
+
+   Tom Hastings
+   Xerox Corporation
+   701 S Aviation Blvd, ESAE 242
+   El Segundo, CA  90245
+
+   Phone: 310-333-6413
+   Fax:   310-333-6342
+   EMail: hastings@cp10.es.xerox.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 94]
+
+RFC 3995       IPP: Event Notifications and Subscriptions     March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Herriot & Hastings          Standards Track                    [Page 95]
+