INTERNET-DRAFT
<draft-ietf-ipp-indp-method-00.txt>
Hugo Parra
Novell, Inc.
Tom Hastings
Xerox Corp.
March 9, 2000
Internet Printing Protocol (IPP):
The INDP Notification Delivery 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 event notification specification [ipp-ntfy] is an OPTIONAL
extension to IPP/1.0, IPP/1.1, and future versions. [ipp-ntfy] requires
the definition of one or more delivery methods for dispatching
Notifications to Notification Recipients. This document describes the
semantics and syntax of the INDP Notification Delivery Method that is
itself a request/response protocol. For this delivery method, an IPP
Printer sends (pushes) IPP event Notifications to the Notification
Recipients using the IPP Notification Delivery Protocol (INDP) defined
in [indp]. The Notification Recipient can either be the Ultimate
Recipient of the Notification or can be a Notification Service that
forwards the Notification to the Ultimate Recipient.
Parra, Hastings [page 1]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 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 (this document)
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]
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: 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 a message body over
HTTP 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.
Parra, Hastings [page 2]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
Table of Contents
1 Introduction ......................................................4
2 Terminology .......................................................4
3 Model and Operation ...............................................4
4 Notification Operations ...........................................5
4.1 SEND-NOTIFICATIONS OPERATION.....................................6
4.1.1 Send-Notifications Request ..................................6
4.1.2 Send-Notifications Response .................................7
4.2 NOTIFICATION PROTOCOL URI SCHEME.................................8
5 Encoding of the Operation Layer ...................................9
6 Encoding of Transport Layer .......................................9
7 IANA Considerations ...............................................9
8 Internationalization Considerations ...............................9
9 Security Considerations ...........................................9
9.1 SECURITY CONFORMANCE............................................10
10 References .......................................................10
11 Author's Addresses ...............................................11
12 Full Copyright Statement .........................................11
Parra, Hastings [page 3]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
1 Introduction
An IPP Printer that supports the OPTIONAL IPP event notification
extension [ipp-ntfy] is called a Notification Source which sends event
Notifications to Notification Recipients. As such, a Printer either a)
accepts, stores, and uses notification Subscription objects to generate
event Notification and implements one or more delivery methods for
notifying interested parties, or b) supports a subset of these tasks and
farms out the remaining tasks to a Notification Delivery Service. The
INDP Notification Delivery Method specified in this document employs a
request/response protocol, which is a subset of the IPP Notification
Delivery Protocol (INDP), defined in [indp]. A Notification Source may
implement the INDP Notification Delivery Method to send (push) event
notifications to Notification Recipients using the INDP Send-
Notifications operation (see section 4.1) over HTTP.
2 Terminology
This document uses terms such as "attributes", "keywords", and
"support". These terms have special meaning and are defined in the
model terminology [ipp-mod] section 12.2.
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
MAY, NEED NOT, and OPTIONAL, have special meaning relating to
conformance. These terms are defined in [ipp-mod] section 12.1 on
conformance terminology, most of which is taken from RFC 2119 [RFC2119].
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.
Event Notification (Notification for short) - See [ip-ntfy]
Notification Source - See [ipp-ntfy]
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], a client is able to:
Parra, Hastings [page 4]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
1.supply one or more Per-Job Subscriptions in the Job Creation
operation
2.OPTIONALLY supply Per-Job Subscriptions as subsequent Create-Job-
Subscription operations
3.Supply one Per-Printer Subscription in the Create-Printer-
Subscription 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 notification
method is 'indp' and the rest of the URI is the address of the
Notification Recipient to which the IPP Printer will send the INDP Send-
Notifications operation.
The INDP Notification Delivery Method defined in this document also uses
a client/server protocol paradigm. The "client" in this HTTP
relationship is the Notification Source described in [ipp-ntfy] while
the "server" is the Notification Recipient. The Notification Source
invokes the Send-Notifications operation supported in INDP to
communicate IPP event Notification contents to the Notification
Recipient. The Notification Recipient only conveys information to the
Notification Source in the form of responses to the operations initiated
by the Notification Source.
Notification Sources that implement the INDP Notification Delivery
Method will need to include an INDP client stack (and hence an HTTP
client stack) while notification recipients that implement this delivery
method will need to support an INDP server stack (and hence an HTTP
server stack). See section 6 for more details.
4 Notification Operations
The Notification Source composes the information defined for an IPP
Notification [ipp-ntfy] and sends it using the Sent-Notifications
operation to the Notification Recipient supplied in the Subscription
object.
Parra, Hastings [page 5]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
INDP makes extensive use of the operations model defined by IPP
[rfc2566]. This includes, the use of a URI as the identifier for the
target of each operation, the inclusion of a version number, operation-
id, and request-id in each request, and the definition of attribute
groups. The Send-Notifications operation uses the Operation Attributes
group, but currently has no need for the Unsupported Attributes, Printer
Object Attributes, and Job-Object Attributes groups. However, it uses a
new attribute group, the Notification Attributes group (see [indp]).
4.1 Send-Notifications Operation
This REQUIRED operation allows a Notification Source to send one or more
Notifications to a Notification Recipient using HTTP. The operation has
been tailored to accommodate the current definition of IPP Notification
[ipp-ntfy].
Both Machine-Consumable and Human-Consumable notifications may be sent
to a Notification Recipient through this operation.
4.1.1 Send-Notifications Request
Every operation request contains the following REQUIRED parameters (see
[ipp-mod] section 3.1.1):
- a "version-number"
- an "operation-id"
- a "request-id"
The following groups of attributes are part of the Send-Notifications
Request:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes ads defined in [rfc 2566] section 3.1.4.1.
Target:
The "notification-recipient-uri" (uri) operation attribute
which is the target of this operation as described in [ipp-
mod] section 3.1.5, i.e., the URI of the 'indp' Notification
Recipient.
Group 2 to N: Notification Attributes
"human-readable-report" (text)
The 'indp' Notification Source OPTIONALLY supports this attribute.
This attribute is a text string generated by the IPP printer or
Notification Delivery Service from the contents of the IPP
Parra, Hastings [page 6]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
Notification suitable for human consumption. If the Notification
Source supports this attribute, it MUST supply this attribute if
the Subscription object contains the "notify-text-format"
(mimeMediaType) attribute. The text value of this attribute MUST
be localized in the charset identified by the "notify-charset"
(charset) attribute and the natural language identified by the
notify-natural-language" (naturalLanguage) attribute supplied in
the associated Subscription object that generates this event
Notification. The format of the text value is specified by the
value of the "notify-text-format" (mimeMediaType) supplied in the
associated Subscription object.
"human-readable-report-format" (mime)
This attribute MUST be supplied by the Notification Source whenever
the "human-readable-report" attribute is present. It indicates the
format, e.g., text/plain, text/html, etc. of the "human-readable-
report" attribute.
All of the REQUIRED attributes and any of the OPTIONAL attributes
indicated in [ipp-ntfy] for a Push event Notification, including
"notify-text-format-type" (mimeMediaType), if the "human-readable-
report" (text) attribute is included, so that the Notification
Recipient will know the text format of the "human-readable-report"
(text) attribute value.
These attributes communicate the same information as the notification
attributes by the same name described in sections 7.4, 7.5, and 7.6
of [ipp-ntfy]. The rules that govern when each individual attribute
MUST or MAY be included in this operation precisely mirror those
specified in [ipp-ntfy].
4.1.2 Send-Notifications Response
The 'indp' Notification Recipient returns a status code for the entire
operation and one for each Notification Report in the request if the
operation's status code is other than "successful-ok". If the 'indp'
Notification Recipient receives a Notification report that it can't pair
up with a Subscription it knows about, it can return a 'client-error-
unknown-subscription' error status-code to indicate that events
associated with that subscription should no longer be sent to it.
Alternatively, the Notification Recipient can return the 'successful-ok-
but-cancel-subscription' to the Notification Source and cancel a
Subscription that is no longer wanted.
Every operation response contains the following REQUIRED parameters (see
[ipp-mod] section 3.1.1}:
- a "version-number"
- a "status-code"
Parra, Hastings [page 7]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
- the "request-id" that was supplied in the corresponding request
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes ads defined in [rfc 2566] section 3.1.4.1.
ISSUE 01 _ Should there be an Unsupported Attributes group to return
attributes that are not supported to the client?
Group 2 to N: Notification Attributes
"notification-report-status-code" (type2 enum)
Indicates whether the 'ipp-notify-send' Notification Recipient was
able to consume the n-th Notification Report.
The following standard enum values are defined:
'successful-ok'
'successful-ok-but-cancel-subscription'
'client-error-unknown-subscription'
'client-error-bad-request'
ISSUE 02 _ Should this use the same status code space as IP, namely:
"successful" _ 0x0000 to 0x00FF
"informational" _ 0x0100 to 0x01FF
"redirection" _ 0x0400 to 0x04FF
"server-error" _ 0x0500 to 0x05FF
ISSUE 03 _ What status code from IPP can we re-use?
ISSUE 04 _ Where should the status code be defined? Here, in [indp], in
[ipp-ntfy], or in [ipp-mod]?
ISSUE 05 _ Since there is an overall status code for the entire
operation and one fore each Notification, what status code is returned
for the overall operation, if one Notification succeeds and another
fails? Do we need a status code for this such as 'client-error-some-
notifications-failed'?
4.2 Notification Protocol URI Scheme
The INDP Notification Delivery Method uses the 'indp://' URI scheme in
the "notify-recipients" attribute in the Subscription object in order to
indicate the notification delivery method defined in this document. The
remainder of the URI indicates the host and address of the Notification
Recipient that is to receive the Send-Notification operation.
Parra, Hastings [page 8]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
5 Encoding of the Operation Layer
The INDP Notification Delivery Method uses the INDP operation layer
encoding described in [indp].
6 Encoding of Transport Layer
The INDP Notification Delivery Method uses the INDP transport layer
encoding described in [indp].
It is REQUIRED that an 'indp' Notification Recipient implementation
support HTTP over the IANA assigned Well Known Port XXX (the INDP
default port), though a notification recipient implementation MAY
support HTTP over some other port as well.
7 IANA Considerations
The 'indp://' URL scheme and the IDNP default fort will be registered
with IANA.
8 Internationalization Considerations
When the client requests Human Consumable form by supplying the "notify-
text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or
any Notification Service that the IPP Printer might be configured to
use) supplies and localizes the text value of the "human-readable-
report" attribute in the Notification according to the charset and
natural language requested in the notification subscription.
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.
The Notification Recipient can cancel unwanted Subscriptions created by
other parties without having to be the owner of the subscription by
returning the 'successful-ok-but-cancel-subscription' status code in the
Send-Notifications response returned to the Notification Source.
Parra, Hastings [page 9]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
9.1 Security Conformance
Notification Sources (client) MAY support Digest Authentication
[rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess
MUST be supported, but the Message Integrity feature NEED NOT be
supported.
Notification Recipient (server) MAY support Digest Authentication
[rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess
MUST be supported, but the Message Integrity feature NEED NOT be
supported.
Notification Recipients MAY support TLS for client authentication,
server authentication and operation privacy. If a notification recipient
supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites
are OPTIONAL. Notification recipients MAY support Basic Authentication
(described in HTTP/1.1 [rfc2616]) for client authentication if the
channel is secure. TLS with the above mandated cipher suite can provide
such a secure channel.
10 References
[indp]
Parra, H., T. Hastings, "Internet Printing Protocol (IPP): IPP
Notification Delivery Protocol (INDP)", <draft-ietf-indp-00.txt>,
February 29, 2000.
[ipp-mod]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: 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>,
February 2, 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.
Parra, Hastings [page 10]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 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.
[rfc2617]
J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A.
Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
11 Author's Addresses
Hugo Parra
Novell, Inc.
1800 South Novell Place
Provo, UT 84606
Phone: 801-861-3307
Fax: 801-861-2517
e-mail: hparra@novell.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
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,
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
Parra, Hastings [page 11]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000
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.
Parra, Hastings [page 12]
Expires: Sep 9, 2000
