GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3996

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3996.txt · Last modified: 2005/03/22 01:02 (external edit)