- Device problems for which the job is destined
- Job (interpreter) issues
5. It must define how an End User or Operator subscribes for
- any set of Job Events for a specific job, or
- any set of Printer Events while a specific job is not
complete.
6. It must define how an End User or Operator subscribes for the
following without having to submit a Job:
- Any set of Printer Events for a defined period.
- Any set of Job Events for all jobs, with no control over
which jobs.
7. It must define how the Notification Subscriber is able to
specify either immediate or store-and-forward notification
independently for each Notification Recipient. The means may be
explicit, or implied by the method of delivery chosen by the Job
Submitting End User.
8. It must define common delivery methods: e.g., email.
9. It must define how an IPP Printer validates its ability to
deliver an Event by using the specified delivery scheme. If it
does not support the specified scheme, or if the specified
scheme is invalid for some reason, then the IPP Printer accepts
and performs the request anyway and indicates the unsupported
attribute values. There is no requirement for the IPP Printer
receiving the print request to validate the identity of a
Notification Recipient, or the ability of the system to deliver
an event to that recipient as requested (for example, if the
Notification Recipient is not at work today).
10. It must define a class of IPP event notification delivery
methods that can flow through corporate firewalls. However, an
IPP printer need not test to guarantee delivery of the
notification through a firewall before accepting a print job.
11. It may define a means to deliver a notification to the
submitting client when the delivery of an event notification to
a specified Notification Recipient fails. A fallback means of
subscribers to determine whether notifications have failed
(i.e., polling) may be provided.
12. It must define a mechanism for localizing Human-Consumable
Notifications by the Notification Source.
13. It may define a way to specify whether event delivery requires
acknowledgement back to the Notification Source.
14. There must be a mechanism defined so that job-independent
subscriptions do not become stale and do not require human
intervention to be removed. However, a subscription must not be
deemed stale only if it is unable to deliver an Event
Notification, as temporary Notification delivery problems must
be tolerated.
15. A mechanism must be defined so that an Event Subscriber is able
to add an Event Subscription to a Job after the Job has been
submitted.
16. A mechanism must be defined so that a client is able to cancel
an Event Subscription on a job or printer after the job has been
submitted.
17. A mechanism must be defined so that a client can obtain the set
of current Subscriptions.
5. Security Considerations for IPP Notifications Requirements
By far the biggest security concern is the abuse of notification:
sending unwanted notifications sent to third parties (i.e., spam).
The problem is made worse by notification addresses that may be
redistributed to multiple parties (e.g., mailing lists). Scenarios
exist in which third-party notification is required (see scenarios 2
and 3). The fully secure solution would require active agreement of
all recipients before anything is sent out. However, requirement 9
("There is no requirement for an IPP Printer receiving the print
request to validate the identity of an event recipient") argues
against this. Certain systems may decide to disallow third-party
notifications (a traditional fax model).
The same security issues are present when Clients submit notification
requests to the IPP Printer as when they submit an IPP/1.1 print job
request. 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.
The notification access control model should be similar to the IPP
access control model. Creating a notification subscription is
associated with a user. Only the creator or an operator can cancel
the subscription. The system may limit the listing of items to items
owned by the user. Some subscriptions (e.g., those that have a
lifetime longer than a job) can be done only by privileged users
(operators and/or administrators), if that is the authorization
policy.
The standard security concerns (delivery to the right user, privacy
of content, tamper-proof content) apply to the notification delivery.
IPP should use the security mechanism of the delivery method used.
Some delivery mechanisms are more secure than others. Therefore,
sensitive notifications should use the delivery method that has the
strongest security.
6. Internationalization Considerations
The Human-Consumable Notification must be localized to the natural
language and charset that Notification Subscriber specifies within
the choice of natural languages and charsets that the IPP Printer
supports.
The Machine-Consumable Notification data uses the "application/ipp"
MIME media type. It contains attributes whose text values are
required to be in the natural language and charset that the
Notification Subscriber specifies within the choice of natural
languages and charsets that the IPP Printer supports. See [RFC2566].
7. IANA Considerations
Some notification delivery methods have been registered with IANA for
use in URLs. These will be defined in other documents.
8. References
8.1. Normative References
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and
P. Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC 2911, September 2000.
[RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol
(IPP): Event Notifications and Subscriptions", RFC 3995,
March 2005.
8.2. Informative References
[RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner,
"Internet Printing Protocol/1.0: Encoding and Transport",
RFC 2565, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2567] Wright, F., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure of the Model and
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569, April
1999.
[RFC2639] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
Holst, "Internet Printing Protocol/1.1: Implementor’s
Guide", RFC 3196, November 2001.
9. Appendix A: Description of the Base IPP Documents
The base set of IPP documents includes the following:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer’s Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]
"Design Goals for an Internet Printing Protocol" takes a broad look
at distributed printing functionality, and it enumerates real-life
scenarios that help clarify the features that need to be included in
a printing protocol for the Internet. It identifies requirements for
three types of users: end users, operators, and administrators. It
calls out a subset of end-user requirements that are satisfied in
IPP/1.0 [RFC2566], [RFC2565]. A few OPTIONAL operator operations
have been added to IPP/1.1 [RFC2911], [RFC2910].
"Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol" describes IPP from a high-level view, defines a
roadmap for the various documents that form the suite of IPP
specification documents, and gives background and rationale for the
IETF IPP working group’s major decisions.
"Internet Printing Protocol/1.1: Model and Semantics" describes a
simplified model with abstract objects, their attributes, and their
operations. The model introduces a Printer and a Job. The Job
supports multiple documents per Job. The model document also
addresses security, internationalization, and directory issues.
"Internet Printing Protocol/1.1: Encoding and Transport" is a formal
mapping of the abstract operations and attributes defined in the
model document onto HTTP/1.1 [RFC2616]. It 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.
"Internet Printing Protocol/1.1: Implementer’s Guide" gives insight
and advice to implementers of IPP clients and IPP objects. It is
intended to help them understand IPP/1.1 and some of the
considerations that may assist them in the design of their client
and/or IPP object implementations. For example, a typical order of
processing requests is given, including error checking. Motivation
for some of the specification decisions is also included.
"Mapping between LPD and IPP Protocols" gives some advice to
implementers of gateways between IPP and LPD (Line Printer Daemon )
implementations.
Authors’ Addresses
Tom Hastings (editor)
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
Roger deBry
Utah Valley State College
Phone: (801) 863-8848
EMail: debryro@uvsc.edu
Harry Lewis
IBM Corporation
6300 Diagonal Hwy
Boulder, CO 80301
Phone: (303) 924-5337
EMail: harryl@us.ibm.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.