INTERNET-DRAFT
<draft-ietf-ipp-notify-poll-00.txt> Carl-Uno Manros
Tom Hastings
Robert Herriot
Xerox Corp.
Harry Lewis
IBM, Corp.
March 8, 2000
Internet Printing Protocol (IPP):
The 'ipp' Notification Polling Method
Copyright (C) The Internet Society (2000). 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
The IPP notification specification [ipp-ntfy] is an OPTIONAL extension
to IPP/1.0 and IPP/1.1 that requires the definition of one or more
delivery methods for dispatching Event Notification reports to
Notification Recipients. This document describes the semantics and
syntax of the 'ipp' event Notification delivery method. For this
delivery method, the client uses an explicit IPP Get-Notifications
Printer operation in order to request (pull) Event Notifications from
the IPP Printer.
When a Printer supports the 'ipp' delivery method, it holds each Event
Notification for a certain length of time. The amount of time is called
the "event-lease time".. A Printer may assign the same event-lease time
to each Event Notification or different times. If a Notification
Recipient does not want to miss Event Notifications, the time between
consecutive pollings of Subscription objects must be less than the
event-lease time of the events that occur between pollings. The Get-
Notifications request indicates whether the client wants to receive all
pending event Notifications for (1) any Subscription for which the
client is the owner, (2) any Subscription associated with a Job, (3) any
Subscription with a particular delivery-method URL, or (4) an identified
Manros, Hastings, Herriot, Lewis [page 1]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
set of Subscription objects. With the Get-Notifications operation, the
Printer returns all existing Event Notifications along with two time
intervals. One specifies the minimum time at which event-leases of
future events of the type returned will begin to expire and the other
specifies the recommended interval for the client to wait before sending
the next Get-Notifications operation. The second time interval is less
than the first.
The Printer may keep the channel open if the recommended interval is
sufficiently short, but in any case the client performs a new Get-
Notifications operation each time it wants more Event Notifications.
Since the time interval between consecutive client requests is normally
less than the event-lease time, consecutive responses will normally
contain some Event Notifications that are identical. The youngest ones
in the previous response will become the oldest in the next response.
The client is expected to filter out these duplicates, which is easy to
do because of the sequence number in each Event Notification.
Manros, Hastings, Herriot, Lewis [page 2]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [ipp-mod]
Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
Internet Printing Protocol/1.0 & 1.1: Event Notification
Specification [ipp-ntfy]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that are
satisfied in IPP/1.0. A few OPTIONAL operator operations have been
added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol" document describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of IPP
specification documents, and gives background and rationale for the IETF
working group's major decisions.
The "Internet Printing Protocol/1.1: Model and Semantics" document
describes a simplified model with abstract objects, their attributes,
and their operations that are independent of encoding and transport. It
introduces a Printer and a Job object. The Job object optionally
supports multiple documents per Job. It also addresses security,
internationalization, and directory issues.
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 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 a
new scheme named 'ipp' for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
insight and advice to implementers of IPP clients and IPP objects. It
is intended to help them understand IPP/1.1 and some of the
considerations that may assist them in the design of their client and/or
IPP object implementations. For example, a typical order of processing
requests is given, including error checking. Motivation for some of the
specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
Manros, Hastings, Herriot, Lewis [page 3]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
The "Event Notification Specification" document defines OPTIONAL
operations that allow a client to subscribe to printing related events.
Subscriptions include "Per-Job subscriptions" and "Per-Printer
subscriptions". Subscriptions are modeled as Subscription objects.
Four other operations are defined for subscription objects: get
attributes, get subscriptions, renew a subscription, and cancel a
subscription.
Manros, Hastings, Herriot, Lewis [page 4]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
Table of Contents
1 Introduction......................................................6
2 Terminology.......................................................7
3 Model and Operation...............................................7
4 Get-Notifications operation.......................................8
4.1GET-NOTIFICATIONS REQUEST........................................9
4.2GET-NOTIFICATIONS RESPONSE......................................11
5 Extension to Print-Job, Print-URI, Create-Job, Create-Printer-
Subscription and Create-Printer-Subscription.........................12
5.1RESPONSE........................................................12
6 Encoding.........................................................13
7 IANA Considerations..............................................13
8 Internationalization Considerations..............................14
9 Security Considerations..........................................14
10 References.......................................................14
11 Authors' Addresses...............................................15
12 Full Copyright Statement.........................................15
Manros, Hastings, Herriot, Lewis [page 5]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
1 Introduction
IPP printers that support the OPTIONAL IPP notification extension [ipp-
ntfy] either a) accept, store, and use notification subscriptions to
generate Event Notification reports and implement one or more delivery
methods for notifying interested parties, or b) support a subset of
these tasks and farm out the remaining tasks to a Notification Delivery
Service. The 'ipp' Event Notification delivery method specified in this
document defines a Get-Notifications operation that may be used in a
variety of notification scenarios. Its primary intended use is for
clients that want to be Notification Recipients. However, the Get-
Notifications operation may also be used by Notification Delivery
Services for subsequent distribution to the Ultimate Notification
Recipients.
When a Printer supports the 'ipp' delivery method, it holds each Event
Notification for a certain length of time. The amount of time is called
the "event-lease time". A Printer may assign the same event-lease time
to each event or different times. If a Notification Recipient does not
want to miss Event Notifications, the time between consecutive pollings
of Subscription objects must be less than the event-lease time of the
Event Notifications that occur between pollings. The Get-Notifications
request indicates whether the client wants to receive all pending Event
Notifications for (1) any Subscription for which the client is the
owner, (2) any Subscription associated with a particular Job, (3) any
Subscription with a particular notification recipient URL, or (4) an
identified set of Subscription objects. With the Get-Notifications
operation, the Printer returns all existing Event Notifications along
with two time intervals. One specifies the minimum time at which event-
leases of future events of the type returned will begin to expire and
the other specifies the recommended interval for the client to wait
before sending the next Get-Notifications operation. The second time
interval is less than the first.
The Printer may keep the channel open if the recommended interval is
sufficiently short, but in any case the client performs a new Get-
Notifications operation each time it wants more Notifications. Since the
time interval between consecutive client requests is normally less than
the event-lease time, consecutive responses will normally contain some
events that are identical. The youngest ones in the previous response
will become the oldest in the next response. The client is expected to
filter out these duplicates, which is easy to do because of the sequence
number in each Notification. The reason for not removing the
Notifications from the Subscription object with every Get-Notifications
request, is so that multiple Notification Recipients can be polling the
same subscription object and so the Get-Notification operation satisfies
the rule of idempotency. The former is useful if someone is logged in
to several desktops at the same time and wants to see the same events at
both places. The latter is useful if the network loses the response.
Manros, Hastings, Herriot, Lewis [page 6]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
2 Terminology
This section defines the following additional terms that are used
throughout this document:
REQUIRED: if an implementation supports the extensions described in
this document, it MUST support a REQUIRED feature.
OPTIONAL: if an implementation supports the extensions described in
this document, it MAY support an OPTIONAL feature.
Notification Recipient - See [ipp-ntfy]
Subscription object - See [ipp-ntfy]
Ultimate Notification Recipient - See [ipp-ntfy]
3 Model and Operation
In the IPP Notification Model [ipp-ntfy], one or more Per-Job
Subscriptions can be supplied in the Job Creation operation or
OPTIONALLY as subsequent Create-Job-Subscription operations; one Per-
Printer Subscription can be supplied in the Create-Printer operation.
The client that creates these Subscription objects becomes the owner of
the Subscription object.
When creating each Subscription object, the client supplies the "notify-
recipient" (uri) attribute. The "notify-recipient" attribute specifies
both a single Notification Recipient that is to receive the
Notifications when subsequent events occur and the method for
Notification delivery that the IPP Printer is to use. For the
Notification delivery method defined in this document, the scheme of the
URL is 'ipp' and the host SHOULD be the client host's URL. In addition,
the URL MAY contains a path to allow for applications to have a unique
URL.
ISSUE 1: The 'ipp' is a convenient reuse of 'ipp', but does it imply the
existence of a print service at each client that is not a reality?
For most Notification delivery methods, a Printer sends Event
Notifications to the delivery URL and the Printer does not perform any
authentication or authorization with the receivers of the Event
Notifications. For the Notification delivery method defined in this
document, the client requests Event Notifications from the Printer via a
Get-Notifications operation, and the Printer performs the same
authentication and authorization as it does for the Get-Job-Attributes
operation. That is, a Printer MAY allow a client to perform a Get-
Notifications operation on any Subscription object or it MAY restrict
access as follows. Any client that is authenticated (1) as an operator
or administrator or (2) as the owner of the Subscription object can
initiate a Get-Notifications operation for that Subscription object.
Because a Printer has to wait for a client to request Event
Notifications for the 'ipp' delivery method, any Printer that supports
the 'ipp' notification delivery method MUST hold each Event Notification
at least for the event-lease time that it advertises to clients. With
this rule, a single user can login at different places, say his/her
office, the lab, and/or several desktops in the same room, and receive
Manros, Hastings, Herriot, Lewis [page 7]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
the same Event Notifications from a single Subscription object. In
addition, a client that gets no response, perhaps because of a network
failure, can perform the Get-Notifications operations two or more times
in quick succession and get the same results except for a few newly
arrived Event Notifications and a few old Event Notifications whose
event-leases have expired.
The event-lease time assigned to Event Notifications MAY be different
for each implementation. Furthermore, a particular implementation MAY
assign different event-lease times to each Event Notification. If a
Printer assigns different event-lease times to each Event Notification,
the event-lease time returned with Get-Notifications MUST be a value
that ensures a client will not miss future Event Notifications.
The client issues a Get-Notifications Printer operation in order to
initiate the delivery of the pending Notifications held by the Printer
for the Subscription objects requested. The client can indicate in the
Get-Notifications request whether it wants to receive all pending
Notifications for:
1) any existing Subscription objects for which the client is the
owner,
2) any existing Subscription objects whose notification-recipient is a
specified URL
3) any existing Subscription objects associated with a job-id or
4) particular Subscription object(s) (for which it MUST be the owner
or have read-access rights).
In any case, the Notifications are returned in a response to the Get-
Notifications request.
If the client requests a persistent channel, then the Printer MAY keep
the channel open. Either the client or the IPP Printer can disconnect
the HTTP connection.
4 Get-Notifications operation
This REQUIRED operation allows the client to request that pending Event
Notifications be delivered as a response to this request. The client
MUST be the owner or have read-access rights of the Subscription objects
that are involved and the delivery method specified when the
Subscription objects were created MUST be ipp'. When the Printer
creates a Subscription Object, either with a Job Creation operation or
with a Create-Printer-Subscription or Create-Job-Subscription operation
and a subscription object contains the 'ipp' value for the "notify-
recipient" operation attribute, the Printer returns the event-lease time
for Events and the recommended time interval before the client to
performs the next Get-Notifications operation. The client SHOULD
perform a Get-Notifications operation at about the recommended interval
Manros, Hastings, Herriot, Lewis [page 8]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
and if the Printer receives the Get-Notifications before the event-lease
time has elapsed, it MUST have all of the Notifications since the
previous Get-Notification operation or the Subscription object creation,
whichever was most recent.
Issue 2: Now that the Get-Notification operation does not affect the
Event Notifications in the Printer, it should not require write access
to access them.
The IPP Printer MUST accept the request in any state (see [ipp-mod]
"printer-state" and "printer-state-reasons" attributes) and MUST remain
in the same state with the same "printer-state-reasons".
Access Rights: The authenticated user (see [ipp-mod] section 8.3)
performing this operation must either be the Subscription object owner
(as determined when the Subscription object was created by the Job
Creation operation, Create-Job-Subscription, or Create-Printer-
Subscription operations) or an operator or administrator of the Printer
object (see [ipp-mod] Sections 1 and 8.5). Otherwise, the IPP object
MUST reject the operation and return: 'client-error-forbidden', 'client-
error-not-authenticated', or 'client-error-not-authorized' as
appropriate.
Issue 3: Is it possible for this operation to have an option that causes
it to delay completing its response? It would initially returns all
existing Event Notifications. Then it would return additional
notifications as they occur for some period of time. The client would
receive these Event Notifications as they occur. The question is
whether http servers or proxies would behave in this manner so that the
client would get the Event Notifications without delay after they are
sent by the http server? It has been suggested that the Printer send
each burst of Event Notifications be in a separate message body where
each message body is part of a multipart MIME content-type.
4.1 Get-Notifications Request
The following groups of attributes are part of the Get-Notifications
Request:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in [ipp-mod] section 3.1.4.1.
Target:
The "printer-uri" (uri) operation attribute which is the target for
this operation as described in [ipp-mod] section 3.1.5.
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
by the client as described in [ipp-mod] section 8.3.
Manros, Hastings, Herriot, Lewis [page 9]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
"notification-recipient" (url):
The client OPTIONALLY supplies this attribute. The Printer object
MUST support this attribute. It is a URL that identifies one or
more Subscription objects for which Event Notifications are being
requested. If the client supplies this attribute, but no
notification-recipients are found, the IPP Printer MUST return the
'client-error-not-found' status code. If some are found and others
are not, the ones that are not found are return in the Unsupported
Attributes. By definition, if a notification-recipient URL
exists, there must be at least one Subscription object.
Note: this attribute allows a subscribing client to pick URLs that
are unique, e.g. the client's own URL or a friend's URL, which in
both cases is likely the URL of the person's host. An application
could make a URL unique for each application if it wants. If a
client uses such a URL as the value of this attribute, the client
gets event Notifications for all Subscription objects whose
"notification-recipient" is the specified URL. This mechanism is
more general than getting all subscriptions owned by a client. It
allows clients who didn't subscribe to get Event Notifications
without knowing job-ids or subscription-ids.
ISSUE 4: The "notification-recipient" option allows a client to group
multiple Subscription-ids with a single URL. A client might decide to
use the same URL for all subscriptions for a user, or it might have a
separate URL for each client program. In addition a client might use an
URL belonging to some other known user and let that user access Event
Notifications using that URL. Is the above option useful?
"subscription-ids" (1setOf integer(1:MAX)):
The client OPTIONALLY supplies this attribute. The Printer object
MUST support this attribute. It is an integer value that identifies
one or more Subscription objects for which Event Notifications are
being requested. If the client supplies this attribute, but none
of the Subscription objects are found, the IPP Printer MUST return
the 'client-error-not-found' status code. If some are found and
others are not, the ones that are not found are return in the
Unsupported Attributes.
"job-ids" (1setOf integer(1:MAX)):
The client OPTIONALLY supplies this attribute. The Printer object
MUST support this attribute. It is an integer value that identifies
one or more job-ids. These job-ids identify the Subscription
objects for which Event Notifications are being requested. If the
client supplies this attribute, but no Jobs are found, the IPP
Printer MUST return the 'client-error-not-found' status code. If
some are found and others are not, the ones that are not found are
returned in the Unsupported Attributes. It is not an error if
there are no Subscription objects for a Job.
Manros, Hastings, Herriot, Lewis [page 10]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
If the client supplies none of the last three attributes described
for this operation, then the IPP Printer returns Event
Notifications for all Subscription objects for which the client is
the owner and the "notify-recipients" attribute is 'ipp'. It is
not an error if there are currently no Subscription objects for
this client; the response then contains no Notifications.
ISSUE 5: Does the mechanism described in the above paragraph describe a
useful option that "notification-recipient" alone cannot do? Should this
case be an error instead?
If a client supplies more than one of the last three attributes
described for this operation, the Printer returns Event
Notifications for all Subscription objects specified by all
attributes. If these attributes describe duplicate Event
Notifications, the Printer MAY remove them.
ISSUE 6: Is it better if "notification-recipient" is the only way to
request Event Notification? If so, this behaves more like other
notification delivery methods where a recipient receives those and only
those events with its delivery URL. Furthermore, if there is a single
mechanism of "notification-recipient" for a client to specify Event
Notifications, a Printer can better optimize event-leases because it
knows which events will be accessed together. If client can specify
subscription-ids, each request can contain a different mix of
subscription-ids.
4.2 Get-Notifications Response
The Printer object returns either an immediate error response or a
successful response with status code: 'successful-ok' when the first
event occurs, i.e., when the Printer delivers the first Event
Notification.
Group 1: Operation Attributes
Status Message:
In addition to the REQUIRED status code returned in every response,
the response OPTIONALLY includes a "status-message" (text(255))
and/or a "detailed-status-message" (text(MAX)) operation attribute
as described in [ipp-mod] sections 13 and 3.1.6.
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in [ipp-mod] section 3.1.4.2.
"recommended-time-interval" (integer(0:MAX)):
The value of this attribute is the recommended number of seconds
that SHOULD elapse before the client performs this operation again
for these Subscription objects. A client MAY perform this operation
Manros, Hastings, Herriot, Lewis [page 11]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
at any time, and a Printer MUST respond with all existing
Notifications. A client observes this value in order to be a "good
network citizen". The value that a Printer returns for this
attribute MUST NOT exceed 80% of the "event-lease-time-interval" in
order to give a client plenty of time to perform another Get-
Notifications operation before the event-lease of the oldest Event
Notifications expire.
"event-lease-time-interval" (integer(0:MAX)):
The value of this attribute is the minimum number of seconds until
the event-lease expiration time for all future Event Notifications
associated with the Subscription objects generating the requested
Event Notifications. Thus this number is the maximum number of
seconds that elapses before this client SHOULD issue this operation
again for these Subscription objects. A Printer MUST preserve all
Notifications that occur for the number of seconds specified by
this attribute starting at the time it is sent in a response. A
client MAY perform this operation at any time, and a Printer MUST
respond with all existing Event Notifications. If a Printer
receives this operation after this time interval, it MAY have
discarded some Notifications since the last response.
Group 2: Unsupported Attributes
See [ipp-mod] section 3.1.7 for details on returning Unsupported
Attributes.
If the "subscription-ids" attribute contained subscription-ids that
do not exist, the Printer returns them in this group as value of
the "subscription-ids" attribute.
Group 3 through N: Notification Attributes
The Printer object responds with one Event Notification per Group
for each Notification that meets the criteria specified by the
request.(see [ipp-ntfy]).
5 Extension to Print-Job, Print-URI, Create-Job, Create-Printer-
Subscription and Create-Printer-Subscription
5.1 Response
When Print-Job, Print-URI or Create-Job contains a "job-notify"
attribute and the "notify-recipient" is 'ipp', the response contains two
additional Operation Attributes that pertain to subscriptions.
When Create-Job-Subscription or Create-Printer-Subscription operation
contains a "notify-recipient" that is 'ipp', the response contains two
additional Operation Attributes that pertain to subscriptions.
Group 1: Operation Attributes
Manros, Hastings, Herriot, Lewis [page 12]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
"recommended-time-interval" (integer(0:MAX)):
The value of this attribute is the recommended number of seconds
that SHOULD elapse before the client SHOULD perform the Get-
Notification operation for the first time with any Subscription
objects returned with this job. A client MAY perform the Get-
Notification operation at any time, and a Printer MUST respond with
all existing Notifications. A client observes this value in order
to be a "good network citizen". The value that a Printer returns
for this attribute MUST NOT exceed 80% of the "event-lease-time-
interval" in order to give a client plenty of time to perform
another Get-Notifications operation before the event-lease of the
oldest events expire.
"event-lease-time-interval" (integer(0:MAX)):
The value of this attribute is the minimum number of seconds until
the event-lease expiration time for all future Event Notifications
associated with the Subscription objects generating the requested
Event Notifications. Thus this number is the maximum number of
seconds that elapses before a client SHOULD perform the Get-
Notification operation for the first time with any Subscription
objects returned with this job. A Printer MUST preserve all
Notifications that occur for the number of seconds specified by
this attribute starting at the time it is sent in a response. A
client MAY perform the Get-Notification operation at any time, and
a Printer MUST respond with all existing Event Notifications. If a
Printer receives a Get-Notification operation after this time
interval, it may have discarded some Notifications since the last
response.
6 Encoding
The operation-id assigned for the Get-Notification operation is:
0x00??
and should be added to the next version of [ipp-mod] section 4.4.15
"operations-supported".
This notification delivery method uses the IPP transport and encoding
[ipp-pro] for the Get-Notifications operation with one extension:
notification-attributes-tag = %x07 ; tag of 7
7 IANA Considerations
There is nothing to register.
Manros, Hastings, Herriot, Lewis [page 13]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
8 Internationalization Considerations
With the 'ipp' method defined in this document, the client cannot
request the Human Consumable form by supplying the "notify-format"
operation attribute (see [ipp-ntfy]). The only supported value for this
delivery method is "application/ipp". Therefore, the IPP Printer does
not have to perform any localization with this notification delivery
method. However, the client when it receives the Get-Notifications
response is expected to localize the attributes that have the 'keyword'
attribute syntax according to the charset and natural language requested
in the Get-Notifications request.
9 Security Considerations
The IPP Model and Semantics document [ipp-mod] discusses high level
security requirements (Client Authentication, Server Authentication and
Operation Privacy). Client Authentication is the mechanism by which the
client proves its identity to the server in a secure manner. Server
Authentication is the mechanism by which the server proves its identity
to the client in a secure manner. Operation Privacy is defined as a
mechanism for protecting operations from eavesdropping.
Unlike other Event Notification delivery methods in which the IPP
Printer initiates the Event Notification, with the method defined in
this document, the Notification Recipient is the client who issues the
Get-Notifications operation. Therefore, there is no chance of "spam"
notifications with this method. Furthermore, such a client can close
down the HTTP channel at any time, and so can avoid future unwanted
Event Notifications at any time.
10 References
[ipp-mod]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.1: Model and Semantics", <draft-ietf-
ipp-model-v11-06.txt>, March 1, 2000.
[ipp-ntfy]
Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
Bergman, R., "Internet Printing Protocol/1.1: IPP Event
Notification Specification", <draft-ietf-ipp-not-spec-02.txt>,
March 8, 2000.
[ipp-pro]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
05.txt, March 1, 2000.
[rfc2026]
S. Bradner, "The Internet Standards Process -- Revision 3", RFC
2026, October 1996.
Manros, Hastings, Herriot, Lewis [page 14]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
[RFC2616]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC 2616, June 1999.
11 Authors' Addresses
Carl-Uno Manros
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
Phone: 310-333-
Fax: 310-333-5514
e-mail: manros@cp10.es.xerox.com
Tom Hastings
Xerox Corporation
737 Hawaii St. ESAE 231
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com
Robert Herriot
Xerox Corp.
3400 Hill View Ave, Building 1
Palo Alto, CA 94304
Phone: 650-813-7696
Fax: 650-813-6860
e-mail: robert.herriot@pahv.xerox.com
Harry Lewis
IBM
P.O. Box 1900
Boulder, CO 80301-9191
Phone: (303) 924-5337
FAX:
e-mail: harryl@us.ibm.com
12 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
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,
Manros, Hastings, Herriot, Lewis [page 15]
Expires: September 8, 2000
INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
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
revoked by the Internet Society or its successors or assigns.
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.
Manros, Hastings, Herriot, Lewis [page 16]
Expires: September 8, 2000
