--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / thirdparty / cups.git / blobdiff