|
Network Working Group Request for Comments: 3997 Category: Informational |
T. Hastings, Ed. Xerox Corporation R. K. deBry Utah Valley State College H. Lewis IBM Corporation March 2005 Internet Printing Protocol (IPP): |
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright © The Internet Society (2005).
This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service.
1. Introduction
2. Terminology
3. Scenarios
4. Requirements
5. Security Considerations for IPP Notifications Requirements
6. Internationalization Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
9. Appendix A: Description of the Base IPP Documents
Authors' Addresses
Full Copyright Statement
This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. See section 10 for a description of the base IPP documents.
The scope of this requirements document covers functionality used by the following kinds of IPP Users: End Users, Print Administrators, and Operators. See [RFC3995] for the extensions to the Internet Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911], [RFC2910], and future versions.
It is necessary to define a set of terms to be able to clearly express the requirements for notification services in an IPP System.
A human end user who submits a print job to an IPP Printer. This person may or may not be within the same security domain as the Printer. This person may or may not be geographically near the printer.
A human user who established policy for and configures the print system.
A human user who carries out the policy established by the Administrator and controls the day-to-day running of the print system.
An application (for example, a batch application), acting on behalf of a Job Submitting End User, that submits a print job to an IPP Printer. The application may or may not be within the same security domain as the Printer. This application may or may not be geographically near the printer.
For the purposes of this discussion, the set of network components that can communicate without going through a proxy or firewall. A security domain may be geographically very large; for example, anywhere within example.com.
The software component that sends IPP requests to an IPP Printer object and accepts IPP responses from an IPP Printer.
A human who is the ultimate consumer of the print job. In many cases this will be the same person as the Job-Submitting End User, but this need not always be the case. For example, if I use IPP to print a document on a printer in a business partner's office, I am the Job- Submitting End User, and the person whom I intend the document for in my business partner's office is the Job Recipient. Since one of the goals of IPP is to be able to print near the Job Recipient, we would normally expect that person to be in the same security domain as, and geographically near, the Printer. However, this may not always be the case. For example, I submit a print job across the Internet to a XYZ's print shop. I am both the Submitting End User and the Job Recipient, but I am neither near nor in the same security domain as the Printer.
A person acting on behalf of the Job Recipient. The Job Recipient Proxy physically picks up the printed document from the Printer if the Job Recipient cannot do so. The Proxy is by definition geographically near and in the same security domain as the printer. For example, I submit a print job from home to be printed on a printer at work. I'd like my secretary to pick up the print job and put it on my desk. In this case, I am acting as both a Job- Submitting End User and a Job Recipient. My secretary is acting as a Job Recipient Proxy.
A client that requests the IPP Printer to send Event Notifications to one or more Notification Recipients. A Notification Subscriber may be a Job-Submitting End User or an End User, an Operator, or an Administrator that is not submitting a job.
The entity that sends Event Notifications.
The entity that receives IPP Notifications about Job and/or Printer events. A Notification Recipient may be a Job Submitting End User, a Job-Submitting Application, a Job Recipient, a Job Recipient Proxy, an Operator, an Administrator, etc., and his or her representative, log file, usage statistics-gathering application, or other active or passive entities.
A program that receives Event Notifications on behalf of the Notification Recipient. The agent may take some action on behalf of the recipient, forward the notification to the recipient via some alternative means (for example, page the recipient), or queue the notification for later retrieval by the recipient.
An Event is an occurrence (either expected or unexpected) within the printing system of a change of state, condition, or configuration of a Job or Printer object.
When an event occurs, an Event Notification is generated that fully describes the event (what the event was, where it occurred, when it occurred, etc.). Event Notifications are delivered to all the Notification Recipients that are subscribed to that Event, if any. The Event Notification is delivered to the address of the Notification Recipient by using the notification delivery method defined in the subscription. However, an Event Notification is sent ONLY if there is a corresponding subscription.
A Notification Subscription is a request by a Notification Subscriber to the IPP Printer to send Event Notifications to specified Notification Recipient(s) when an event occurs.
IPP Objects (for example, a print job) from which notification are being sent may have associated attributes. A user may want to have one or more of these returned along with a particular notification. In general, these may include any attribute associated with the object emitting the notification. Examples include the following:
number-of-intervening jobs
job-k-octets
job-k-octets processed
job impressions
job-impressions-interpreted
job-impressions-completed
impressionsCompletedCurrentCopy (job MIB)
sheetCompletedCopyNumber (job MIB)
sheetsCompletedDocumentNumber (job MIB)
Copies-requested
Copy-type
Output-destination
Job-state-reasons
Job ID
Printer URI
Subscription ID (for job independent subscription)
Event Notifications are delivered by using a Delivery Method. An example of a Delivery Method is email.
Notifications sent to the Notification Recipient or the Notification Recipient's agent in such a way that the notification arrives immediately, within the limits of common addressing, routing, network congestion, and quality of service.
Notifications that are not necessarily delivered to Notification Recipients immediately but are queued for delivery by an intermediate network application, for later retrieval. Email is an example of a store-and-forward notification delivery method.
Notifications that are delivered by a reliable delivery of packets or character stream, with acknowledgement and retry, so that delivery of the notification is guaranteed within determinate time limits. For example, if the Notification Recipient has logged off and gone home for the day, an immediate notification cannot be guaranteed, even when sent over a reliable transport, because there is nothing there to catch it. Guaranteed delivery requires both store-and-forward notification and a reliable transport.
Notifications are delivered via the fundamental transport address and routing framework, but no acknowledgement or retry is required. Process-to-process communications, if involved, are unconstrained.
Notifications intended to be consumed by human end users only. Email would be an example of a Human-Consumable Notification, though it could also contain Machine-Consumable Notification.
Notifications that are intended for consumption by a program only, such as an IPP Client. Machine-Consumable Notifications may not contain human-readable information. Do we need both human and machine? Machine readable is intended for application-to-application only. The Notification Recipient could process the machine-readable Event Notification into human-readable format.
A mixed notification contains both Human-Consumable and Machine- Consumable information.
- Notification Recipient: Me
- Notification Events: All
- Notification Attributes: Job-state-reason
- Notification Type: Immediate
- Notification Recipient: My secretary
- Notification Events: Print complete
- Notification Type: Immediate
- Notification Recipient: Me
- Notification Events: Print complete
- Notification Attributes: Impressions completed
- Notification Type: Store and forward
- Notification Recipient: Client at engineering firm
- Notification Events: Print complete
- Notification Type: Immediate
- Notification Language: French
- Notification Recipient: Me
- Notification Events: Print complete
- Notification Type: Store and forward
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: All state transitions
- Notification Attributes: Impression completed
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: All Printer state transitions
- Notification Attributes: Printer state, printer state
reasons, device powering up, device powering down
- Notification Recipient: Me
- Notification Type: Immediate
- Notification Events: Job completion
- Notification Attributes: Impression completed, sheets
completed, time submitted, time started, time completed, job
owner, job size in octets, etc.
state to my clients. So I subscribe to these IPP Printers for Printer events with a long-standing subscription, with myself as the Notification Recipient. When I get a Job Creation request, I decide to which IPP Printer to send the job. When I do so, I also add a job subscription for Job events, with me as the Notification Recipient to the job's job subscriptions supplied by my clients (this usage is called "piggybacking"). These IPP Printers automatically remove their job subscriptions when the job finishes, as for all job subscriptions, so that I no longer get Job events when my jobs are completed.
The following requirements are intended to be met by the IPP Notification specification (not the implementation). The following are true for the resulting IPP Notification Specification document:
- Any standard Printer MIB alert
- Job Received (transition from Unknown to Pending)
- Job Started (transition from Pending to Processing)
- Page Complete (page is stacked)
- Collated Copy Complete (last sheet of collated copy is
stacked)
- Job Complete (transition from Processing or Processing-stopped
to Completed)
- Job Aborted (transition from Pending, Pending-held,
- Processing, or Processing-stopped to Aborted)
- Job Canceled (transition from Pending, Pending-held,
- Processing, or Processing-held to Canceled)
- Other job state changes, such as paused, purged
- Device problems for which the job is destined
- Job (interpreter) issues
- any set of Job Events for a specific job, or
- any set of Printer Events while a specific job is not
complete.
- Any set of Printer Events for a defined period.
- Any set of Job Events for all jobs, with no control over
which jobs.
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.
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].
Some notification delivery methods have been registered with IANA for use in URLs. These will be defined in other documents.
[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.
[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.
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.
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
Copyright © 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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.