RFC 3995
Internet Printing Protocol (IPP): Event Notifications and Subscriptions
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.
*********************** * * 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 Client18. 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
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 Printer19. 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.
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
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.
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.
[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.
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
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.123.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.223.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.
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.323.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] 1423.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
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:
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.
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
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.n23.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:
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
[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).
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.
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
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
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.comAuthors' 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
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.