draft-ietf-ipp-not-07.txt   rfc3997.txt 
Internet Printing Protocol WG Tom Hastings (editor) Network Working Group T. Hastings, Ed.
INTERNET DRAFT Xerox Corporation Request for Comments: 3997 Xerox Corporation
<draft-ietf-ipp-not-07.txt> Roger K deBry Category: Informational R. K. deBry
[Target Category: Informational] Utah Valley State College Utah Valley State College
Expires: December 21, 2004 Harry Lewis H. Lewis
IBM Corporation IBM Corporation
June 21, 2004 March 2005
Internet Printing Protocol (IPP): Requirements for IPP Notifications
Copyright (C) The Internet Society (2001). All Rights Reserved.
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ''work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html.
ABSTRACT
This document is one of a set of documents which together describe
all aspects of a new 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.
Table of Contents
1 Scope............................................................3
2 Terminology......................................................3
3 Scenarios........................................................7 Internet Printing Protocol (IPP):
Requirements for IPP Notifications
4 Requirements....................................................10 Status of This Memo
5 Security considerations for IPP Notifications requirements......13 This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
6 Internationalization Considerations.............................14 Copyright Notice
7 IANA Considerations.............................................14 Copyright (C) The Internet Society (2005).
8 References......................................................14 Abstract
9 Author's Address................................................15 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.
10 Appendix A: Description of the Base IPP Documents..............15 Table of Contents
11 Appendix B: Full Copyright Statement...........................16 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations for IPP Notifications Requirements. . 12
6. Internationalization Considerations . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References. . . . . . . . . . . . . . . . . . 14
8.2. Informative References. . . . . . . . . . . . . . . . . 14
9. Appendix A: Description of the Base IPP Documents . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
1 Scope 1. Introduction
This document is one of a set of documents which together describe This document is one of a set of documents that together describe all
all aspects of a new Internet Printing Protocol (IPP). IPP is an aspects of the Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing application level protocol that can be used for distributed printing
on the Internet. There are multiple parts to IPP, but the primary on the Internet. There are multiple parts to IPP, but the primary
architectural components are the Model, the Protocol and an interface architectural components are the Model, the Protocol, and an
to Directory Services. This document provides a statement of the interface to Directory Services. This document provides a statement
requirements for notifications as an optional part of an IPP Service. of the requirements for notifications as an optional part of an IPP
See section 10 for a description of the base IPP documents. Service. See section 10 for a description of the base IPP documents.
The scope of this requirements document covers functionality used by The scope of this requirements document covers functionality used by
the following kinds of IPP Users: End Users, Print Administrators and the following kinds of IPP Users: End Users, Print Administrators,
Operators. See [ipp-ntfy] for the extensions to the Internet and Operators. See [RFC3995] for the extensions to the Internet
Printing Protocol/1.0 (IPP) [RFC2565, RFC2566], IPP/1.1 [RFC2911, Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911],
RFC2910], and future versions. [RFC2910], and future versions.
2 Terminology 2. Terminology
It is necessary to define a set of terms in order to be able to It is necessary to define a set of terms to be able to clearly
clearly express the requirements for notification services in an IPP express the requirements for notification services in an IPP System.
System.
2.1 Job Submitting End User 2.1. Job-Submitting End User
A human end user who submits a print job to an IPP Printer. This 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 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. This person may or may not be geographically near the
printer. printer.
2.2 Administrator 2.2. Administrator
A human user who established policy for and configures the print A human user who established policy for and configures the print
system. system.
2.3 Operator 2.3. Operator
A human user who carries out the policy established by the A human user who carries out the policy established by the
Administrator and controls the day to day running of the print Administrator and controls the day-to-day running of the print
system. system.
2.4 Job Submitting Application 2.4. Job-Submitting Application
An application (for example, a batch application), acting on behalf An application (for example, a batch application), acting on behalf
of a Job Submitting End User, which submits a print job to an IPP 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 Printer. The application may or may not be within the same security
domain as the Printer. This application may or may not be domain as the Printer. This application may or may not be
geographically near the printer. geographically near the printer.
2.5 Security Domain 2.5. Security Domain
For the purposes of this discussion, the set of network components For the purposes of this discussion, the set of network components
which can communicate without going through a proxy or firewall. A that can communicate without going through a proxy or firewall. A
security domain may be geographically very large, for example - security domain may be geographically very large; for example,
anyplace within example.com. anywhere within example.com.
2.6 IPP Client 2.6. IPP Client
The software component that sends IPP requests to an IPP Printer The software component that sends IPP requests to an IPP Printer
object and accepts IPP responses from an IPP Printer. object and accepts IPP responses from an IPP Printer.
2.7 Job Recipient 2.7. Job Recipient
A human who is the ultimate consumer of the print job. In many cases 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 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 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 document on a printer in a business partner's office, I am the Job-
Submitting End User, while the person I intend the document for in my Submitting End User, and the person whom I intend the document for in
business partner's office is the Job Recipient. Since one of the 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 of the goals of IPP is to be able to print near the Job Recipient, we would
printed output, we would normally expect that person to be in the normally expect that person to be in the same security domain as, and
same security domain as, and geographically near, the Printer. geographically near, the Printer. However, this may not always be
However, this may not always be the case. For example, I submit a the case. For example, I submit a print job across the Internet to a
print job across the Internet to a XYZ's print shop. I am both the XYZ's print shop. I am both the Submitting End User and the Job
Submitting end User and the Job Recipient, but I am neither near nor Recipient, but I am neither near nor in the same security domain as
in the same security domain as the Printer. the Printer.
2.8 Job Recipient Proxy 2.8. Job Recipient Proxy
A person acting on behalf of the Job Recipient. In particular, the A person acting on behalf of the Job Recipient. The Job Recipient
Job Recipient Proxy physically picks up the printed document from the Proxy physically picks up the printed document from the Printer if
Printer, if the Job Recipient cannot perform that function. The Proxy the Job Recipient cannot do so. The Proxy is by definition
is by definition geographically near and in the same security domain geographically near and in the same security domain as the printer.
as the printer. For example, I submit a print job from home to be For example, I submit a print job from home to be printed on a
printed on a printer at work. I'd like my secretary to pick up the printer at work. I'd like my secretary to pick up the print job and
print job and put it on my desk. In this case, I am acting as both put it on my desk. In this case, I am acting as both a Job-
Job Submitting End User and Job Recipient. My secretary is acting as Submitting End User and a Job Recipient. My secretary is acting as a
a Job Recipient Proxy. Job Recipient Proxy.
2.9 Notification Subscriber 2.9. Notification Subscriber
A client that requests the IPP Printer to send Event Notifications to A client that requests the IPP Printer to send Event Notifications to
one or more Notification Recipients. A Notification Subscriber may one or more Notification Recipients. A Notification Subscriber may
be a Job Submitting End User or an End User, an Operator, or an be a Job-Submitting End User or an End User, an Operator, or an
Administrator that is not submitting a job. Administrator that is not submitting a job.
2.10 Notification Source 2.10. Notification Source
The entity that sends Event Notifications. The entity that sends Event Notifications.
2.11 Notification Recipient 2.11. Notification Recipient
The entity that receives IPP Notifications about Job and/or Printer The entity that receives IPP Notifications about Job and/or Printer
events. A Notification Recipient may be a: Job Submitting End User, events. A Notification Recipient may be a Job Submitting End User, a
Job Submitting Application, Job Recipient, Job Recipient Proxy, Job-Submitting Application, a Job Recipient, a Job Recipient Proxy,
Operator, or Administrator, etc., and their representatives or log an Operator, an Administrator, etc., and his or her representative,
file or usage statistics gathering application or other active or log file, usage statistics-gathering application, or other active or
passive entities. passive entities.
2.12 Notification Recipient Agent 2.12. Notification Recipient Agent
A program which receives Event Notifications on behalf of the A program that receives Event Notifications on behalf of the
Notification Recipient. The agent may take some action on behalf of Notification Recipient. The agent may take some action on behalf of
the recipient, forward the notification to the recipient via some the recipient, forward the notification to the recipient via some
alternative means (for example, page the recipient), or queue the alternative means (for example, page the recipient), or queue the
notification for later retrieval by the recipient. notification for later retrieval by the recipient.
2.13 Event 2.13. Event
A Event is some occurrence (either expected or unexpected) within the An Event is an occurrence (either expected or unexpected) within the
printing system of a change of state, condition, or configuration of printing system of a change of state, condition, or configuration of
a Job or Printer object. a Job or Printer object.
2.14 Event Notification 2.14. Event Notification
When an event occurs, an Event Notification is generated that fully When an event occurs, an Event Notification is generated that fully
describes the event (what the event was, where it occurred, when it describes the event (what the event was, where it occurred, when it
occurred, etc.). Event Notifications are delivered to all the occurred, etc.). Event Notifications are delivered to all the
Notification Recipients that are subscribed to that Event, if any. Notification Recipients that are subscribed to that Event, if any.
The Event Notification is delivered to the address of the The Event Notification is delivered to the address of the
Notification Recipient using the notification delivery method defined Notification Recipient by using the notification delivery method
in the subscription. However, an Event Notification is sent ONLY if defined in the subscription. However, an Event Notification is sent
there is a corresponding subscription. ONLY if there is a corresponding subscription.
2.15 Notification Subscription 2.15. Notification Subscription
A Notification Subscription is a request by a Notification Subscriber A Notification Subscription is a request by a Notification Subscriber
to the IPP Printer to send Event Notifications to specified to the IPP Printer to send Event Notifications to specified
Notification Recipient(s) when the event occur. Notification Recipient(s) when an event occurs.
2.16 Notification Attributes 2.16. Notification Attributes
IPP Objects (for example, a print job) from which notification are IPP Objects (for example, a print job) from which notification are
being sent may have attributes associated with them. A user may want being sent may have associated attributes. A user may want to have
to have one or more of these associated attributes returned along one or more of these returned along with a particular notification.
with a particular notification. In general, these may include any In general, these may include any attribute associated with the
attribute associated with the object emitting the notification. object emitting the notification. Examples include the following:
Examples include:
number-of-intervening jobs number-of-intervening jobs
job-k-octets job-k-octets
job-k-octets processed job-k-octets processed
job impressions job impressions
job-impressions-interpreted job-impressions-interpreted
job-impressions-completed job-impressions-completed
impressionsCompletedCurrentCopy (job MIB) impressionsCompletedCurrentCopy (job MIB)
sheetCompletedCopyNumber (job MIB) sheetCompletedCopyNumber (job MIB)
sheetsCompletedDocumentNumber (job MIB) sheetsCompletedDocumentNumber (job MIB)
Copies-requested Copies-requested
Copy-type Copy-type
Output-destination Output-destination
Job-state-reasons Job-state-reasons
Job ID Job ID
Printer URI Printer URI
Subscription ID (for job independent subscription) Subscription ID (for job independent subscription)
2.17 Notification Delivery Method (or Delivery Method for short) 2.17. Notification Delivery Method (or Delivery Method for Short)
Event Notifications are delivered using a method, such as email, Event Notifications are delivered by using a Delivery Method. An
TCP/IP, etc. example of a Delivery Method is email.
2.18 Immediate Notification 2.18. Immediate Notification
Notifications sent to the Notification Recipient or the Notification Notifications sent to the Notification Recipient or the Notification
Recipient's agent in such a way that the notification arrives Recipient's agent in such a way that the notification arrives
immediately , within the limits of common addressing, routing, immediately, within the limits of common addressing, routing, network
network congestion and quality of service. congestion, and quality of service.
2.19 Store and Forward Notification 2.19. Store-and-Forward Notification
Notifications which are not necessarily delivered to Notification Notifications that are not necessarily delivered to Notification
Recipients immediately, but are queued for delivery by some Recipients immediately but are queued for delivery by an intermediate
intermediate network application, for later retrieval. Email is an network application, for later retrieval. Email is an example of a
example of a store and forward notification delivery method. store-and-forward notification delivery method.
2.20 Reliable Delivery of Notifications 2.20. Reliable Delivery of Notifications
Notifications which are delivered by a reliable delivery of packets Notifications that are delivered by a reliable delivery of packets or
or character stream, with acknowledgment and retry, such that character stream, with acknowledgement and retry, so that delivery of
delivery of the notification is guaranteed within some determinate the notification is guaranteed within determinate time limits. For
time limits. For example, if the Notification Recipient has logged example, if the Notification Recipient has logged off and gone home
off and gone home for the day, an immediate notification cannot be for the day, an immediate notification cannot be guaranteed, even
guaranteed to be delivered, even when sent over a reliable transport, when sent over a reliable transport, because there is nothing there
because there is nothing there to catch it. Guaranteed delivery to catch it. Guaranteed delivery requires both store-and-forward
requires both store and forward notification and a reliable notification and a reliable transport.
transport.
2.21 Notification over Unreliable Transport 2.21. Notification over Unreliable Transport
Notifications are delivered via the fundamental transport address and Notifications are delivered via the fundamental transport address and
routing framework, but no acknowledgment or retry is required. routing framework, but no acknowledgement or retry is required.
Process to process communications, if involved, are unconstrained. Process-to-process communications, if involved, are unconstrained.
2.22 Human Consumable Notification 2.22. Human-Consumable Notification
Notifications which are intended to be consumed by human end users Notifications intended to be consumed by human end users only. Email
only. Email would be an example of a Human consumable notification, would be an example of a Human-Consumable Notification, though it
though it could also contain Machine Consumable Notification. could also contain Machine-Consumable Notification.
2.23 Machine Consumable Notification 2.23. Machine-Consumable Notification
Notifications which are intended for consumption by a program only, Notifications that are intended for consumption by a program only,
such as an IPP Client. Machine Consumable notifications may not such as an IPP Client. Machine-Consumable Notifications may not
contain human readable information. Do we need both human and contain human-readable information. Do we need both human and
machine? Machine readable is intended for application to application machine? Machine readable is intended for application-to-application
only. The Notification Recipient could process the machine readable only. The Notification Recipient could process the machine-readable
Event Notification into human readable format. Event Notification into human-readable format.
2.24 Mixed Notification 2.24. Mixed Notification
A mixed notification contains both Human Consumable and Machine A mixed notification contains both Human-Consumable and Machine-
Consumable information. Consumable information.
3 Scenarios 3. Scenarios
1. I am sitting in my office and submit a print job to the printer 1. Sitting in my office, I submit a print job to the printer down
down the hall. I am in the same security domain as the printer and the hall. I am in the same security domain as the printer and,
of course, geographically near. I want to know immediately when of course, geographically near. I want to know immediately when
my print job will be completed (or if there is a problem) because my print job will be completed (or if there is a problem)
the document I am working on is urgent. I submit the print job because the document I am working on is urgent. I submit the
with the following attributes: print job with the following attributes:
. Notification Recipient - me - Notification Recipient: Me
. Notification Events - all - Notification Events: All
. Notification Attributes - job-state-reason - Notification Attributes: Job-state-reason
. Notification Type - immediate - Notification Type: Immediate
2. I am working from home and submit a print job to the same printer 2. Working from home, I submit a print job to the same printer as
as in the previous example. However, since I am not at work, I in the previous example. However, I am not at work, I cannot
cannot physically get the print file or do anything with it. It physically get the print file or do anything with it. It can
can wait until I get to work this afternoon. However, I'd like my wait until I get to work this afternoon. However, I'd like my
secretary to pick up the output and put it on my desk so it secretary to pick up the output and put it on my desk so that it
doesn't get lost or miss-filed. I'd also like a store and forward doesn't get lost or misfiled. I'd also like a store-and-forward
notification sent to my email so that when I get to work I can notification sent to my email so that when I get to work I can
tell if there was a problem with the print job. I submit a print tell whether there was a problem with the print job. I submit a
job with the following attributes: print job with the following attributes:
. Notification Recipient - my secretary - Notification Recipient: My secretary
. Notification Events - print complete - Notification Events: Print complete
. Notification Type - immediate - Notification Type: Immediate
. Notification Recipient - me - Notification Recipient: Me
. Notification Events - print complete - Notification Events: Print complete
. Notification Attributes - impressions completed - Notification Attributes: Impressions completed
. Notification Type - store and forward - Notification Type: Store and forward
3. I am sitting in my office and submit a print job to a client at an 3. Sitting in my office, I submit a print job to a client at an
engineering firm we work with on a daily basis. The engineering engineering firm my company works with on a daily basis. The
firm is in Belgium. I would like my client to know when the print engineering firm is in Belgium. I would like my client to know
job is complete, so that she can pick it up from the printer in when the print job is complete so that she can pick it up from
her building. It is important that she review it right away and the printer in her building. It is important that she review it
get her comments back to me. I submit the print job with the right away and send her comments back to me. I submit the print
following attributes: job with the following attributes:
. Notification Recipient - client at engineering firm - Notification Recipient: Client at engineering firm
. Notification Events - print complete - Notification Events: Print complete
. Notification Type - immediate - Notification Type: Immediate
. Notification Language - French - Notification Language: French
4. I am in a hotel room and send a print job to a Kinko's store in 4. From a hotel room, I send a print job to a Kinko's store in the
the town I am working in, in order to get a printed report for the town I am working in, in order to get a printed report for the
meeting I am attending in the morning. Since I'm going out to meeting I am attending in the morning. As I'm going out to
dinner after I get this job submitted, an immediate notification dinner after I get this job submitted, an immediate notification
won't do me much good. However, I'd like to check in the morning won't do me much good. However, I'd like to check in the
before I drive to the Kinko's store to see if the file has been morning before I drive to the Kinko's store to see whether the
printed. An email notification is sufficient for this purpose. I file has been printed. An email notification is sufficient for
submit the print job with the following attributes: this purpose. I submit the print job with the following
attributes:
. Notification Recipient - me - Notification Recipient: Me
. Notification Events - print complete - Notification Events: Print complete
. Notification Type - store and forward - Notification Type: Store and forward
5. I am printing a large, complex print file. I want to have some 5. I am printing a large, complex print file. I want to have some
immediate feedback on the progress of the print job as it prints. immediate feedback on the progress of the print job as it
I submit the print job with the following attributes: prints. I submit the print job with the following attributes:
. Notification Recipient - me - Notification Recipient: Me
. Notification Type - immediate - Notification Type: Immediate
. Notification Events - all state transitions - Notification Events: All state transitions
. Notification Attributes - impression completed - Notification Attributes: Impression completed
6. I am an operator and my duties is to keep the printer running. I 6. I am an operator and one of my duties is to keep the printer
subscribe independently from a job submission so that my running. I subscribe independently from a job submission so
subscription outlasts any particular job. I subscribe with the that my subscription outlasts any particular job. I subscribe
following attributes: with the following attributes:
. Notification Recipient - me - Notification Recipient: Me
. Notification Type - immediate - Notification Type: Immediate
. Notification Events - all Printer state transitions - Notification Events: All Printer state transitions
. Notification Attributes - Printer state, printer state reasons, - Notification Attributes: Printer state, printer state
device powering up, device powering down. reasons, device powering up, device powering down
7. I am a usage statistics gathering application. I subscribe 7. I am a usage statistics gathering application. I subscribe
independently from a job submission so that my subscription independently from a job submission so that my subscription
outlasts any particular job. My subscription may persists across outlasts any particular job. My subscription may persist across
power cycles. I subscribe with the following attributes: power cycles. I subscribe with the following attributes:
. Notification Recipient - me - Notification Recipient: Me
. Notification Type - immediate - Notification Type: Immediate
. Notification Events - job completion - Notification Events: Job completion
. Notification Attributes - impression completed, sheets - Notification Attributes: Impression completed, sheets
completed, time submitted, time started, time completed, job completed, time submitted, time started, time completed, job
owner, job size in octets, etc. owner, job size in octets, etc.
8. I am a client application program that displays a list of jobs 8. I am a client application program that displays a list of jobs
currently queued for printing on a printer. I display the "job- currently queued for printing on a printer. I display the
name", "job-state", "job-state-reasons", "page-count", and "job-name", "job-state", "job-state-reasons", "page-count", and
"intervening-jobs" either for the user's jobs or for all jobs. "intervening-jobs", either for the user's jobs or for all jobs.
The window displaying the job list remains open for an independent The window displaying the job list remains open for an
amount of time, and it is desired that it represent the current independent amount of time, and it is desired that it represent
state of the queue. It is desired that the application only need the current state of the queue. It is desired that the
to perform a slow poll in order to recover from any missed application only perform a slow poll in order to recover from
notifications. So the event delivery mechanism provides the means any missed notifications. So the event delivery mechanism
to update the screen on all needed changes, including querying for provides the means to update the screen on all needed changes,
some attributes that may not be delivered in the Notification. including querying for some attributes that may not be delivered
in the Notification.
9. I am a client application program that displays a list of 9. I am a client application program that displays a list of
printers. For each Printer I display the current state and printers. For each Printer, I display the current state and
configuration. The window displaying the printer list remains configuration. The window displaying the printer list remains
open for an independent amount of time, and it is desired that it open for an independent amount of time, and it is desired that
represent the current state of each printer. It is desired that it represent the current state of each printer. It is desired
the application only need to perform a slow poll in order to that the application only need to perform a slow poll in order
recover from any missed notifications. So the event delivery to recover from any missed notifications. So the event delivery
mechanism provides the means to update the screen on all needed mechanism provides the means to update the screen on all needed
changes, including querying for some attributes that may not be changes, including querying for some attributes that may not be
delivered in the Notification. delivered in the Notification.
10. I am an IPP Server that controls one or more devices and 10. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I want implements an IPP Printer object to represent each device. I
to support IPP Notification for each of the IPP Printer objects want to support IPP Notification for each of the IPP Printer
that I implement. Many of these devices do not support objects that I implement. Many of these devices do not support
notification (or IPP). So I need to support the IPP Notification notification (or IPP). So I need to support the IPP
semantics specified for each IPP Printer object myself on behalf Notification semantics specified for each IPP Printer object
of each of the devices that each of the IPP Printer objects myself on behalf of each of the devices that each of the IPP
represent. When I accept IPP job creation requests, I convert the Printer objects represents. When I accept an IPP job creation
request to what the device will accept. In some cases, I must requests, I convert it to what the device will accept. In some
poll the devices in order to be informed of their job and device cases, I must poll the devices in order to be informed of their
state and state changes in order to be able to send IPP job and device state and state changes to be able to send IPP
Notifications to subscribed Notification Recipients. Notifications to subscribed Notification Recipients.
11. I am an IPP Server that controls one or more devices and 11. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I want implements an IPP Printer object to represent each device. I
to support IPP Notification for each of the IPP Printer objects want to support IPP Notification for each of the IPP Printer
that I implement. These devices all support IPP, including IPP objects that I implement. These devices all support IPP,
Notification. I would like the design choice for supporting IPP including IPP Notification. I would like the design choice for
Notification for these IPP Printer objects that I implement either supporting IPP Notification for these objects either (1) by
(1) by forwarding the notification to the IPP Printers that I forwarding the notification to the IPP Printers that I, alone,
alone control and have them send the notifications to the intended control and have them send the notifications to the intended
Notification Recipients without my involvement or (2) replace the Notification Recipients without my involvement, or (2) by
notification submitted with the Job to indicate me as the replacing the notification submitted with the Job to indicate me
Notification Recipient and I will in turn forward Notifications to as the Notification Recipient; in turn I will forward
the Notification Recipients requested by my clients. Most of the Notifications to the Notification Recipients requested by my
rest of the contents of the IPP Job that I send to the IPP clients. Most of the rest of the contents of the IPP Job I send
Printers that I control will be the same as the IPP Job that I to the IPP Printers I control will be the same as those that I
receive from my IPP clients. receive from my IPP clients.
12. I am an IPP Server that controls one or more devices and 12. I am an IPP Server that controls one or more devices and that
implements an IPP Printer object to represent each device. I want implements an IPP Printer object to represent each device. I
to support IPP Notification for each of the IPP Printer objects want to support IPP Notification for each of the IPP Printer
that I implement. These devices all support IPP, including IPP objects that I implement. These devices all support IPP,
Notification. Because these IPP Printers MAY also be being including IPP Notification. Because these IPP Printers MAY also
controlled by other servers (using IPP or other protocols), I only be controlled by other servers (using IPP or other protocols), I
want job events for the jobs that I send, but do want Printer only want job events for the jobs that I send, but I do want
events all the time, so that I can show proper Printer state to my Printer events all the time, so that I can show proper Printer
clients. So I subscribe to these IPP Printers for Printer events state to my clients. So I subscribe to these IPP Printers for
with a long standing subscription with myself to as the Printer events with a long-standing subscription, with myself as
Notification Recipient. When I get a Job Creation request, I the Notification Recipient. When I get a Job Creation request,
decide to which IPP Printer to send the job. When I do so, I also I decide to which IPP Printer to send the job. When I do so, I
add a job subscription for Job events with me as the Notification also add a job subscription for Job events, with me as the
Recipient to the job's job subscriptions supplied by my clients Notification Recipient to the job's job subscriptions supplied
(this usage is called "piggy-backing"). These IPP Printers by my clients (this usage is called "piggybacking"). These IPP
automatically remove their job subscriptions when the job Printers automatically remove their job subscriptions when the
completes as for all job subscriptions so that I no longer get Job job finishes, as for all job subscriptions, so that I no longer
events when my jobs are completed. get Job events when my jobs are completed.
4. Requirements
4 Requirements
The following requirements are intended to be met by the IPP The following requirements are intended to be met by the IPP
Notification specification (not the implementation). The resulting Notification specification (not the implementation). The following
IPP Notification Specification document: are true for the resulting IPP Notification Specification document:
1. must indicate which of these requirements are REQUIRED and which 1. It must indicate which of these requirements are REQUIRED and
are OPTIONAL for a conforming implementation to support. See which are OPTIONAL for a conforming implementation to support.
[RFC2911] section 12.1 for the definition of these important See [RFC2911], section 12.1, for the definition of these
conformance terms. important conformance terms.
2. must be designed to that an IPP Printer can transparently support 2. It must be designed so that an IPP Printer can transparently
the IPP Notification semantics using third party notification support the IPP Notification semantics by using third-party
services that exist today or that may be standardized in the notification services that exist today or that may be
future. standardized in the future.
3. must define means for a Job Submitting End User to specify zero or 3. It must define a means for a Job-Submitting End User to specify
more Notification Recipients when submitting a print job. A zero or more Notification Recipients when submitting a print job.
Submitter will not be able to prevent out of band subscriptions A Submitter will not be able to prevent out-of-band subscriptions
from authorized persons, such as Operators. from authorized persons, such as Operators.
4. must define means when specifying a Notification Recipient, for a 4. It must define a means, when specifying a Notification Recipient,
Notification Subscriber to be able to specify one or more for a Notification Subscriber to specify one or more notification
notification events for that Notification Recipient, subject to events for that Notification Recipient, subject to administrative
administrative and security policy restrictions. Any of the and security policy restrictions. Any of the following
following constitute Job or Printer Events that a Job Submitting constitute Job or Printer Events for which a Job Submitting End
End User can specify notifications be sent for: User can specify that notifications be sent:
. Any standard Printer MIB alert (i.e. device alerts) (critical
and warning?) (state change notifications)? - Any standard Printer MIB alert
. Job Received (transition from Unknown to Pending) - Job Received (transition from Unknown to Pending)
. Job Started (Transition from Pending to Processing) - Job Started (transition from Pending to Processing)
. Page Complete (Page is stacked) - Page Complete (page is stacked)
. Collated Copy Complete (last sheet of collated copy is - Collated Copy Complete (last sheet of collated copy is
stacked) 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 like 'paused', purged?
. Device problems for which the job is destined
. Job (interpreter) issues
5. must define how an End User or Operator subscribes for: - Job Complete (transition from Processing or Processing-stopped
. Any set of Job Events for a specific job. to Completed)
. Any set of Printer Events while a specific job is not - Job Aborted (transition from Pending, Pending-held,
complete. - 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
6. must define how an End User or Operator subscribes for the 5. It must define how an End User or Operator subscribes for
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. must define how the Notification Subscriber is able to specify - any set of Job Events for a specific job, or
either immediate or store and forward notification independently - any set of Printer Events while a specific job is not
for each Notification Recipient. The means may be explicit, or complete.
implied by the method of delivery chosen by the Job Submitting End
User.
8. must define common delivery methods, e.g. email, must be defined. 6. It must define how an End User or Operator subscribes for the
following without having to submit a Job:
9. must define how an IPP Printer validates its ability to deliver an - Any set of Printer Events for a defined period.
Event using the specified delivery scheme. If it does not support - Any set of Job Events for all jobs, with no control over
the specified scheme, or the specified scheme is invalid for some which jobs.
reason, then the IPP Printer accepts and performs the request
anyway and responds indicating the unsupported attribute values.
There is no requirement for the IPP Printer receiving the print
request to validate the identity of an Notification Recipient, nor
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. must define a class of IPP event notification delivery methods 7. It must define how the Notification Subscriber is able to
which can flow through corporate firewalls. However, an IPP specify either immediate or store-and-forward notification
printer need not test to guarantee delivery of the notification independently for each Notification Recipient. The means may be
through a firewall before accepting a print job. explicit, or implied by the method of delivery chosen by the Job
11. may define means for delivering a notification to the Submitting End User.
submitting client when the delivery of an event notification to a
specified Notification Recipient fails. Fall back means of
subscribers determining if notifications have failed, i.e.
polling, may be provided.
12. must define a mechanism for localizing Human Consumable 8. It must define common delivery methods: e.g., email.
notifications by the Notification Source.
13. may define a way to specify whether or not event delivery 9. It must define how an IPP Printer validates its ability to
requires acknowledgement back to the Notification Source. 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).
14. There must be a mechanism defined so that job independent 10. It must define a class of IPP event notification delivery
subscriptions do not become stale and do not require human methods that can flow through corporate firewalls. However, an
intervention to remove stale subscriptions. However, stale must IPP printer need not test to guarantee delivery of the
not be the inability to deliver an Event Notification , since notification through a firewall before accepting a print job.
temporary Notification delivery problems must be tolerated.
15. A mechanism must be defined so that an Event Subscriber is 11. It may define a means to deliver a notification to the
able to add an Event Subscription to a Job after the Job has been submitting client when the delivery of an event notification to
submitted. a specified Notification Recipient fails. A fallback means of
subscribers to determine whether notifications have failed
(i.e., polling) may be provided.
16. A mechanism must be defined so that a client is able to cancel 12. It must define a mechanism for localizing Human-Consumable
an Event Subscription on a job or printer after the job has been Notifications by the Notification Source.
submitted.
17. A mechanism must be defined so that a client can obtain the 13. It may define a way to specify whether event delivery requires
set of current Subscriptions. acknowledgement back to the Notification Source.
5 Security considerations for IPP Notifications requirements 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: By far the biggest security concern is the abuse of notification:
sending unwanted notifications to third parties (i.e., spam). The sending unwanted notifications sent to third parties (i.e., spam).
problem is made worse by notification addresses that may be The problem is made worse by notification addresses that may be
redistributed to multiple parties (e.g. mailing lists). There exist redistributed to multiple parties (e.g., mailing lists). Scenarios
scenarios where third party notification is required (see Scenario #2 exist in which third-party notification is required (see scenarios 2
and #3). The fully secure solution would require active agreement of and 3). The fully secure solution would require active agreement of
all recipients before sending out anything. However, requirement #9 all recipients before anything is sent out. However, requirement 9
("There is no requirement for IPP Printer receiving the print request ("There is no requirement for an IPP Printer receiving the print
to validate the identity of an event recipient") argues against this. request to validate the identity of an event recipient") argues
Certain systems may decide to disallow third party notifications (a against this. Certain systems may decide to disallow third-party
traditional fax model). notifications (a traditional fax model).
Clients submitting notification requests to the IPP Printer has the The same security issues are present when Clients submit notification
same security issues as submitting an IPP/1.1 print job request. The requests to the IPP Printer as when they submit an IPP/1.1 print job
same mechanisms used by IPP/1.1 can therefore be used by the client request. The same mechanisms used by IPP/1.1 can therefore be used
notification submission. Operations that require authentication can by the client notification submission. Operations that require
use the HTTP authentication. Operations that require privacy can use authentication can use the HTTP authentication. Operations that
the HTTP/TLS privacy. require privacy can use the HTTP/TLS privacy.
The notification access control model should be similar to the IPP The notification access control model should be similar to the IPP
access control model. Creating a notification subscription is access control model. Creating a notification subscription is
associated with a user. Only the creator or an operator can cancel associated with a user. Only the creator or an operator can cancel
the subscription. The system may limit the listing of items to only the subscription. The system may limit the listing of items to items
those items owned by the user. Some subscriptions (e.g. those that owned by the user. Some subscriptions (e.g., those that have a
have a lifetime longer than a job) can be done only by privileged lifetime longer than a job) can be done only by privileged users
users (operators and/or administrators), if that is the authorization (operators and/or administrators), if that is the authorization
policy. policy.
The standard security concerns (delivery to the right user, privacy The standard security concerns (delivery to the right user, privacy
of content, tamper proof content) apply to the notification delivery. of content, tamper-proof content) apply to the notification delivery.
IPP should use the security mechanism of the delivery method used. IPP should use the security mechanism of the delivery method used.
Some delivery mechanisms are more secure than others. Therefore, Some delivery mechanisms are more secure than others. Therefore,
sensitive notifications should use the delivery method that has the sensitive notifications should use the delivery method that has the
strongest security. strongest security.
6 Internationalization Considerations 6. Internationalization Considerations
The Human Consumable notification must be localized to the natural The Human-Consumable Notification must be localized to the natural
language and charset that Notification Subscriber specifies within language and charset that Notification Subscriber specifies within
the choice of natural languages and charsets that the IPP Printer the choice of natural languages and charsets that the IPP Printer
supports. supports.
The Machine Consumable notification data uses the 'application/ipp' The Machine-Consumable Notification data uses the "application/ipp"
MIME media type. It contains some attributes whose text values are MIME media type. It contains attributes whose text values are
required to be in the natural language and charset that the required to be in the natural language and charset that the
Notification Subscriber specifies within the choice of natural Notification Subscriber specifies within the choice of natural
languages and charsets that the IPP Printer supports. See [RFC2566]. languages and charsets that the IPP Printer supports. See [RFC2566].
7 IANA Considerations 7. IANA Considerations
There will be some notification delivery methods registered with IANA
for use in URLs. These will be defined in other documents.
8 References Some notification delivery methods have been registered with IANA for
use in URLs. These will be defined in other documents.
8.1 Normative References 8. References
[RFC2910]
Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2911] 8.1. Normative References
deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
"Internet Printing Protocol/1.1: Model and Semantics", RFC 2911,
September 2000.
[ipp-ntfy] [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J.
Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., Wenn, "Internet Printing Protocol/1.1: Encoding and
Bergman, R., " IPP Event Notification Specification", <draft-ietf- Transport", RFC 2910, September 2000.
ipp-not-spec-07.txt>, work in progress, July 17, 2001.
8.2 Informative References [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and
[RFC2565] P. Powell, "Internet Printing Protocol/1.1: Model and
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Semantics", RFC 2911, September 2000.
Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2566] [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, (IPP): Event Notifications and Subscriptions", RFC 3995,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, March 2005.
April 1999.
[RFC2567] 8.2. Informative References
Wright, D., "Design Goals for an Internet Printing Protocol", RFC
2567, April 1999.
[RFC2568] [RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner,
Zilles, S., "Rationale for the Structure and Model and Protocol for "Internet Printing Protocol/1.0: Encoding and Transport",
the Internet Printing Protocol", RFC 2568, April 1999. RFC 2565, April 1999.
[RFC2569] [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between P. Powell, "Internet Printing Protocol/1.0: Model and
LPD and IPP Protocols", RFC 2569, April 1999. Semantics", RFC 2566, April 1999.
[RFC2639] [RFC2567] Wright, F., "Design Goals for an Internet Printing
T. Hastings, C. Manros. "Internet Printing Protocol/1.0: Protocol", RFC 2567, April 1999.
Implementer's Guide", RFC 2639, July 1999.
9 Author's Address [RFC2568] Zilles, S., "Rationale for the Structure of the Model and
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
Tom Hastings (editor) [RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin,
Xerox Corporation "Mapping between LPD and IPP Protocols", RFC 2569, April
737 Hawaii St. ESAE 231 1999.
El Segundo, CA 90245
Phone: 310-333-6413 [RFC2639] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
Fax: 310-333-5514 Holst, "Internet Printing Protocol/1.1: Implementor's
e-mail: hastings@cp10.es.xerox.com Guide", RFC 3196, November 2001.
Roger deBry 9. Appendix A: Description of the Base IPP Documents
Utah Valley State College
Orem, UT 84058
Phone: (801) 222-8000 The base set of IPP documents includes the following:
e-mail: debryro@uvsc.edu
Harry Lewis Design Goals for an Internet Printing Protocol [RFC2567]
HUC/003G Rationale for the Structure and Model and Protocol for the
IBM Corporation Internet Printing Protocol [RFC2568]
P.O. Box 1900 Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Boulder, CO 80301-9191 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]
Phone: (303) 924-5337 "Design Goals for an Internet Printing Protocol" takes a broad look
Fax: (303) 924-9889 at distributed printing functionality, and it enumerates real-life
e-mail: harryl@us.ibm.com 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].
10 Appendix A: Description of the Base IPP Documents "Rationale for the Structure and Model and Protocol for the Internet
The base set of IPP documents includes: Printing Protocol" describes IPP from a high-level view, defines a
Design Goals for an Internet Printing Protocol [RFC2567] roadmap for the various documents that form the suite of IPP
Rationale for the Structure and Model and Protocol for the Internet specification documents, and gives background and rationale for the
Printing Protocol [RFC2568] IETF IPP working group's major decisions.
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 [IPP-IIG]
Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a "Internet Printing Protocol/1.1: Model and Semantics" describes a
broad look at distributed printing functionality, and it enumerates simplified model with abstract objects, their attributes, and their
real-life scenarios that help to clarify the features that need to be operations. The model introduces a Printer and a Job. The Job
included in a printing protocol for the Internet. It identifies supports multiple documents per Job. The model document also
requirements for three types of users: end users, operators, and addresses security, internationalization, and directory issues.
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/1.1: Encoding and Transport" is a formal
Internet Printing Protocol" document describes IPP from a high level mapping of the abstract operations and attributes defined in the
view, defines a roadmap for the various documents that form the suite model document onto HTTP/1.1 [RFC2616]. It also defines the encoding
of IPP specification documents, and gives background and rationale rules for a new Internet MIME media type called "application/ipp".
for the IETF IPP working group's major decisions. This document also defines the rules for transporting over HTTP a
The "Internet Printing Protocol/1.1: Model and Semantics" document message body whose Content-Type is "application/ipp". This document
describes a simplified model with abstract objects, their attributes, defines the "ipp" scheme for identifying IPP printers and jobs.
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 "Internet Printing Protocol/1.1: Implementer's Guide" gives insight
gives insight and advice to implementers of IPP clients and IPP and advice to implementers of IPP clients and IPP objects. It is
objects. It is intended to help them understand IPP/1.1 and some of intended to help them understand IPP/1.1 and some of the
the considerations that may assist them in the design of their client considerations that may assist them in the design of their client
and/or IPP object implementations. For example, a typical order of and/or IPP object implementations. For example, a typical order of
processing requests is given, including error checking. Motivation processing requests is given, including error checking. Motivation
for some of the specification decisions is also included. 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.
11 Appendix B: Full Copyright Statement "Mapping between LPD and IPP Protocols" gives some advice to
Copyright (C) The Internet Society (1998,1999,2000,2001). All Rights implementers of gateways between IPP and LPD (Line Printer Daemon )
Reserved implementations.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Authors' Addresses
revoked by the Internet Society or its successors or assigns.
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.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 138 change blocks. 
557 lines changed or deleted 559 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/