doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc3996.txt b/doc/rfc/rfc3996.txt
new file mode 100644
index 0000000..c2a2a86
--- /dev/null
+++ b/doc/rfc/rfc3996.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                         R. Herriot
+Request for Comments: 3996                     Global Workflow Solutions
+Updates: 2911                                                T. Hastings
+Category: Standards Track                                    Xerox Corp.
+                                                                H. Lewis
+                                                               IBM Corp.
+                                                              March 2005
+
+
+                   Internet Printing Protocol (IPP):
+          The 'ippget' Delivery Method for Event Notifications
+
+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 extension to the Internet Printing
+   Protocol1.1: Model and Semantics (RFC 2911, RFC 2910).  This document
+   specifies the 'ippget' Pull Delivery Method for use with the
+   "Internet Printing Protocol (IPP): Event Notifications and
+   Subscriptions" specification (RFC 3995).  This IPPGET Delivery Method
+   is REQUIRED for all clients and Printers that support RFC 3995.  The
+   Notification Recipient, acting as a client, fetches (pulls) Event
+   Notifications by using the Get-Notifications operation defined in
+   this document.
+
+Table of Contents
+
+   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  3
+        2.1.  Conformance Terminology . . . . . . . . . . . . . . . .  4
+        2.2.  Other Terminology . . . . . . . . . . . . . . . . . . .  4
+   3.   Model and Operation . . . . . . . . . . . . . . . . . . . . .  4
+   4.   General Information . . . . . . . . . . . . . . . . . . . . .  5
+   5.   Get-Notifications Operation . . . . . . . . . . . . . . . . .  7
+        5.1.  Get-Notifications Request . . . . . . . . . . . . . . .  8
+              5.1.1.  notify-subscription-ids (1setOf integer(1:MAX))  8
+              5.1.2.  notify-sequence-numbers (1setOf integer(1:MAX))  9
+
+
+
+Herriot, et al.             Standards Track                     [Page 1]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+              5.1.3.  notify-wait (boolean) . . . . . . . . . . . . . 10
+        5.2.  Get-Notifications Response. . . . . . . . . . . . . . . 10
+              5.2.1.  notify-get-interval (integer(0:MAX)). . . . . . 13
+              5.2.2.  printer-up-time (integer(1:MAX)). . . . . . . . 14
+   6.   Additional Information about Subscription Template Attributes 17
+        6.1.  notify-pull-method (type2 keyword). . . . . . . . . . . 17
+   7.   Subscription Description Attributes . . . . . . . . . . . . . 18
+   8.   Additional Printer Description Attributes . . . . . . . . . . 18
+        8.1.  ippget-event-life (integer(15:MAX)) . . . . . . . . . . 18
+   9.   New Values for Existing Printer Description Attributes. . . . 19
+        9.1.  notify-pull-method-supported (1setOf type2 keyword) . . 19
+        9.2.  operations-supported (1setOf type2 enum). . . . . . . . 19
+   10.  New Status Codes. . . . . . . . . . . . . . . . . . . . . . . 19
+        10.1.  successful-ok-events-complete (0x0007) . . . . . . . . 20
+   11.  Encoding and Transport. . . . . . . . . . . . . . . . . . . . 20
+   12.  Conformance Requirements. . . . . . . . . . . . . . . . . . . 21
+        12.1.  Conformance for IPP Printers . . . . . . . . . . . . . 21
+        12.2.  Conformance for IPP Clients. . . . . . . . . . . . . . 22
+   13.  Normative References. . . . . . . . . . . . . . . . . . . . . 23
+   14.  Informative References. . . . . . . . . . . . . . . . . . . . 23
+   15.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
+        15.1.  Attribute Registrations. . . . . . . . . . . . . . . . 24
+        15.2.  Delivery Method and Additional Keyword Attribute Value
+               registrations for Existing Attributes. . . . . . . . . 24
+        15.3.  Additional Enum Attribute Values . . . . . . . . . . . 25
+        15.4.  Operation Registrations. . . . . . . . . . . . . . . . 25
+        15.5.  Status Code Registrations. . . . . . . . . . . . . . . 25
+   16.  Internationalization Considerations . . . . . . . . . . . . . 25
+   17.  Security Considerations . . . . . . . . . . . . . . . . . . . 26
+        17.1.  Notification Recipient Client Access Rights. . . . . . 26
+        17.2.  Printer Security Threats . . . . . . . . . . . . . . . 27
+        17.3.  Notification Recipient Security Threats. . . . . . . . 27
+        17.4.  Security Requirements for Printers . . . . . . . . . . 27
+        17.5.  Security Requirements for clients. . . . . . . . . . . 28
+   18.  Description of Base IPP Documents (Informative) . . . . . . . 28
+   19.  Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 29
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 31
+
+Table of Tables
+
+   Table 1.  Information about the Delivery Method. . . . . . . . . .  5
+   Table 2.  Combinations of "notify-wait", "status-code", and
+             "notify-get-interval". . . . . . . . . . . . . . . . . . 13
+   Table 3.  Attributes in Event Notification Content . . . . . . . . 15
+   Table 4.  Additional Attributes in Event Notification Content for
+             Job Events . . . . . . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 2]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Table 5.  Combinations of Events and Subscribed Events for "job-
+             impressions-completed" . . . . . . . . . . . . . . . . . 17
+   Table 6.  Additional Attributes in Event Notification Content for
+             Printer Events . . . . . . . . . . . . . . . . . . . . . 17
+   Table 7.  Operation-id Assignments . . . . . . . . . . . . . . . . 19
+   Table 8.  The "event-notification-attributes-tag" Value. . . . . . 21
+
+1.  Introduction
+
+   This document describes an extension to the Internet Printing
+   Protocol/1.1: Model and Semantics [RFC 2911], [RFC 2910].  This
+   document specifies the 'ippget' Pull Delivery Method for use with the
+   "Internet Printing Protocol (IPP): Event Notifications and
+   Subscriptions" specification [RFC3995].  This IPPGET Delivery Method
+   is REQUIRED for all clients and Printers that support [RFC3995].  The
+   Notification Recipient, acting as a client, fetches (pulls) Event
+   Notifications by using the Get-Notifications operation defined in
+   this document.  For a description of the base IPP documents, see
+   section 21 of this document.  For a description of the IPP Event
+   Notification Model, see [RFC3995].
+
+   With this Pull Delivery Method, when an Event occurs, the Printer
+   saves the Event Notification for a period of time called the Event
+   Life.  The Notification Recipient fetches (pulls) the Event
+   Notifications by using the Get-Notifications operation.  This
+   operation causes the Printer to return all Event Notifications held
+   for the specified Subscription object(s).  If the Notification
+   Recipient has selected the Event Wait Mode option to wait for
+   additional Event Notifications, the Printer MAY continue to return
+   Event Notifications to the Notification Recipient as asynchronous
+   Get-Notification responses as Events occur using the transaction
+   originated by the Notification Recipient.
+
+   The Notification Recipient can terminate Event Wait Mode (without
+   closing the connection) by supplying the "notify-wait" (boolean)
+   attribute with a 'false' value in a subsequent Get-Notifications
+   request.  Similarly, the Printer can terminate Event Wait Mode
+   (without closing the connection) by returning the "notify-get-
+   interval" (integer) operation attribute in a Get-Notifications
+   response that tells the Notification Recipient how long to wait
+   before trying again.
+
+2.  Terminology
+
+   This section defines the following terms that are used throughout
+   this document:
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 3]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+2.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 [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 it is explicitly stated otherwise.
+
+2.2.  Other terminology
+
+   This document uses the same terminology as [RFC2911], including
+   "client", "Printer", "Job", "attribute", "attribute value",
+   "keyword", "operation", "request", "response", and "support", with
+   the same meanings.  This document also uses terminology defined in
+   [RFC3995], such as "Subscription (object)", "Notification Recipient",
+   "Event", "Event Notification", "Compound Event Notification", "Event
+   Life", and "Event Notification Attribute Group", with the same
+   meanings.  In addition, this document defines the following terms for
+   use in this document:
+
+   Event Wait Mode: The mode requested by a Notification Recipient
+       client in its Get-Notifications Request and granted by a Printer
+       to keep the connection open while the Printer sends subsequent
+       Get-Notification operation responses to the Notification
+       Recipient in the form of Event Notifications as they occur.
+
+3.  Model and Operation
+
+   In a Subscription Creation Operation, when the "notify-pull-method"
+   attribute is present and has the "ippget" keyword value, the client
+   is requesting that the Printer use the "ippget" Pull Delivery Method
+   for the Event Notifications associated with the new Subscription
+   Object.
+
+   When an Event occurs, the Printer MUST generate an Event Notification
+   and MUST assign it the Event Life.  The Printer MUST hold an Event
+   Notification for its assigned Event Life.
+
+   When a Notification Recipient wants to receive Event Notifications
+   for a Subscription object, it performs the Get-Notifications
+   operation supplying the Subscription object's subscription-id, which
+   causes the Printer to return all un-expired Event Notifications held
+   for that Subscription object.  If the Notification Recipient has
+   selected the Event Wait Mode option to wait for additional Event
+   Notifications, the response to the Get-Notifications request
+   continues indefinitely as the Printer continues to send Event
+
+
+
+Herriot, et al.             Standards Track                     [Page 4]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Notifications in the response as Events occur for that Subscription
+   object.
+
+   When the Notification Recipient requests Event Notifications for
+   Per-Job Subscription Objects, the Notification Recipient typically
+   performs the Get-Notifications operation within a second of
+   performing the Subscription Creation operation.  Because the Printer
+   MUST save Event Notifications for at least 15 seconds (see section
+   8.1), the Notification Recipient is unlikely to miss any Event
+   Notifications that occur between the Subscription Creation and the
+   Get-Notifications operation.
+
+   The 'ippget' Delivery Method is designed primarily for (1) a client
+   that wants to get Events (from the job's Per-Job Subscription object)
+   for a job that it has submitted and (2) a privileged client that
+   wants to get all job or printer Events from a Per-Printer
+   Subscription object.
+
+4.  General Information
+
+   If a Printer supports this Delivery Method, the following are its
+   characteristics.
+
+              Table 1.  Information about the Delivery Method
+
+   Document Method Conformance Requirement    Delivery Method
+   Realization
+
+   1.  What is the URL scheme name for the     'ippget' keyword method
+       Push Delivery Method, or the keyword     name
+       method name for the Pull Delivery
+       Method?
+
+   2.  Is the Delivery Method REQUIRED,        REQUIRED
+       RECOMMENDED, or OPTIONAL for an IPP
+       Printer to support?
+
+   3.  What transport and delivery protocols   IPP with one new
+       does the Printer use to deliver the     operation.
+       Event Notification Content; i.e.,
+       what is the entire network stack?
+
+   4.  Can several Event Notifications be      Yes.
+       combined into a Compound Event
+       Notification?
+
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 5]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   5.  Is the Delivery Method initiated by     This Delivery Method is
+       the Notification Recipient (pull),      a pull method with
+       or by the Printer (push)?               aspects of a push
+                                               method, though the
+                                               Printer does not
+                                               initiate the operation.
+
+   6.  Is the Event Notification content       Machine Consumable.
+       Machine Consumable or Human
+       Consumable?
+
+   7.  What section in this document answers   Section 5.
+       the following questions? For a Machine
+       Consumable Event Notification, what is
+       the representation and encoding of
+       values defined in section 9.1 of
+       [RFC3995], and what are 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    Same as IPP and the
+       of the transport and delivery           underlying HTTP
+       protocol?                               transport.
+
+   9.  What are the security aspects of the    Same as IPP and the
+       transport and delivery protocol;        underlying HTTP
+       e.g., how it is handled in              transport and in the
+       firewalls?                              same direction, so no
+                                               new firewall
+                                               considerations.
+
+   10. What are the content length             None.
+       restrictions?
+
+   11. What are the additional values or       None.
+       pieces of information that a Printer
+       sends in an Event Notification content
+       and the conformance requirements
+       thereof?
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 6]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   12. What are the additional Subscription    None.
+       Template and/or Subscription
+       Description attributes and the
+       conformance requirements thereof?
+
+   13. What are the additional Printer         "ipp-event-life"
+       Description attributes and the          (integer (15: MAX))
+       conformance requirements thereof?
+
+5.  Get-Notifications Operation
+
+   This operation is issued by a client acting in the role of a
+   Notification Recipient requesting the Printer to return all Event
+   Notifications held for the identified Subscription object(s).
+
+   A Printer MUST support this operation, MUST accept the request in any
+   state (see [RFC2911] "printer-state" and "printer-state-reasons"
+   attributes), and MUST remain in the same state with the same
+   "printer-state-reasons" values.
+
+   When a Printer performs this operation, it MUST return all and only
+   those Event Notifications
+
+   1.  whose associated Subscription Object's "notify-subscription-id"
+       Subscription Description attribute equals one of the values of
+       the "notify-subscription-ids" (1setOf integer(1:MAX)) operation
+       attribute AND
+
+   2.  whose associated Subscription Object contains the "notify-pull-
+       method" attribute and it has the 'ippget' keyword value, AND
+
+   3.  whose "notify-sequence-number" is equal to or greater than the
+       corresponding value of the "notify-sequence-numbers" (1setOf
+       integer(1:MAX)) operation attribute if supplied AND
+
+   4.  whose Event Life has not yet expired AND
+
+   5.  where the Notification Recipient client has read-access rights to
+       the identified Subscription Object (see Access Rights paragraph
+       below).
+
+   The Notification Recipient client MUST either (a) request Event Wait
+   Mode by supplying the "notify-wait" operation attribute with a 'true'
+   value or (b) suppress Event Wait Mode by omitting the "notify-wait"
+   operation attribute or by supplying it with a 'false' value.  To
+   terminate Event Wait Mode subsequently, the Notification Recipient
+   client MUST close the connection.  To terminate Event Wait Mode, the
+   Printer MUST either (a) return the "notify-get-interval" operation
+
+
+
+Herriot, et al.             Standards Track                     [Page 7]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   attribute in a Get-Notifications response (RECOMMENDED behavior) or
+   (b) close the connection.  The "notify-get-interval" operation
+   attributes tell the Notification Recipient how long to wait before
+   trying a subsequent Get-Notifications request.
+
+   Access Rights: The authenticated user (see [RFC2911], section 8.3)
+   performing this operation MUST be (1) the owner of each Subscription
+   Object identified by the "notify-subscription-ids" operation
+   attribute (see section 5.1.1), (2) an operator or administrator of
+   the Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise
+   authorized by the Printer's administrator-configured security policy
+   to request Event Notifications from the target Subscription
+   Object(s).  Otherwise, the IPP Printer MUST reject the operation and
+   return: 'client-error-forbidden', 'client-error-not-authenticated',
+   or 'client-error-not-authorized' status code, as appropriate.
+   Furthermore, the Printer's security policy MAY limit the attributes
+   returned by the Get-Notifications operation, in a manner similar to
+   that of the Get-Job-Attributes operation (see [RFC2911], end of
+   section 3.3.4.2).
+
+5.1.  Get-Notifications Request
+
+   The following groups of attributes are part of the Get-Notifications
+   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" (uri) operation attribute that is the target
+         for this operation as described in [RFC2911], section 3.1.5.
+
+      Requesting User Name:
+         The "requesting-user-name" (name(MAX)) attribute SHOULD be
+         supplied by the client as described in [RFC2911], section 8.3.
+
+5.1.1.  notify-subscription-ids (1setOf integer(1:MAX))
+
+   This attribute identifies one or more Subscription objects for which
+   Events are requested.  The client MUST supply this attribute with at
+   least one value.  The Printer object MUST support this attribute with
+   multiple values.
+
+   If no Subscription Object exists with the supplied identifier, or if
+   the identified Subscription Object does not contain the "notify-
+
+
+
+Herriot, et al.             Standards Track                     [Page 8]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   pull-method" attribute with the 'ippget' keyword value, the Printer
+   MUST return the 'client-error-not-found' status code.
+
+         Note:  The name of both the "notify-subscription-ids" and
+         "notify-sequence-numbers" end in 's', as they are multi-valued.
+         However, there are other occurrences of these attribute names
+         without the 's' that are single valued.
+
+5.1.2.  notify-sequence-numbers (1setOf integer(1:MAX))
+
+   This attribute specifies one or more of the lowest Event Notification
+   sequence number values for the Subscription objects identified by the
+   corresponding values of the "notify-subscription-ids" operation
+   attribute.  The Notification Recipient SHOULD supply this attribute,
+   and the number of values SHOULD be the same as that of the "notify-
+   subscriptions-ids" attribute.  The Printer MUST support this
+   attribute with multiple values.
+
+   The Printer MUST NOT return Notification Events with lower sequence
+   numbers for the corresponding Subscription object.  Therefore, by
+   supplying the proper values for this attribute the Notification
+   Recipient can prevent getting the same Event Notifications from a
+   Subscription object that were returned on a previous Get-
+   Notifications request.  The Notification Recipient SHOULD remember
+   the highest "notify-sequence-number" value returned for each
+   Subscription object requested and SHOULD pass that value for each
+   requested Subscription object on the next Get-Notifications request.
+
+   If the Notification Recipient supplies fewer values for this
+   attribute (including omitting this attribute) than it does for the
+   "notify-subscription-ids" operation attribute, the Printer assumes a
+   '1' value for each missing value.  A value of '1' causes the Printer
+   to return any un-expired Event Notification for that Subscription
+   object, as '1' is the lowest possible sequence number.  If the
+   Notification Recipient supplies more values for this attribute than
+   the number of values for the "notify-subscription-ids" operation
+   attribute, the Printer ignores the extra values.
+
+   Note: If a Notification Recipient performs two consecutive Get-
+   Notifications operations with the same value for "notify-sequence-
+   number" (or omits the attribute), the time stamp value of the first
+   Event Notification in the second Get-Notifications Response may be
+   less than that of the time stamp of the last Event Notification in
+   the first Get-Notification Response.  This happens because the
+   Printer sends all unexpired Event Notifications with an equal or
+   higher sequence number according to the ordering specified in
+   [RFC3995], and some Event Notifications from the first Get-
+
+
+
+
+Herriot, et al.             Standards Track                     [Page 9]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Notifications operation may not have expired by the time the second
+   Get-Notifications operation occurs.
+
+5.1.3.  notify-wait (boolean)
+
+   This value indicates whether the Notification Recipient wants Event
+   Wait Mode.  The client MAY supply this attribute.  The Printer object
+   MUST support both values of this attribute.
+
+   If the client supplies the 'false' value or omits this attribute, the
+   client is not requesting Event Wait Mode.  If the value is 'true',
+   the client is requesting Event Wait Mode.  See the beginning of
+   section 5.2 for the rules for Event Wait Mode.
+
+5.2.  Get-Notifications Response
+
+   The Printer has the following options for responding to a Get-
+   Notifications Request:
+
+   1.  The Printer can reject the request and return the 'server-error-
+       busy' status code if the Printer is too busy to accept this
+       operation at this time.  In this case, the Printer MUST return
+       the "get-notify-interval" operation attribute to indicate when
+       the client SHOULD try again.
+
+   2.  If the Notification Recipient did not request Event Wait Mode
+       ("notify-wait-mode" = 'false' or omitted), the Printer MUST
+       immediately return whatever Event Notifications it currently
+       holds in the requested Subscription object(s) and MUST return the
+       "notify-get-interval" operation attribute with the number of
+       seconds from now, at which the Notification Recipient SHOULD
+       repeat the Get-Notifications Request to get future Event
+       Notifications.
+
+   3.  If the Notification Recipient requested Event Wait Mode
+       ("notify-wait-mode" = 'true'), the Printer MUST immediately
+       return whatever Event Notifications it currently holds in the
+       requested Subscription object(s) and MUST continue to return
+       Event Notifications as they occur until all the requested
+       Subscription Objects are canceled.  A Subscription Object is
+       canceled either via the Cancel-Subscription operation or by the
+       Printer (e.g., the Subscription Object is canceled when the
+       associated Job completes and is no longer in the Job Retention or
+       Job History phase; see the "ippget-event-life (integer(15:MAX))"
+       attribute discussion in section 8.1).
+
+       However, the Printer MAY decide to terminate Event Wait Mode at
+       any time, including in the first response.  In this case, the
+
+
+
+Herriot, et al.             Standards Track                    [Page 10]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+       Printer MUST return the "notify-get-interval" operation
+       attribute.  This attribute indicates that the Printer wishes to
+       leave Event Wait Mode and the number of seconds in the future
+       that the Notification Recipient SHOULD try the Get-Notifications
+       operation again.  The Notification Recipient MUST accept this
+       response and MUST disconnect.  If the Notification Recipient does
+       not disconnect, the Printer SHOULD do so.
+
+   From the Notification Recipient's view, the response appears as an
+   initial burst of data, which includes the Operation Attributes Group
+   and one Event Notification Attributes Group per Event Notification
+   that the Printer is holding.  After the initial burst of data, if the
+   Notification Recipient has selected the Event Wait Mode option to
+   wait for additional Event Notifications, the Notification Recipient
+   receives occasional Event Notification Attribute Groups.  Proxy
+   servers may delay some Event Notifications or cause time-outs to
+   occur.  The client MUST be prepared to perform the Get-Notifications
+   operation again when time-outs occur.
+
+   Each attribute is encoded by using the IPP rules for encoding
+   attributes [RFC2910] and MAY be encoded in any order.  Note:  the
+   Get-Jobs response in [RFC2911] acts as a model for encoding multiple
+   groups of attributes.  See section 11 for the encoding and transport
+   rules.
+
+   The following groups of attributes are part of the Get-Notifications
+   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.
+
+         The Printer can return any status codes defined in [RFC2911].
+         If the status code is not 'successful-xxx', the Printer MUST
+         NOT return any Event Notification Attribute groups.  The
+         following are descriptions of the important status codes:
+
+            successful-ok: The response contains all Event Notification
+               associated with the specified subscription-ids that had
+               been supplied in the "notify-subscription-ids" operation
+               attribute in the request.  If the requested Subscription
+               Objects have no associated Event Notification, the
+               response MUST contain zero Event Notifications.
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 11]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+            successful-ok-events-complete:  Indicates when this return
+               is the last return for all Subscription objects that
+               match the request, whether or not Event Notifications are
+               returned.  This condition occurs for Event Wait Mode with
+               Notification Recipients waiting for responses when (1)
+               the Subscription Object is canceled with a Cancel-
+               Subscription operation, (2) the Subscription Object is
+               deleted, when the Per-Printer Subscription lease time
+               expires, or (3) the 'job-completed' event occurs for a
+               Per-Job Subscription.  This condition also occurs for a
+               Get-Notifications request that a Notification Recipient
+               makes after the job completes, but before the Event Life
+               expires.  See section 10.1.
+            client-error-not-found: The Printer has no Subscription
+               Objects whose "notify-subscription-id" attribute equals
+               any of the values of the "notify-subscription-ids"
+               operation attribute supplied, or the identified
+               Subscription Object does not contain the "notify-pull-
+               method" attribute with the 'ippget' keyword value.
+            server-error-busy: The Printer is too busy to accept this
+               operation.  The Printer SHOULD return the "notify-get-
+               interval" operation attribute in the Operation Attributes
+               of the response; then the Notification Recipient SHOULD
+               wait for the number of seconds specified by the "notify-
+               get-interval" operation attribute before performing this
+               operation again.  If the "notify-get-interval" Operation
+               Attribute is not present, the Notification Recipient
+               SHOULD use the normal network back-off algorithms to
+               determine when to perform this operation again.
+
+      Natural Language and Character Set:
+         The "attributes-charset" and "attributes-natural-language"
+         attributes, as described in [RFC2911], section 3.1.4.2.
+
+         The Printer MUST use the values of "notify-charset" and
+         "notify-natural-language", respectively, from one Subscription
+         Object associated with the Event Notifications in this
+         response.
+
+         Normally, there is only one matched Subscription Object, or the
+         value of the "notify-charset" and "notify-natural-language"
+         attributes is the same in all Subscription Objects.  If not,
+         the Printer MUST pick one Subscription Object from which to
+         obtain the value of these attributes.  The algorithm for
+         picking the Subscription Object is implementation dependent.
+         The choice of natural language is not critical, because 'text'
+         and 'name' values can override the "attributes-natural-
+         language" operation attribute.  The Printer's choice of charset
+
+
+
+Herriot, et al.             Standards Track                    [Page 12]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+         is critical because a bad choice may leave it unable to send
+         some 'text' and 'name' values accurately.
+
+5.2.1.  notify-get-interval (integer(0:MAX))
+
+   The value of this operation attribute is the number of seconds that
+   the Notification Recipient SHOULD wait before trying the Get-
+   Notifications operation again.  The Printer MUST return this
+   operation attribute if (1) it is too busy to return events, (2) the
+   Notification Recipient client did not request Event Wait Mode, or (3)
+   the Printer is terminating Event Wait Mode.  The client MUST accept
+   this attribute and SHOULD reissue the Get-Notifications operation
+   (with or without "notify-wait" = 'true') at the indicated number of
+   seconds in the future in order to get more Event Notifications  This
+   value is intended to help the client be a good network citizen.
+
+   The value of this attribute MUST be at least as large as that of the
+   Printer's "ippget-event-life" Printer Description attribute (see
+   section 8.1).  The Printer MAY return a value that is larger than
+   that of the "ippget-event-life" Printer Description attribute
+   provided that the Printer increases the Event Life for this
+   Subscription object so that Notification Recipients taking account of
+   the larger value and polling with a longer interval will not miss
+   events.  Note:  Implementing such an algorithm requires some hidden
+   attributes in the Subscription object that are IMPLEMENTATION
+   DEPENDENT.
+
+   If the Printer wants to remain in Event Wait Mode, then the Printer
+   MUST NOT return this attribute in the response.
+
+   Here is a complete table of combinations of "notify-wait", "status-
+   code", "notify-get-interval", and Event Notification Attributes
+   Groups for Get-Notification initial (Wait and No Wait) Responses and
+   subsequent Event Wait Mode Responses (which may stay in Event Wait
+   Mode or may request the Notification Recipient to leave Event Wait
+   Mode):
+
+       Table 2.  Combinations of "notify-wait", "status-code", and
+                           "notify-get-interval"
+
+         Client sends:  Printer returns:  Printer       Event
+                                          returns:      Notification
+         "notify-wait"  "status-code"     "notify-get-  Attribute
+                                          interval"     Groups
+
+         1.  'false'*   'successful-ok'   MUST return N maybe
+         2.  'false'*   'not-found'       MUST NOT      MUST NOT
+         3.  'false'*   'busy'            MUST return N MUST NOT
+
+
+
+Herriot, et al.             Standards Track                    [Page 13]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+         4.  'false'*   'events-          MUST NOT      'job-
+                        complete'                        completed'
+         5.  'true'     'successful-ok'   MUST NOT      MUST
+         6.  'true'     'successful-ok'   MUST return N maybe
+         7.  'true'     'not-found'       MUST NOT      MUST NOT
+         8.  'true'     'busy'            MUST return N MUST NOT
+         9.  'true'     'events-          MUST NOT      'job-
+                        complete'                        completed' or
+                                                         maybe other
+         * 'false' or client omits the "notify-wait" attribute.
+
+         Explanation:
+
+         1-4:  Client does not request Event Wait Mode.
+         5-9:  Client requests Event Wait Mode.
+         2,7:  Subscription object not found, or was canceled earlier;
+               client should NOT try again.
+         3,8:  Server busy, tells client to try later; client should try
+               again in N seconds.
+         4:    Client polled after job completed, but before Event Life
+               expired, and got the 'job-completed' event, so the client
+               shouldn't bother trying again; client should NOT try
+               again later.
+         5:    Printer returns one or more Event Notifications and is OK
+               to stay in Event Wait Mode; the client waits for more
+               Event Notifications to be returned.
+         6:    Printer wants to leave Event Wait mode.  Can happen on
+               the first response (with or without Event Notifications)
+               or happen on a subsequent response with or without Event
+               Notifications; the client SHOULD try again in N seconds.
+         9:    Either (1) the printer returns 'job-completed' event, or
+               (2) the Subscription Object was canceled by either a
+               Cancel-Job or a Per-Printer Subscription expired without
+               being renewed.  For case (1), at least one Event
+               Notification MUST be returned; for case (2), it is
+               unlikely that any Event Notifications are returned, and
+               the client should NOT try again.
+
+5.2.2.  printer-up-time (integer(1:MAX))
+
+   The value of this attribute is the Printer's "printer-up-time"
+   attribute at the time when the Printer sends this response.  The
+   Printer MUST return this attribute.  Because each Event Notification
+   also contains the value of this attribute when the event occurred,
+   the value of this attribute lets a Notification Recipient know when
+   each Event Notification occurred relative to the time of this
+   response.
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 14]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Group 2: Unsupported Attributes
+         See [RFC2911], section 3.1.7, for details on returning
+         Unsupported Attributes.
+
+   Group 3 through N: Event Notification Attributes
+         The Printer responds with one Event Notification Attributes
+         Group per matched Event Notification.  The entire response is
+         considered a single Compound Event Notification (see
+         [RFC3995]).  The matched Event Notifications are all un-expired
+         Event Notifications associated with the matched Subscription
+         Objects and MUST follow the "Event Notification Ordering"
+         requirements for Event Notifications within a Compound Event
+         Notification specified in [RFC3995] section 9.  In other words,
+         the Printer MUST order these Event Notification groups in
+         ascending time stamp (and sequence number) order for a
+         Subscription object.  If Event Notifications for multiple
+         Subscription objects are being returned, the Notification
+         Events for the next Subscription object follow in ascending
+         time stamp order, etc.
+
+         Each Event Notification Group MUST contain all of attributes
+         specified in section 9.1 ("Content of Machine Consumable Event
+         Notifications") of [RFC3995], with exceptions denoted by
+         asterisks in the tables below.
+
+         The tables below are identical to those in section 9.1
+         ("Content of Machine Consumable Event Notifications") of
+         [RFC3995], except that each cell in the "Sends" column is a
+         "MUST".
+
+         If more than one Event Notification is being returned and the
+         status of each is not the same, then the Printer MUST return a
+         "notify-status-code" attribute in each Event Notification
+         Attributes group to indicate the differing status values.
+
+         For an Event Notification for all Events, the Printer includes
+         the attributes shown in Table 3.
+
+               Table 3.  Attributes in Event Notification Content
+
+   Source Value                              Sends     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(1:MAX)) *        MUST      Printer
+   printer-current-time (dateTime)           MUST **   Printer
+
+
+
+Herriot, et al.             Standards Track                    [Page 15]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   notify-sequence-number (integer (0:MAX))  MUST      Subscription
+   notify-charset (charset)                  MUST      Subscription
+   notify-natural-language (naturalLanguage) MUST      Subscription
+   notify-user-data (octetString(63))        MUST ***  Subscription
+   notify-text (text)                        MUST      Event
+                                                        Notification
+   attributes from the "notify-attributes"   MUST **** Printer
+   attribute
+   attributes from the "notify-attributes"   MUST **** Job
+   attribute
+   attributes from the "notify-attributes"   MUST **** Subscription
+   attribute
+
+      * As specified in [RFC3995] section 9, the value of the
+      "printer-up-time" attribute sent in each Event Notification
+      MUST be the time at which the Event occurred, not the time at
+      which the Event Notification was sent.
+
+      ** The Printer MUST send the "printer-current-time" attribute
+      if and only if it supports the "printer-current-time" attribute
+      on the Printer object.
+
+      *** If the associated Subscription Object does not contain a
+      "notify-user-data" attribute, the Printer MUST send an
+      octet-string of length 0.
+
+      **** If the "notify-attributes" attribute is present on the
+      Subscription Object, the Printer MUST send all attributes
+      specified by the "notify-attributes" attribute.  Note:  If the
+      Printer doesn't support the "notify-attributes" attribute, it
+      is not present on the associated Subscription Object.
+
+      For Event Notifications for Job Events, the Printer includes
+      the additional attributes shown in Table 4.
+
+     Table 4.  Additional Attributes in Event Notification Content for
+                                Job Events
+
+   Source Value                                  Sends  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
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 16]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+      *  The Printer MUST send the "job-impressions-completed" attribute
+      in an Event Notification only for the combinations of Events and
+      Subscribed Events shown in Table 5.
+
+        Table 5.  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'
+
+      For Event Notification for Printer Events, the Printer includes
+      the additional attributes shown in Table 6.
+
+     Table 6.  Additional Attributes in Event Notification Content for
+                              Printer Events
+
+   Source Value                                  Sends   Source
+   Object
+
+   printer-state (type1 enum)                    MUST    Printer
+   printer-state-reasons (1setOf type2 keyword)  MUST    Printer
+   printer-is-accepting-jobs (boolean)           MUST    Printer
+
+6.  Additional Information about Subscription Template Attributes
+
+   The 'ippget' Delivery Method does not define any addition
+   Subscription Template attributes and has the conformance requirements
+   for Subscription Template attributes defined in [RFC3995].  This
+   section defines additional information about Subscription Template
+   attributes defined in [RFC3995].
+
+6.1.  notify-pull-method (type2 keyword)
+
+   This Subscription Template attribute identifies the Pull Delivery
+   Method to be used for the Subscription Object (see [RFC3995]).  To
+   support the 'ippget' Pull Delivery Method defined in this document,
+   the Printer MUST support this attribute with the following keyword
+   value:
+
+     'ippget':  Indicates that the 'ippget' Pull Delivery Method is to
+       be used for this Subscription Object.
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 17]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+7.  Subscription Description Attributes
+
+   The 'ippget' Delivery Method has the conformance requirements for
+   Subscription Description attributes defined in [RFC3995].  The
+   'ippget' Delivery Method does not define any addition Subscription
+   Description attributes.
+
+8.  Additional Printer Description Attributes
+
+   This section defines additional Printer Description attributes for
+   use with the 'ippget' Delivery Method.
+
+8.1.  ippget-event-life (integer(15:MAX))
+
+   This Printer Description attribute specifies the Event Life value
+   that the Printer assigns to each Event; i.e., the number of seconds
+   after an Event occurs during which a Printer will return that Event
+   in an Event Notification in a Get-Notifications response.  After the
+   Event Life expires for the Event, the Printer MAY no longer return an
+   Event Notification for that Event in a Get-Notifications response.
+
+   The Printer MUST support this attribute if it supports the 'ippget'
+   Delivery Method.  The value MUST be 15 or more (at least 15 seconds),
+   and 60 (seconds) is the RECOMMENDED value to align with the PWG Job
+   Monitoring MIB [RFC2707] jmGeneralJobPersistence and
+   jmGeneralAttributePersistence objects.
+
+   For example, assume the following:
+
+   1.  A client performs a Job Creation operation that creates a
+       Subscription Object associated with the 'ippget' Delivery Method;
+
+   2.  An Event associated with the new Job occurs immediately after the
+       Subscription Object is created;
+
+   3.  the same client or some other client performs a Get-Notifications
+       operation so that the client is connected N seconds after the Job
+       Creation operation.
+
+   Then, if N is less than the value of this attribute, the client(s)
+   performing the Get-Notifications operations can expect not to miss
+   any Event-Notifications, barring some unforeseen lack of memory space
+   in the Printer.  Note:  The client MUST initiate the Get-
+   Notifications at a time that is sufficiently less that N seconds to
+   account for network latency so that it is connected to the Printer
+   before N seconds elapses.
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 18]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   If a Printer supports the 'ippget' Delivery Method, it MUST keep
+   'completed', 'canceled', or 'aborted' Job objects in the Job
+   Retention and/or Job History phases for at least as long as this
+   attribute's value.  The Printer MAY retain jobs longer that this
+   value.  See [RFC2911], section 4.3.7.1, and the discussion in
+   [RFC3995] (regarding the 'job-completed' event).  The latter explains
+   that a Notification Recipient can query the Job after receiving a
+   'job-completed' Event Notification in order to find out other
+   information about the job that is 'completed', 'aborted', or
+   'canceled'.  However, this attribute has no effect on the Cancel-
+   Subscription operation, which deletes the Subscription object
+   immediately whether or not it contains the "notify-pull-method"
+   attribute with the 'ippget' keyword value.  Immediately thereafter,
+   subsequent Get-Notifications Responses MUST NOT contain Event
+   Notifications associated with the canceled Subscription object.
+
+9.  New Values for Existing Printer Description Attributes
+
+   This section defines additional values for existing Printer
+   Description attributes as defined in [RFC3995].
+
+9.1.  notify-pull-method-supported (1setOf type2 keyword)
+
+   The following keyword value for the "notify-pull-method-supported"
+   attribute is added in order to support the new Delivery Method
+   defined in this document:
+
+      'ippget':   The IPP Notification Pull Delivery Method defined in
+        this document.
+
+9.2.  operations-supported (1setOf type2 enum)
+
+   Table 7 lists the "operation-id" value defined in order to support
+   the new Get-Notifications operation defined in this document.
+
+                    Table 7.  Operation-id Assignments
+
+      Value       Operation Name
+
+      0x001C      Get-Notifications
+
+10.  New Status Codes
+
+   The following status code is defined as an extension for this
+   Delivery Method and is returned as the status code of the Get-
+   Notifications operation in Group 1 or Group 3 to N (see section 5.2).
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 19]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+10.1.  successful-ok-events-complete (0x0007)
+
+   The Printer MUST return the 'successful-ok-events-complete' status
+   code to indicate when this Get-Notifications response is the last
+   response for a Subscription object, whether or not there are Event
+   Notifications being returned.  This condition occurs for Event Wait
+   Mode with Notification Recipients waiting for responses when (1) the
+   Subscription Object is canceled with a Cancel-Subscription operation,
+   (2) the Subscription object is deleted, when the Per-Printer
+   Subscription lease time expires, or (3) the 'job-completed' event
+   occurs for a Per-Job Subscription.  This condition also occurs for a
+   Get-Notifications request that a Notification Recipient makes after
+   the job completes, but before the Event Life expires.
+
+11.  Encoding and Transport
+
+   This section defines the encoding and transport considerations for
+   this Delivery Method based on [RFC2910].
+
+   The encoding of a Get-Notifications Response is modeled after the
+   Get-Jobs Response (see [RFC2911]).  In a Get-Notifications Response,
+   each Event Notification Attributes Group MUST start with an 'event-
+   notification-attributes-tag' (see the section "Encodings of
+   Additional Attribute Tags" in [RFC3995]), and end with an 'end-of-
+   attributes-tag'.  In addition, for Event Wait Mode the multi-
+   part/related is used to separate each multiple response (in time) to
+   a single Get-Notifications Request.
+
+   The Printer returns Get-Notification Response as follows:
+
+   1.  If the Notification Recipient client did not request Event Wait
+       Mode ("notify-wait" = 'false' or omitted), the Printer ends the
+       response with an 'end-of-attributes-tag' (see [RFC2911], Get-Jobs
+       encoding), as with any operation response.
+
+   2.  If the Notification Recipient client requests Event Wait Mode
+       ("notify-wait" = 'true') and the Printer wishes to honor the
+       request, the Printer MUST return the response as an
+       application/ipp part inside a multi-part/related MIME media type.
+       When one or more additional Events occur, the Printer returns
+       each as an additional Event Notification Group using a separate
+       application/ipp part under the multi-part/related type.
+
+   3.  If the client requested Event Wait Mode ("notify-wait" = 'true'),
+       but the Printer does not wish to honor the request in the initial
+       response and wants the client explicitly polled for Event
+       Notifications, the Printer MUST return the "notify-get-interval"
+       operation attribute (see section 5.2.1).  The Printer returns the
+
+
+
+Herriot, et al.             Standards Track                    [Page 20]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+       response as an application/ipp part that MAY be inside an multi-
+       part/related type.  The client MUST accept this response and
+       reissue the Get-Notifications request in the future indicated by
+       the value of the "notify-get-interval" attribute value.
+
+   4.  If the client requested Event Wait Mode ("notify-wait" = 'true'),
+       and the Printer initially honored the request but later wishes to
+       leave Event Wait Mode,  the Printer MUST return the "notify-get-
+       interval" operation attribute (see section 5.2.1).  The Printer
+       returns the response as an application/ipp part that MUST be
+       inside an multi-part/related type.
+
+   NOTE:  If a Notification Recipient fails to receive a response, it
+   can ask the Printer for the same Event Notifications again.  The
+   Notification Recipient will receive the same Event Notifications that
+   it should have received the first time, except for those Event
+   Notifications that have expired in the meantime.
+
+   The Printer MAY chunk the responses, but this has no significance to
+   the IPP semantics.
+
+   This notification delivery method uses the IPP transport and encoding
+   [RFC2910] for the Get-Notifications operation with the following
+   extension, allocated in [RFC3995]:
+
+          Table 8.  The "event-notification-attributes-tag" Value
+
+      Tag Value (Hex)   Meaning
+
+      0x07              "event-notification-attributes-tag"
+
+12.  Conformance Requirements
+
+   This section lists the conformance requirements for clients and
+   Printers.
+
+12.1.  Conformance for IPP Printers
+
+   It is OPTIONAL for a Printer to support IPP Notifications as defined
+   in [RFC3995].  However, if a Printer supports IPP Notifications, the
+   Printer MUST support the 'ippget' Delivery Method, as defined in this
+   document, as one of its Delivery Methods.  IPP Printers that conform
+   to this specification
+
+   1.  MUST meet the conformance requirements defined in [RFC3995] for a
+       Pull Delivery Method;
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 21]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   2.  MUST support the Get-Notifications operation defined in section
+       5, including Event Wait Mode;
+
+   3.  MUST support the Subscription Template object attributes, as
+       defined in section 6;
+
+   4.  MUST support the Subscription Description object attributes, as
+       defined in section 7;
+
+   5.  MUST support the "ippget-event-life" Printer Description
+       attribute defined in section 8.1, including retaining jobs in the
+       Job Retention and/or Job History phases for at least as long as
+       the value specified by the Printer's "ippget-event-life";
+
+   6.  MUST support the additional values for IPP/1.1 Printer
+       Description attributes defined in section 9;
+
+   7.  MUST support the 'successful-ok-events-complete' status code, as
+       described in section 10.1;
+
+   8.  MUST listen for the IPP Get-Notifications operation requests on
+       IANA-assigned well-known port 631, unless explicitly configured
+       by system administrators or site policies;
+
+   9.  SHOULD NOT listen for IPP Get-Notifications operation requests on
+       any other port, unless explicitly configured by system
+       administrators or site policies; and
+
+   10. MUST meet the security conformance requirements stated in section
+       18.4.
+
+12.2.  Conformance for IPP Clients
+
+   It is OPTIONAL for an IPP Client to support IPP Notifications as
+   defined in [RFC3995].  However, if a client supports IPP
+   Notifications, the client MUST support the 'ippget' Delivery Method
+   as defined in this document as one of its Delivery Methods.  IPP
+   Clients that conform to this specification:
+
+   1.  MUST create Subscription Objects by sending Subscription Creation
+       operation requests containing the "notify-pull-method" attribute
+       (as opposed to the "notify-recipient-uri" attribute) using the
+       'ippget' keyword value (see sections 6.1 and 15.2);
+
+   2.  MUST send IPP Get-Notifications operation requests (see section
+       5.1) via the port specified in the associated 'ipp' URL (if
+       present) or otherwise via IANA-assigned well-known port 631;
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 22]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   3.  MUST convert the associated 'ipp' URLs for use in IPP Get-
+       Notifications operation to their corresponding 'http' URL forms
+       for use in the HTTP layer, according to the rules in section 5,
+       "IPP URL Scheme", in [RFC2910]; and
+
+   4.  MUST meet the security conformance requirements stated in section
+       18.5.
+
+13.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2910]    Herriot, R., Butler, S., Moore, P., Turner, R., and J.
+                Wenn, "Internet Printing Protocol/1.1: Encoding and
+                Transport", RFC 2910, September 2000.
+
+   [RFC2911]    Hastings, T., Herriot, R., deBry, R., Isaacson, S., and
+                P. Powell, "Internet Printing Protocol/1.1: Model and
+                Semantics", RFC 2911, September 2000.
+
+   [RFC3995]   Herriot, R. and T. Hastings, "Internet Printing Protocol
+                (IPP): Event Notifications and Subscriptions", RFC 3995,
+                March 2005.
+
+14.  Informative References
+
+   [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, F., "Design Goals for an Internet Printing
+                Protocol", RFC 2567, April 1999.
+
+   [RFC2568]    Zilles, S., "Rationale for the Structure of the 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.
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 23]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   [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.
+
+   [RFC2707]    Bergman, R., Hastings, T., Isaacson, S., and H. Lewis,
+                "Job Monitoring MIB - V1.0", RFC 2707, November 1999.
+
+   [RFC3196]    Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
+                Holst, "Internet Printing Protocol/1.1: Implementor's
+                Guide", RFC 3196, November 2001.
+
+   [RFC3997]    Hastings, T., Ed., deBry, R., and H. Lewis, "Internet
+                Printing Protocol (IPP): Requirements for IPP
+                Notifications", RFC 3997, March 2005.
+
+15.  IANA Considerations
+
+   This section contains the exact information that the IANA has added
+   to the IPP Registries according to the procedures defined in
+   [RFC2911], section 6.  These registrations have been published in the
+   http://www.iana.org/assignments/ipp-registrations registry.
+
+15.1.  Attribute Registrations
+
+   The following table lists the attributes defined in this document.
+   This has been registered according to the procedures in RFC 2911
+   [RFC2911] section 6.2.
+
+   Printer Description attributes:                Reference   Section
+   -------------------------------                ---------   -------
+   ippget-event-life (integer(15:MAX))            [RFC3996]   8.1
+
+15.2.  Delivery Method and Additional Keyword Attribute Value
+       Registrations for Existing Attributes
+
+   This section lists additional keyword attribute value registrations
+   for use with existing attributes defined in other documents.  These
+   have been registered according to the procedures in [RFC2911],
+   section 6.1.  According to [RFC3995], section 24.7.3, Pull Delivery
+   Method registrations are the keyword attribute value registrations
+   for the "notify-pull-method" and "notify-pull-method-supported"
+   attributes.
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 24]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   Attribute (attribute syntax)
+     Values                                       Reference   Section
+     -----------------------                      ---------   -------
+   notify-pull-method (type2 keyword)             [RFC3995]   5.3.2
+   notify-pull-method-supported (1setOf type2 keyword)
+                                                  [RFC3995]   5.3.2.1
+     ippget                                       [RFC3996]   9.1
+
+15.3.  Additional Enum Attribute Values
+
+   The following table lists the enum attribute values defined in this
+   document.  These have been registered according to the procedures in
+   [RFC2911], section 6.1.
+
+   Attribute (attribute syntax)
+     Value    Name                                Reference   Section
+     ------   -----------------------------       ---------   -------
+   operations-supported (1setOf type2 enum)       [RFC2911]   4.4.15
+     0x001C   Get-Notifications                   [RFC3996]   9.2
+
+15.4.  Operation Registrations
+
+   The following table lists the operations defined in this document.
+   This has been registered according to the procedures in RFC 2911
+   [RFC2911] section 6.4.
+
+   Operations:                                    Reference   Section
+   -----------                                    ---------   -------
+   Get-Notifications                              [RFC3996]   5
+
+15.5.  Status Code Registrations
+
+   The following table lists the status codes defined in this document.
+   This has been registered according to the procedures in [RFC2911],
+   section 6.6.
+
+   Status codes:                                  Reference  Section
+   -------------                                  ---------  -------
+   successful-ok-events-complete (0x0007)         [RFC3996]  10.1
+
+16.  Internationalization Considerations
+
+   The IPP Printer MUST localize the "notify-text" attribute as
+   specified in section 14 of [RFC3995].
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 25]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   In addition, when the client receives the Get-Notifications response,
+   it is expected to localize the attributes that have the 'keyword'
+   attribute syntax according to the charset and natural language
+   requested in the Get-Notifications request.
+
+17.  Security Considerations
+
+   The IPP Model and Semantics document [RFC2911, section 8] discusses
+   high-level security requirements (Client Authentication, Server
+   Authentication and Operation Privacy).  The IPP Transport and
+   Encoding document [RFC2910, section 8] discusses the security
+   requirements for the IPP protocol.  Client Authentication is the
+   mechanism by which the client proves its identity to the server in a
+   secure manner.  Server Authentication is the mechanism by which the
+   server proves its identity to the client in a secure manner.
+   Operation Privacy is defined as a mechanism for protecting operations
+   from eavesdropping.
+
+   The 'ippget' Delivery Method with its Get-Notifications operations
+   leverages the security mechanism that are used in IPP/1.1 [RFC2910
+   and RFC2911] without adding any additional security mechanisms in
+   order to maintain the same security support as IPP/1.1.
+
+   The access control model for the Get-Notifications operation defined
+   in this document is the same as the access control model for the
+   Get-Job-Attributes operation (see [RFC2911], section 3.2.6).  The
+   primary difference is that a Get-Notifications operation is directed
+   at Subscription Objects rather than at Job objects, and a returned
+   attribute group contains Event Notification attributes rather than
+   Job object attributes.
+
+17.1.  Notification Recipient Client Access Rights
+
+   The Notification Recipient client MUST have the following access
+   rights to the Subscription object(s) targeted by the Get-
+   Notifications operation request:
+
+      The authenticated user (see [RFC2911], section 8.3) performing
+      this operation MUST be (1) the owner of each Subscription Object
+      identified by the "notify-subscription-ids" operation attribute
+      (see section 5.1.1), (2) an operator or administrator of the
+      Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise
+      authorized by the Printer's administrator-configured security
+      policy to request Event Notifications from the target Subscription
+      Object(s).  Furthermore, the Printer's security policy MAY limit
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 26]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+      the attributes returned by the Get-Notifications operation, in a
+      manner similar to that of the Get-Job-Attributes operation (see
+      [RFC2911], end of section 3.3.4.2).
+
+17.2.  Printer Security Threats
+
+   Because the Get-Notifications operation is sent in the same direction
+   as are Job Creation operations, usually by the same client, this
+   Event Notification Delivery Method poses no additional
+   authentication, authorization, privacy, firewall, or port assignment
+   issues above those for the IPP Get-Job-Attributes and Get-Printer-
+   Attributes operations (see [RFC2911], sections 3.2.6 and 3.2.5).
+
+17.3.  Notification Recipient Security Threats
+
+   Unwanted Events Notifications (spam):  Unlike Push Event Notification
+   Delivery Methods in which the IPP Printer initiates the Event
+   Notification, with the Pull Delivery Method defined in this document,
+   the Notification Recipient is the client that initiates the Get-
+   Notifications operation (see section 5).  Therefore, with this method
+   there is no chance of "spam" notifications.
+
+   Note:  When a client stays connected to a Printer by using the Event
+   Wait Mode (see section 5.1.3) in order to receive Event Notifications
+   as they occur, it can close down the IPP connection at any time and
+   so can avoid future unwanted Event Notifications at any time.
+
+   It is true that the client has control over whether to ask for Event
+   Notifications.  However, if the client subscribes to an event and
+   does a Get-Notifications request, it gets all events for the
+   Subscription Object in the sequence number range (see section 5.1.2),
+   not just those it wants.  If a client subscribes to a Per-Printer
+   Subscription job event, such as 'job-completed', and someone then
+   starts and cancels thousands of jobs, the client would have to
+   receive these events in addition to those it is interested in.  A
+   client can protect itself better by subscribing to its own jobs by
+   using a Per-Job Subscription, rather than create a Per-Printer
+   subscription whose Job events apply to all jobs.
+
+17.4.  Security Requirements for Printers
+
+   For the Get-Notifications operation defined in this document, the
+   same Printer conformance requirements apply for supporting and using
+   Client Authentication, Server Authentication and Operation Privacy as
+   stated in [RFC2910] section 8 for all IPP operations.
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 27]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+17.5.  Security Requirements for Clients
+
+   For the Get-Notifications operation defined in this document, the
+   same client conformance requirements apply for supporting and using
+   Client Authentication, Server Authentication, and Operation Privacy
+   as stated in [RFC2910], section 8, for all IPP operations.
+
+18.  Description of Base IPP Documents (Informative)
+
+   The base set of IPP documents includes the following:
+
+     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]
+
+   "Design Goals for an Internet Printing Protocol" takes a broad look
+   at distributed printing functionality, and it enumerates real-life
+   scenarios that help 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.
+
+   "Rationale for the Structure and Model and Protocol for the Internet
+   Printing Protocol" 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 working group's major decisions.
+
+   "Internet Printing Protocol/1.1: Model and Semantics" describes a
+   simplified model with abstract objects, their attributes, and their
+   operations that are independent of encoding and transport.  It
+   introduces a Printer and a Job object.  The Job object optionally
+   supports multiple documents per Job.  It also addresses security,
+   internationalization, and directory issues.
+
+   "Internet Printing Protocol/1.1: Encoding and Transport" is a formal
+   mapping of the abstract operations and attributes defined in the
+   model document onto HTTP/1.1 [RFC2616].  It 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.
+
+
+
+Herriot, et al.             Standards Track                    [Page 28]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+   "Internet Printing Protocol/1.1: Implementer's Guide" 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
+   processing requests is given, including error checking.  Motivation
+   for some of the specification decisions is also included.
+
+   "Mapping between LPD and IPP Protocols" gives some advice to
+   implementers of gateways between IPP and LPD (Line Printer Daemon)
+   implementations.
+
+19.  Contributors
+
+   Carl Kugler and Harry Lewis contributed the basic idea of in-band
+   "smart polling" coupled with multiple responses for a single
+   operation on the same connection, with one response for each event as
+   it occurs.  Without their continual persuasion, we would not have
+   arrived at this Delivery Method specification and would not have been
+   able to agree on a single REQUIRED Delivery Method for IPP.
+
+   Carl Kugler
+   IBM Corporation
+   6300 Diagonal Highway
+   Boulder, CO 80301
+
+   EMail: kugler@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 29]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          March 2005
+
+
+Authors' Addresses
+
+   Robert Herriot
+   Global Workflow Solutions
+   706 Colorado Ave.
+   Palo Alto, CA 94303
+
+   Phone: 650-324-4000
+   EMail: bob@herriot.com
+
+
+   Thomas N. Hastings
+   Xerox Corporation
+   710 S Aviation Blvd.  ESAE 242
+   El Segundo CA 90245
+
+   Phone: 310-333-6413
+   Fax:   310-333-6342
+   EMail: hastings@cp10.es.xerox.com
+
+
+   Harry Lewis
+   IBM Corporation
+   6300 Diagonal Hwy
+   Boulder, CO 80301
+
+   Phone: (303) 924-5337
+   EMail: harryl@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot, et al.             Standards Track                    [Page 30]
+
+RFC 3996           IPP: The 'ippget' Delivery Method          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, et al.             Standards Track                    [Page 31]
+