Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 3995

Internet Printing Protocol (IPP): Event Notifications and Subscriptions

Pages: 95
Proposed Standard
Updates:  29112910
Part 4 of 4 – Pages 75 to 95
First   Prev   None

Top   ToC   RFC3995 - Page 75   prevText

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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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   ToC   RFC3995 - 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.