tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3995

 
 
 

Internet Printing Protocol (IPP): Event Notifications and Subscriptions

Part 4 of 4, p. 75 to 95
Prev RFC Part

 


prevText      Top      Up      ToC       Page 75 
17.  Distributed Model for Notification (Informative)

   A Printer implementation could use some other remote notification
   server to provide some or most of the service.  For example, the
   remote notification server could deliver Event Notifications using
   Delivery Methods that are not directly supported by the output device
   or Printer object.  Or, the remote notification server could store
   Subscription Objects (passed to it from the output device in response
   to Subscription Creation requests), accept Events, format the Event
   Notification in the natural language of the Notification Recipient,
   and deliver the Event Notifications to the Notification Recipient(s).

   Figure 3 shows this partitioning.  The interface between the output
   device (or Printer object) and the remote notification server is
   outside the scope of this document and is intended to be transparent
   to the client and this document.

Top      Up      ToC       Page 76 
                                            ***********************
                                            *
                                            * Printer in combination
                                            * with the distributed
                                            * Notification Server)
                                            *
                                            * output device or server
                                            * +---------------+
      PDA, desktop, or server               * +  ###########  +
           +--------+                       * |  #         #  |
           | client |---IPP Subscription--------># Printer #  |
           +--------+   Creation operation  * |  # Object  #  |
                                            * |  #####|#####  |
                                            * +-------|-------+
                                            *         | Subscriptions
                                            *         | OR Event
        +------------+                      *         | Notifications
        |Notification|   IPP-defined        *  +------v--------+
        |Recipient   |<--Event Notifications---| Notification  |
        +------------+                      *  | Server        |
                                            *  +---------------+
                                            *
                                            *************************
   *** = Implementation configuration opaque boundary

     Figure 3 - Opaque Use of a Notification Server Transparent to the
                                  Client

18.  Extended Notification Recipient (Informative)

   The model allows for an extended Notification Recipient that is
   itself a notification server that forwards each Event Notification to
   another recipient (called the Ultimate Notification Recipient in this
   section).  The Delivery Method to the Ultimate Recipient is probably
   different from the Delivery Method used by the Printer to the
   extended Notification Recipient.

   This extended Notification Recipient is transparent to the Printer
   but not to the client.

   When a client performs a Subscription Creation Operation, it
   specifies the extended Notification Recipient as it would any
   Notification Recipient.  In addition, the client specifies the
   Ultimate Notification Recipient in the Subscription Creation
   Operation in a manner specified by the extended Notification
   Recipient.  Typically, it is either some bytes in the value of
   "notify-user-data" or some additional parameter in the value of
   "notify-recipient-uri".  The client also subscribes directly with the

Top      Up      ToC       Page 77 
   extended Notification Recipient (by means outside this document),
   since it is a notification server in its own right.

   The IPP Printer treats the extended Notification Recipient like any
   other Notification Recipient and the IPP Printer is not aware of the
   forwarding.  The Delivery Method that the extended Notification
   Recipient uses for delivering the Event Notification to the Ultimate
   Notification Recipient is beyond the scope of this document and is
   transparent to the IPP Printer.

   Examples of this extended Notification Recipient are paging,
   immediate messaging services, general notification services, and NOS
   vendors' infrastructure.  Figure 4 shows this approach.

      PDA, desktop, or server                    server or output device
                                                      +---------------+
          +--------+                                  |  ###########  |
          | client |---Subscription Creation -----------># Printer #  |
          +--------+       Operation                  |  # Object  #  |
                                                      |  #####|#####  |
   +------------+     +------------+   IPP-defined    +-------|-------+
   |Ultimate    | any |Notification|<--Event Notifications----+
   |Notification|<----|Recipient   |
   |Recipient   |     +------------+
   +------------+     (Notification Server)

    Figure 4 - Use of an Extended Notification Recipient transparent to
                                the Printer

19.  Object Model for Notification (Normative)

   This section describes the Notification object model that adds a
   Subscription Object which together with the Job and Printer object
   provide the complete Notification semantics.

Top      Up      ToC       Page 78 
   The object relationships can be seen pictorially as:

   Subscription Objects (Per-Printer Subscriptions)     Printer object
   +----+                                               +------------+
   | s1 |<--------------------------------------------->|            |
   +----++                                              |            |
    | s2 |<-------------------------------------------->|     p1     |
    +----++                                             |            |
     | s3 |<------------------------------------------->|            |
     +----+                                             +------------+
                    Job objects
                    +---------+
                    |         |
     +----+         |   j1    |
     | s4 |<------->|         |
     +----+         |         |
                    |         |    s4 is a Per-Job Subscription Object
                    ++--------++
                     |         |
       +----+        |   j2    |
       | s5 |<------>|         |
       +----++       |         |
        | s6 |<----->|         |    s5 and s6 are Per-Job Subscription
        +----+       ++--------++                  Objects
                      |         |
                      |   j3    |
                      |         |
                      |         |         <----> indicates association
                      +---------+

               Figure 5 - Object Model for Notification

   s1, s2, and s3 are Per-Printer Subscription Objects and can identify
   Printer and/or Job Events.

   s4, s5, and s6 are Per-Job Subscription Objects and can identify
   Printer and/or Job Events.

19.1.  Object relationships

   This sub-section defines the object relationships between the
   Printer, Job, and Subscription Objects by example.  Whether Per-
   Printer Subscription Objects are actually contained in a Printer
   object or are just bi-directionally associated with them in some way
   is IMPLEMENTATION DEPENDENT and is transparent to the client.
   Similarly, whether Per-Job Subscription Objects are actually

Top      Up      ToC       Page 79 
   contained in a Job object or are just bi-directionally associated
   with them in some way is IMPLEMENTATION DEPENDENT and is transparent
   to the client.  The object relationships are defined as follows:

19.2.  Printer Object and Per-Printer Subscription Objects

   1. The Printer object contains (is associated with) zero or more
      Per-Printer Subscription Objects (p1 contains s1-s3 Per-Printer
      Subscription Objects).

   2. Each Per-Printer Subscription Object (s1, s2, and s3) is contained
      in (or is associated with) exactly one Printer object (p1).

19.3.  Job Object and Per-Job Subscription Objects

   1. A Job object (j1, j2, j3) is associated with zero or more Per-Job
      Subscription Objects (s4-s6).  Job j1 is associated with Per-Job
      Subscription Object s4, Job j2 is associated with Per-Job
      Subscription Objects s5 and s6, and Job j3 is not associated with
      any Per-Job Subscription Object.

   2. Each Per-Job Subscription Object is associated with exactly one
      Job object.

20.  Per-Job versus Per-Printer Subscription Objects (Normative)

   Per-Job and Per-Printer Subscription Objects are quite similar.
   Either type of Subscription Object can subscribe to Job Events,
   Printer Events, or both.  Both types of Subscription Objects can be
   queried using the Get-Subscriptions and Get-Subscription-Attributes
   operations and canceled using the Cancel-Subscription operation.
   Both types of Subscription Objects create Subscription Objects which
   have the same Subscription Object attributes defined.  However, there
   are some semantic differences between Per-Job Subscription Objects
   and Per-Printer Subscription Objects.  A Per-Job Subscription Object
   is established by the client when submitting a job and after creating
   the job using the Create-Job-Subscriptions operation by specifying
   the "job-id" of the Job with the "notify-job-id" attribute.  A Per-
   Printer Subscription Object is established between a client and a
   Printer using the Create-Printer-Subscriptions operation.  Some
   specific differences are:

   1. A client usually creates one or more Per-Job Subscription Objects
      as part of the Job Creation operations (Create-Job, Print-Job, and
      Print-URI), rather than using the OPTIONAL Create-Job-
      Subscriptions operation, especially since Printer implementations
      NEED NOT support the Create-Job-Subscriptions operation, since it
      is OPTIONAL.

Top      Up      ToC       Page 80 
   2. For Per-Job Subscription Objects, the Subscription Object is only
      valid while the job is "not-complete" (see sections 5.4.3) while
      for the Per-Printer Subscription Objects, the Subscription Object
      is valid until the time (in seconds) that the Printer returned in
      the "notify-lease-expiration-time" operation attribute.

   3. Job Events in a Per-Job Subscription Object apply only to "one
      job" (the Job created by the Job Creation operation or references
      by the Create-Job-Subscriptions operation) while Job Events in a
      Per-Printer Subscription Object apply to ALL jobs contained in the
      IPP Printer.

21.  Normative References

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119 , March 1997.

   [RFC2396]         Berners-Lee, T., Fielding, R., and L. Masinter,
                     "Uniform Resource Identifiers (URI): Generic
                     Syntax", RFC 2396, August 1998.

   [RFC2717]         Petke, R. and I. King, "Registration Procedures for
                     URL Scheme Names", RFC 2717, November 1999.

   [RFC2910]         Herriot, R., Butler, S., Moore, P., and R. Turner,
                     "Internet Printing Protocol/1.1: Encoding and
                     Transport", RFC 2910, September 2000.

   [RFC2911]         deBry, R., Hastings, T., Herriot, R., Isaacson, S.,
                     and P. Powell, "Internet Printing Protocol/1.1:
                     Model and Semantics", RFC 2911, September 2000.

   [RFC3381]         Hastings, T., Lewis, H., and R. Bergman, "IPP: Job
                     Progress Attributes", RFC 3381,  September 2002.

   [RFC3996]         Herriot, R., Hastings, T., and H. Lewis, "Internet
                     Printing Protocol (IPP): The 'ippget' Delivery
                     Method for Event Notifications", RFC 3996, March
                     2005.

22.  Informative References

   [IANA-CON]        Narten, T. and H. Alvestrand, "Guidelines for
                     Writing an IANA Considerations Section in RFCs",
                     BCP 26, RFC 2434, October 1998.

Top      Up      ToC       Page 81 
   [RFC2565]         Herriot, R., Butler, S., Moore, P., and R. Turner,
                     "Internet Printing Protocol/1.0: Encoding and
                     Transport", RFC 2565, April 1999.

   [RFC2566]         deBry, R., Hastings, T., Herriot, R., Isaacson, S.,
                     and P. Powell, "Internet Printing Protocol/1.0:
                     Model and Semantics", RFC 2566, April 1999.

   [RFC2567]         Wright, D., "Design Goals for an Internet Printing
                     Protocol", RFC 2567, April 1999.

   [RFC2568]         Zilles, S., "Rationale for the Structure and Model
                     and Protocol for the Internet Printing Protocol",
                     RFC 2568, April 1999.

   [RFC2569]         Herriot, R., Hastings, T., Jacobs, N., and J.
                     Martin, "Mapping between LPD and IPP Protocols",
                     RFC 2569, April 1999.

   [RFC2616]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                     Masinter, L., Leach, P., and T. Berners-Lee,
                     "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
                     June 1999.

   [RFC3196]         Hastings, T., Manros, C., Zehler, P., Kugler, C.,
                     and H. Holst, "Internet Printing Protocol/1.1:
                     Implementer's Guide", RFC 3196, November 2001.

   [RFC3997]         Hastings, T., Editor, deBry, R., and H. Lewis,
                     "Internet Printing Protocol (IPP): Requirements for
                     IPP Notifications", RFC 3997, March 2005.

23.  IANA Considerations

   This section contains the registration information that IANA added to
   the IPP Registry according to the procedures defined in RFC 2911
   [RFC2911] section 6 to cover the definitions in this document.  In
   addition, this section defines how Events and Delivery Methods will
   be registered when they are defined in other documents.  The
   resulting registrations have been published in the
   http://www.iana.org/assignments/ipp-registrations registry.

Top      Up      ToC       Page 82 
23.1.  Attribute Registrations

   The following table lists all the attributes defined in this
   document.  These have been registered according to the procedures in
   RFC 2911 [RFC2911] section 6.2.

   Subscription Template attributes:                 Reference  Section
   ---------------------------------                 ---------  -------
   notify-attributes (1setOf type2 keyword)          [RFC3995]  5.3.4
   notify-attributes-supported (1setOf type2 keyword)
                                                     [RFC3995]  5.3.4.1
   notify-charset (charset)                          [RFC3995]  5.3.6
   notify-events (1setOf type2 keyword)              [RFC3995]  5.3.3
   notify-events-default (1setOf type2 keyword)      [RFC3995]  5.3.3.1
   notify-events-supported (1setOf type2 keyword)    [RFC3995]  5.3.3.2
   notify-lease-duration (integer(0:67108863))       [RFC3995]  5.3.8
   notify-lease-duration-default (integer(0:67108863))
                                                     [RFC3995]  5.3.8.1
   notify-lease-duration-supported (1setOf (integer(0: 67108863) |
          rangeOfInteger(0:67108863)))               [RFC3995]  5.3.8.2
   notify-max-events-supported (integer(2:MAX))      [RFC3995]  5.3.3.3
   notify-natural-language (naturalLanguage)         [RFC3995]  5.3.7
   notify-pull-method (type2 keyword)                [RFC3995]  5.3.2
   notify-pull-method-supported (1setOf type2 keyword)
                                                     [RFC3995]  5.3.2.1
   notify-recipient-uri (uri)                        [RFC3995]  5.3.1
   notify-schemes-supported  (1setOf uriScheme)      [RFC3995]  5.3.1.1
   notify-time-interval (integer(0:MAX))             [RFC3995]  5.3.9
   notify-user-data (octetString(63))                [RFC3995]  5.3.5

   Subscription Description Attributes:
   notify-job-id (integer(1:MAX))                    [RFC3995]  5.4.6
   notify-lease-expiration-time (integer(0:MAX))     [RFC3995]  5.4.3
   notify-printer-up-time (integer(1:MAX))           [RFC3995]  5.4.4
   notify-printer-uri (uri)                          [RFC3995]  5.4.5
   notify-sequence-number (integer (0:MAX))          [RFC3995]  5.4.2
   notify-subscriber-user-name (name(MAX))           [RFC3995]  5.4.7
   notify-subscription-id  (integer (1:MAX))         [RFC3995]  5.4.1

   Printer Description Attributes:
   printer-state-change-date-time (dateTime)         [RFC3995]  6.2
   printer-state-change-time (integer(1:MAX))        [RFC3995]  6.1

   Attributes Only in Event Notifications
   notify-subscribed-event (type2 keyword)           [RFC3995]  8.1
   notify-text (text(MAX))                           [RFC3995]  8.2

Top      Up      ToC       Page 83 
23.2.  Additional Enum Attribute Value Registrations within the IPP
       registry

   The following table lists all the new enum attribute values defined
   in this document.  These have been registered within the IPP registry
   according to the procedures in RFC 2911 [RFC2911] section 6.1.

   Attribute
     Value      Name                                 Reference   Section
     ------     -----------------------------        ---------   -------
   operations-supported (1setOf type2 enum)          [RFC2911]   4.4.15
     0x0016     Create-Printer-Subscriptions         [RFC3995]   7.1
     0x0017     Create-Job-Subscriptions             [RFC3995]   7.1
     0x0018     Get-Subscription-Attributes          [RFC3995]   7.1
     0x0019     Get-Subscriptions                    [RFC3995]   7.1
     0x001A     Renew-Subscription                   [RFC3995]   7.1
     0x001B     Cancel-Subscription                  [RFC3995]   7.1

23.3.  Operation Registrations

   The following table lists all of the operations defined in this
   document.  These have been registered according to the procedures in
   RFC 2911 [RFC2911] section 6.4.

   Operation Name                                    Reference   Section
   ---------------------------------                 ---------   -------
   Cancel-Subscription                               [RFC3995]   11.2.7
   Create-Job - Extensions                           [RFC3995]   11.1.3
   Create-Job-Subscriptions                          [RFC3995]   11.1.1
   Create-Printer-Subscriptions                      [RFC3995]   11.1.2
   Get-Printer-Attributes - Extensions               [RFC3995]   11.2.3
   Get-Subscription-Attributes                       [RFC3995]   11.2.4
   Get-Subscriptions                                 [RFC3995]   11.2.5
   Print-Job - Extensions                            [RFC3995]   11.1.3
   Print-URI - Extensions                            [RFC3995]   11.1.3
   Renew-Subscription                                [RFC3995]   11.2.6
   Validate-Job Operation - Extensions               [RFC3995]   11.2.2

23.4.  Status code Registrations

   The following table lists all the status codes defined in this
   document.  These have been registered according to the procedures in
   RFC 2911 [RFC2911] section 6.6.

Top      Up      ToC       Page 84 
   Value    Status Code Name                        Reference  Section
   -----    ----------------------------            ---------  -------
   0x0000:0x00FF - Successful:
   0x0003   successful-ok-ignored-subscriptions     [RFC3995]  12.1
   0x0005   successful-ok-too-many-events           [RFC3995]  13.4

   0x0400:0x04FF - Client Error:
   0x0414   client-error-ignored-all-subscriptions  [RFC3995]  12.2
   0x0415   client-error-too-many-subscriptions     [RFC3995]  13.3

23.5.  Attribute Group tag Registrations

   The following table lists all the attribute group tags defined in
   this document.  These have been registered according to the
   procedures in RFC 2911 [RFC2911] section 6.5.

   Value    Attribute Group Tag Name                 Reference  Section
   -----    --------------------------------         --------   -------
   0x06     subscription-attributes-tag              [RFC3995]  14
   0x07     event-notification-attributes-tag        [RFC3995]  14

23.6.  Registration of Events

   The following table lists all the Events defined in this document as
   type2 keywords to be used with the "notify-events", "notify-events-
   default", and "notify-events-supported" Subscription Template
   attributes (see section 5.3.3)).  Rather than creating a separate
   section in the IPP Registry for Events, these event keywords have
   been registered according to the procedures of [RFC2911] section 7.1
   as additional keyword attribute values for use with the "notify-
   events" Subscription Template attribute (see section 5.3.3), i.e.,
   registered as keyword values for the "notify-events", "notify-
   events-default", and "notify-events-supported" attributes:

   Attribute (attribute syntax)
     Value                                          Reference  Section
     ---------------------                          ---------  -------
   notify-events (1setOf type2 keyword)             [RFC3995]  5.3.3
   notify-events-default (1setOf type2 keyword)     [RFC3995]  5.3.3.1
   notify-events-supported (1setOf type2 keyword)   [RFC3995]  5.3.3.2
   notify-subscribed-event (type2 keyword)          [RFC3995]  8.1
     No Events:
       none                                         [RFC3995]  5.3.3.4.1
     Printer Events:
       printer-state-changed                        [RFC3995]  5.3.3.4.2
       printer-restarted                            [RFC3995]  5.3.3.4.2
       printer-shutdown                             [RFC3995]  5.3.3.4.2
       printer-stopped                              [RFC3995]  5.3.3.4.2

Top      Up      ToC       Page 85 
       printer-config-changed                       [RFC3995]  5.3.3.4.2
       printer-media-changed                        [RFC3995]  5.3.3.4.2
       printer-finishings-changed                   [RFC3995]  5.3.3.4.2
       printer-queue-order-changed                  [RFC3995]  5.3.3.4.2
     Job Events:
       job-state-changed                            [RFC3995]  5.3.3.4.3
       job-created                                  [RFC3995]  5.3.3.4.3
       job-completed                                [RFC3995]  5.3.3.4.3
       job-stopped                                  [RFC3995]  5.3.3.4.3
       job-config-changed                           [RFC3995]  5.3.3.4.3
       job-progress                                 [RFC3995]  5.3.3.4.3

23.7.  Registration of Event Notification Delivery Methods

   This section describes the requirements and procedures for
   registration and publication of Event Notification Delivery Methods
   and for the submission of such proposals.

23.7.1.  Requirements for Registration of Event Notification Delivery
         Methods

   Registered IPP Event Notification Delivery Methods are expected to
   follow a number of requirements described below.

23.7.1.1.  Required Characteristics

   A Delivery Method Document MUST either (1) contain all of the
   semantics of the Delivery Method or (2) contain the IPP Delivery
   Method registration requirements and a profile of some other protocol
   that in combination is the Delivery Method (e.g., mailto).  The
   Delivery Method Document (and any documents it requires) MUST define
   either (1) a URL for a Push Delivery Method that the meets the
   requirements of [RFC2717].  or (2) a keyword for a Pull Delivery
   method.

   IPP Event Notification Delivery Method Documents MUST meet the
   requirements of this document (see sections 9 and 10).

   In addition, a Delivery Method Document MUST contain the following
   information:

      Type of registration:  IPP Event Notification Delivery Method
      Name of this delivery method:
      Proposed URL scheme name of this Push Delivery Method or the
      keyword name of this Pull Delivery Method:
      Name of proposer:
      Address of proposer:

Top      Up      ToC       Page 86 
      Email address of proposer:
      Is this delivery method REQUIRED or OPTIONAL for conformance to
      the IPP Event Notification and Subscriptions document:
      Is this delivery method defining Machine Consumable and/or Human
      Consumable content:

23.7.1.2.  Naming Requirements

   Exactly one (URL scheme or keyword) name MUST be assigned to each
   Delivery Method.

   Each assigned name MUST uniquely identify a single Delivery Method.
   All Push Delivery Method names MUST conform to the rules for URL
   scheme names, according to [RFC2396] and [RFC2717] for schemes in the
   IETF tree.  All Pull Delivery Method names MUST conform to the rules
   for keywords according to [RFC2911].

23.7.1.3.  Functionality Requirements

   Delivery Methods MUST function as a protocol that is capable of
   delivering (push or pull) IPP Event Notifications to Notification
   Recipients.

23.7.1.4.  Usage and Implementation Requirements

   Use of a large number of Delivery Methods may hamper
   interoperability.  However, the use of a large number of undocumented
   and/or unlabeled Delivery Methods hampers interoperability even more.

   A Delivery Method should therefore be registered ONLY if it adds
   significant functionality that is valuable to a large community, OR
   if it documents existing practice in a large community.  Note that
   Delivery Methods registered for the second reason should be
   explicitly marked as being of limited or specialized use and should
   only be used with prior bilateral agreement.

23.7.1.5.  Publication Requirements

   Delivery Method Documents MUST be published in a standards track,
   informational, or experimental RFCs.

23.7.2.  Registration Procedure

   The IPP WG is developing a small number of Delivery Methods which are
   intended to be published as standards track RFCs.  However, some
   parties may wish to register additional Delivery Methods in the
   future.  This section describes the procedures for these additional
   Delivery Methods.

Top      Up      ToC       Page 87 
23.7.2.1.  Present the proposal to the Community

   First the Delivery Method Document MUST be an Internet-Draft with a
   target category of standards track, informational, or experimental.
   The same MUST be true for any documents that it references.

   Deliver the proposed Delivery Method Document proposal to the
   "ipp@pwg.org" mailing list.  This mailing list has been established
   by [RFC2911] for reviewing proposed registrations and discussing
   other IPP matters.  Proposed Delivery Method Documents are not
   formally registered and MUST NOT be used until approved.

   The intent of the public posting is to solicit comments and feedback
   on the definition and suitability of the Delivery Method and the name
   chosen for it over a four week period.

23.7.2.2.  Delivery Method Reviewer

   The Delivery Method Reviewer is the same person who has been
   appointed by the IETF Application Area Director(s) as the IPP
   Designated Expert according to [RFC2911] and [IANA-CON].  When the
   four week period is over and the IPP Designated Expert is convinced
   that consensus has been achieved, the IPP Designated Expert either
   approves the request for registration or rejects it.  Rejection may
   occur because of significant objections raised on the list or
   objections raised externally.

   Decisions made by the Reviewer must be posted to the ipp@pwg.org
   mailing list within 14 days.  Decisions made by the Reviewer may be
   appealed to the IESG.

23.7.2.3.  IANA Registration

   Provided that the Delivery Method registration proposal has either
   passed review or has been successfully appealed to the IESG, the IANA
   will be notified by the delivery method reviewer and asked to
   register the Delivery Method and make it available to the community.

23.7.3.  Delivery Method Document Registrations

   Each Push Delivery Method Document defines a URI scheme.  Such a URI
   scheme is used in a URI value of the "notification-recipient" (uri)
   Subscription Template attribute (see section 5.3.1) and the uriScheme
   value of the "notify-schemes-supported" (1setOf uriScheme 5.3.1.1)
   Printer attribute(see section ).  Rather than creating a separate
   section in the IPP Registry for Delivery Methods, Push Delivery
   Methods will be registered as an additional value of the "notify-
   schemes-supported" Printer attribute.  These uriScheme values will be

Top      Up      ToC       Page 88 
   registered according to the procedures of [RFC2911] section 7.1 for
   additional attribute values.  Therefore, the IPP Registry entry for a
   Push Delivery Method will be of the form:

   Attribute
     Value                                        Ref.       Section
     ---------------------                        --------   -------
   notify-schemes-supported (1setOf uriScheme)    [RFC3995]  5.3.1.1
     <scheme name>                                RFC xxxx   m.n

   Each Pull Delivery Method Document defines a keyword method which is
   registered as an additional value of the "notify-pull-method" and
   "notify-pull-method-supported" Printer attributes.  These keyword
   values will be registered according to the procedures of [RFC2911]
   section 7.1 for additional attribute values.  Therefore, the IPP
   Registry entry for a Pull Delivery Method will be of the form:

   Attribute
     Value                                        Ref.       Section
     ---------------------                        --------   -------
   notify-pull-method (type2 keyword)             [RFC3995]  5.3.2
   notify-pull-method-supported (1setOf type2 keyword)
                                                  [RFC3995]  5.3.2.1
     <method keyword name>                        RFC xxxx    m.n

23.7.4.  Registration Template

   To: ipp@pwg.org
   Subject: Registration of a new Delivery Method

   Delivery Method name:

   (All Push Delivery Method names must be suitable for use as the value
   of a URL scheme in the IETF tree and all Pull Delivery Method names
   must be suitable IPP keywords according to [RFC2911])

   Published specification(s):

   (A specification for the Delivery Method must be openly available
   that accurately describes what is being registered.)

   Person & email address to contact for further information:

Top      Up      ToC       Page 89 
24.  Internationalization Considerations

   This IPP Notification specification continues support for the
   internationalization of [RFC2911] of attributes containing text
   strings and names.  Allowing a Subscribing Client to specify a
   different natural language and charset for each Subscription Object
   increases the internationalization support.

   The Printer MUST be able to localize the content of Human Consumable
   Event Notifications and to localize the value of "notify-text"
   attribute in Machine Consumable Event Notifications that it delivers
   to Notification Recipients.  For localization, the Printer MUST use
   the value of the "notify-charset" attribute and the "notify-natural-
   language" attribute in the Subscription Object supplied by the
   Subscribing Client.

25.  Security Considerations

   Clients submitting Notification requests to the IPP Printer have the
   same security issues as submitting an IPP/1.1 print job request (see
   [RFC2911] section 3.2.1 and section 8).  The same mechanisms used by
   IPP/1.1 can therefore be used by the client Notification submission.
   Operations that require authentication can use the HTTP
   authentication.  Operations that require privacy can use the HTTP/TLS
   privacy.  As with IPP/1.1 Print Job Objects, if there is no security
   on Subscription Objects, sequential assignment of subscription-ids
   exposes the system to a passive traffic monitoring threat.

25.1.  Client access rights

   The Subscription Object access control model is the same as the
   access control model for Job objects.  The client MUST have the
   following access rights for the indicated Subscription operations:

   1. Create-Job-Subscriptions (see section 11.1.1):  A Per-Job
      Subscription object is associated with a Job.  To create Per-Job
      Subscription Objects, the authenticated user (see [RFC2911]
      section 8.3) performing this operation MUST (1) be the job owner,
      (2) have Operator or Administrator access rights for this Printer
      (see [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized
      by the Printer's administrator-configured security policy to
      create Per-Job Subscription Objects for the target job.

   2. Create-Printer-Subscriptions (see section 11.1.2):  A Per-Printer
      Subscription object is associated with the Printer.  To create
      Per-Printer Subscription Objects, the authenticated user (see
      [RFC2911] section 8.3) performing this operation MUST (1) have
      Operator or Administrator access rights for this Printer (see

Top      Up      ToC       Page 90 
      [RFC2911] sections 1 and 8.5) or (2) be otherwise authorized by
      the Printer's administrator-configured security policy to create
      Per-Printer Subscription Objects for this Printer.

   3. Get-Subscription-Attributes (see section 11.2.4):  The access
      control model for this operation is the same as that of the Get-
      Job-Attributes operation (see [RFC2911] section 3.3.4).  The
      primary difference is that a Get-Subscription-Attributes operation
      is directed at a Subscription Object rather than at a Job object,
      and a returned attribute group contains Subscription Object
      attributes rather than Job object attributes.  To query the
      specified Subscription Object, the authenticated user (see
      [RFC2911] section 8.3) performing this operation MUST (1) be the
      Subscription Object owner, (2) have Operator or Administrator
      access rights for this Printer (see [RFC2911] sections 1 and 8.5),
      or (3) be otherwise authorized by the Printer's administrator-
      configured security policy to query the Subscription Object for
      the target job.  Furthermore, the Printer's security policy MAY
      limit which attributes are returned, in a manner similar to the
      Get-Job-Attributes operation (see [RFC2911] end of section
      3.3.4.2).

   4. Get-Subscriptions (see section 11.2.5):  The access control model
      for this operation is the same as that of the Get-Jobs operation
      (see [RFC2911] section 3.2.6).  The primary difference is that the
      operation is directed at Subscription Objects rather than at Job
      objects, and the returned attribute groups contain Subscription
      Object attributes rather than Job object attributes.  To query
      Per-Job Subscription Objects of the specified job (client supplied
      the "notify-job-id" operation attribute - see section 11.2.5.1.1),
      the authenticated user (see [RFC2911] section 8.3) performing this
      operation MUST (1) be the Subscription Object owner, (2) have
      Operator or Administrator access rights for this Printer (see
      [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
      the Printer's administrator-configured security policy to query
      the Subscription Object for the target job.  To query Per-Printer
      Subscription Objects of the Printer (client omits the "notify-
      job-id" operation attribute - see section 11.2.5.1.1), the
      authenticated user (see [RFC2911] section 8.3) performing this
      operation MUST (1) have Operator or Administrator access rights
      for this Printer (see [RFC2911] sections 1 and 8.5), or (2) be
      otherwise authorized by the Printer's administrator-configured
      security policy to query Per-Printer Subscription Objects for the
      target Printer.  Furthermore, the Printer's security policy MAY
      limit which attributes are returned, in a manner similar to the
      Get-Job-Attributes operation (see [RFC2911] end of section
      3.2.6.2).

Top      Up      ToC       Page 91 
   5. Renew-Subscriptions (see section 11.2.6):  The authenticated user
      (see [RFC2911] section 8.3) performing this operation MUST (1) be
      the owner of the Per-Printer Subscription Object, (2) have
      Operator or Administrator access rights for the Printer (see
      [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
      the Printer's administrator-configured security policy to renew
      Per-Printer Subscription Objects for the target Printer

   6. Cancel-Subscription (see section 11.2.7):  The authenticated user
      (see [RFC2911] section 8.3) performing this operation MUST (1) be
      the owner of the Subscription Object, (2) have Operator or
      Administrator access rights for the Printer (see [RFC2911]
      sections 1 and 8.5), or (3) be otherwise authorized by the
      Printer's administrator-configured security policy to cancel the
      target Subscription Object.

   The standard security concerns (delivery to the right user, privacy
   of content, tamper proof content) apply to each Delivery Method.
   Some Delivery Methods are more secure than others.  Each Delivery
   Method Document MUST discuss its Security Considerations.

25.2.  Printer security threats

   Notification trap door:  If a Printer supports the OPTIONAL "notify-
   attributes" Subscription Template attribute (see section 5.3.4) where
   the client can request that the Printer return any specified Job,
   Printer, and Subscription object attributes, the Printer MUST apply
   the same security policy to these requested attributes in the Get-
   Notifications request as it does for the Get-Jobs, Get-Job-
   Attributes, Get-Printer-Attributes, and Get-Subscription-Attributes
   requests.

25.3.  Notification Recipient security threats

   Unwanted Events Notifications (spam):  For any Push Delivery Method,
   by far the biggest security concern is the abuse of notification:
   delivering unwanted Event Notifications to third parties (i.e.,
   spam).  The problem is made worse by notification addresses that may
   be redistributed to multiple parties.  There exist scenarios where
   third party notification is used (see Scenario #2 and #3 in
   [RFC3997]).  Any fully secure solution would require active agreement
   of all recipients before delivering anything.

Top      Up      ToC       Page 92 
26.  Description of the base IPP documents (Informative)

   The base set of IPP documents includes:

   Design Goals for an Internet Printing Protocol [RFC2567]
   Rationale for the Structure and Model and Protocol for the Internet
      Printing Protocol [RFC2568]
   Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
   Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
   Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
   Mapping between LPD and IPP Protocols [RFC2569]

   The "Design Goals for an Internet Printing Protocol" document takes a
   broad look at distributed printing functionality, and it enumerates
   real-life scenarios that help to clarify the features that need to be
   included in a printing protocol for the Internet.  It identifies
   requirements for three types of users: end users, operators, and
   administrators.  It calls out a subset of end user requirements that
   are satisfied in IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator
   operations have been added to IPP/1.1 [RFC2911, RFC2910].

   The "Rationale for the Structure and Model and Protocol for the
   Internet Printing Protocol" document describes IPP from a high level
   view, defines a roadmap for the various documents that form the suite
   of IPP specification documents, and gives background and rationale
   for the IETF IPP working group's major decisions.

   The "Internet Printing Protocol/1.1: Model and Semantics" document
   describes a simplified model with abstract objects, their attributes,
   and their operations.  The model introduces a Printer and a Job.  The
   Job supports multiple documents per Job.  The model document also
   addresses how security, internationalization, and directory issues
   are addressed.

   The "Internet Printing Protocol/1.1: Encoding and Transport" document
   is a formal mapping of the abstract operations and attributes defined
   in the model document onto HTTP/1.1 [RFC2616].  It also defines the
   encoding rules for a new Internet MIME media type called
   "application/ipp".  This document also defines the rules for
   transporting over HTTP a message body whose Content-Type is
   "application/ipp".  This document defines the 'ipp' scheme for
   identifying IPP printers and jobs.

   The "Internet Printing Protocol/1.1: Implementer's Guide" document
   gives insight and advice to implementers of IPP clients and IPP
   objects.  It is intended to help them understand IPP/1.1 and some of
   the considerations that may assist them in the design of their client
   and/or IPP object implementations.  For example, a typical order of

Top      Up      ToC       Page 93 
   processing requests is given, including error checking.  Motivation
   for some of the specification decisions is also included.

   The "Mapping between LPD and IPP Protocols" document gives some
   advice to implementers of gateways between IPP and LPD (Line Printer
   Daemon) implementations.

27.  Contributors

   The following people made significant contributions to the design and
   review of this specification:

   Scott A.  Isaacson
   Novell, Inc.
   122 E 1700 S
   Provo, UT  84606

   Phone: 801-861-7366
   Fax:   801-861-2517
   EMail: sisaacson@novell.com


   Roger deBry
   Utah Valley State College
   Orem, UT 84058

   Phone: 801-863-8848
   EMail: debryro@uvsc.edu


   Jay Martin
   Underscore Inc.
   9 Jacqueline St.
   Hudson, NH 03051-5308

   Phone: 603-889-7000
   Fax:   775-414-0245
   EMail: jkm@underscore.com


   Michael Shepherd
   Xerox Corporation
   800 Phillips Road  MS 128-51E
   Webster, NY  14450

   Phone: 716-422-2338
   Fax:   716-265-8871
   EMail: mshepherd@usa.xerox.com

Top      Up      ToC       Page 94 
   Ron Bergman
   Ricoh Printing Systems America
   1757 Tapo Canyon Road
   Simi Valley, CA 93063-3394

   Phone: 805-578-4421
   Fax:   805-578-4001
   EMail: ron.bergman@rpsa.ricoh.com

Authors' Addresses

   Robert Herriot
   Global Workflow Solutions
   706 Colorado Ave.
   Palo Alto, CA 94303

   Phone:  650-324-4000
   EMail:  bob@herriot.com


   Tom Hastings
   Xerox Corporation
   701 S Aviation Blvd, ESAE 242
   El Segundo, CA  90245

   Phone: 310-333-6413
   Fax:   310-333-6342
   EMail: hastings@cp10.es.xerox.com

Top      Up      ToC       Page 95 
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.