INTERNET-DRAFT
<draft-ietf-ipp-indp-00.txt>
Hugo Parra
Novell, Inc.
Tom Hastings
Xerox Corporation
March 9, 2000
Internet Printing Protocol (IPP):
IPP Notification Delivery Protocol (INDP)
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] which
enables IPP clients to request notification of printer and job events.
The IPP notification extension gives IPP Printers the flexibility to
choose how many Subscriptions objects (individual requests for
notification), what delivery methods, and what natural languages to
support, among others. In practice, it's the working environment where
an IPP Printer is deployed what ultimately dictates the notification
requirements for that printer. Notification Delivery Services exist to
help event producers, such as IPP Printers, meet the varying
notification needs of disparate environments. Specifically, an IPP
Notification Delivery Service may extend the notification capabilities
of IPP Printers and help customize the type of notification required in
Parra, Hastings [page 1]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
a highly specialized environment. This documents defines the IPP
Notification Delivery Protocol (INDP), a protocol for IPP Printers to
communicate with Notification Delivery Services using "application/ipp"
as the encoding mechanism and HTTP as the transport. The definition of
INDP lends itself nicely for use by IPP Printers and Notification
Delivery Services for dispatching IPP Notifications to Notification
Recipients as well.
Parra, Hastings [page 2]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol 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 3]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
Table of Contents
1 Introduction ......................................................6
2 Terminology .......................................................6
3 Model and Operation ...............................................7
3.1 NOTIFICATION DELIVERY SERVICE MODEL..............................7
3.1.1 Server Object ...............................................7
3.1.2 Subscription Object .........................................8
3.2 NOTIFICATION DELIVERY SERVICE OPERATION..........................8
3.2.1 Notification without Notification Delivery Services .........9
3.2.2 Delivery method support extension (INDPa) ..................11
3.2.3 Natural language support extension (INDPb) .................12
3.2.4 Subscription object management outsource (INDPc) ...........12
4 Notification Operations ..........................................15
4.1 GET-NOTIFY-SERVICE-ATTRIBUTES...................................15
4.1.1 Get-Notify-Service-Attributes Request ......................16
4.1.2 Get-Notify-Service-Attributes Response .....................16
4.2 VALIDATE-NOTIFY-TARGET-URI OPERATION............................17
4.2.1 Validate-Notify-Target-Uri Request .........................17
4.2.2 Validate-Notify-Target-Uri Response ........................17
4.3 SEND-NOTIFICATIONS OPERATION....................................18
4.3.1 Send-Notifications Request .................................18
4.3.2 Send-Notifications Response ................................20
4.4 REGISTER-NOTIFICATION-SOURCE OPERATION..........................20
4.4.1 Register-Notification-Source Request .......................21
4.4.2 Register-Notification-Source Response ......................21
4.5 CANCEL-NOTIFICATION-SOURCE-REGISTRATION OPERATION...............22
4.5.1 Cancel-Notification-Source-Registration Request ............22
4.5.2 Cancel-Notification-Source-Registration Response ...........23
4.6 RENEW-NOTIFICATION-SOURCE-REGISTRATION OPERATION................23
4.6.1 Renew-Notification-Source-Registration Request .............23
4.6.2 Renew-Notification-Source-Registration Response ............24
4.7 CREATE-SUBSCRIPTION OPERATION...................................24
4.7.1 Create-Subscription Request ................................24
4.7.2 Create-Subscription Response ...............................25
4.8 VALIDATE-SUBSCRIPTION OPERATION.................................25
4.8.1 Validate-Subscription Request ..............................25
4.8.2 Validate-Subscription Response .............................26
4.9 CANCEL-SUBSCRIPTION OPERATION...................................26
4.9.1 Cancel-Subscription Request ................................26
4.9.2 Cancel-Subscription Response ...............................26
4.10 RENEW-SUBSCRIPTION OPERATION ..................................27
4.10.1 Renew-Subscription Request ................................27
4.10.2 Renew-Subscription Response ...............................28
4.11 GET-SUBSCRIPTIONS OPERATION ...................................28
Parra, Hastings [page 4]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
4.11.1 Get-Subscriptions Request .................................28
4.11.2 Get Subscriptions Response ................................28
5 Encoding of the Operation Layer ..................................28
5.1 NEW ATTRIBUTE TAG...............................................29
5.2 NEW STATUS CODES................................................29
5.2.1 unknown-notification-recipient. (0xXXX) ....................29
5.2.2 unable-to-delivery-notification-report (0xXXX) .............29
5.2.3 successful-ok-but-cancel-subscription (0xXXXX) .............29
5.2.4 unknown-registration-id (0xXXX) ............................30
5.2.5 successful-ok-but-error-accessing-persistent-storage () ....30
5.3 ENCODING........................................................30
6 Encoding of Transport Layer ......................................31
7 IANA Considerations ..............................................32
8 Internationalization Considerations ..............................33
9 Security Considerations ..........................................33
9.1 SECURITY CONFORMANCE............................................33
10 References .......................................................34
11 Author's Addresses ...............................................34
12 Full Copyright Statement .........................................35
Parra, Hastings [page 5]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol 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 Notifications 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
IPP Notification Delivery Protocol (INDP) specified in this document is
a request/response protocol that may be used in a variety of
notification scenarios. Its primary intended use is for IPP Printers to
engage the assistance of Notification Delivery Services for storing
notification Subscriptions, generating human-readable notifications in
various languages, and implementing additional delivery methods.
Moreover, IPP Printers and Notification Delivery Services in their role
as Notification Sources may use INDP to send (push) event notifications
to Notification Recipients.
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]
Parra, Hastings [page 6]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
3 Model and Operation
In the IPP Notification Model [ipp-ntfy], print clients request an IPP
Printer for event notification by causing a Subscription object to be
created at the printer. [ipp-ntfy] specifies a number of ways in which
Subscription objects can be created. Each Subscription object lists the
events of interest, the delivery method to be employed, and the address
to which notifications should be dispatched, among others. When an
event occurs, the printer is responsible for notifying each Notification
Recipient that has registered interest in that event, using delivery
method requested by that Notification Recipient. IPP Printers may
employ the assistance of Notification Delivery Services to accomplish
some or all of these tasks.
IPP Printers with support for Notification Delivery Services must
support a new printer description attribute, "notification-delivery-
services-uri-supported" (1SetOf uri). This attribute needs to be
populated with the uri's of the Notification Delivery Services the
printer is configured to use. Whether IPP Printers dynamically discover
Notification Delivery Services on the network or need to be configured
by a system administrator it implementation dependant.
3.1 Notification Delivery Service Model
The INDP 1.0 model defines objects of type Server and Subscription.
Each object definition includes a set of attributes that describe the
state and workings of a Notification Delivery Service. An IPP Printer
interact with instances of these object types by issuing INDP
operations. This section describes the attributes that compose the
Server and Subscription objects with their corresponding attribute
syntaxes and values that are part of the Notification Delivery Service
Model. Each attribute is uniquely identified in this document using a
"keyword" as defined in the IPP/1.1: Model and Semantics document [ipp-
mod]. INDP 1.0 defines The Notification Delivery Service
3.1.1Server Object
The Server object represents the state and capabilities of a
Notification Delivery Service. It implements the server-side of INDP.
In version 1.0 of INDP, the Server object contains information about the
capabilities of a Notification Delivery Service that are of interest to
an IPP Printer.
The following attributes comprise the Server object. Their description
and intended use follow.
- notify-natural-languages-supported
- notify-uri-schemes-supported
Parra, Hastings [page 7]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
3.1.1.1 notify-natural-languages-supported (1setOf naturalLanguage)
This REQUIRED Server object attribute describes the natural languages
supported by the Notification Delivery Service for the generation of
human-consumable Notifications.
3.1.1.2 notify-uri-schemes-supported (1setOf uriScheme)
This REQUIRED Server object attribute describes the notification
delivery methods supported by the Notification Delivery Service.
Standard values are defined in [ipp-ntfy] Section 5.1.
3.1.2Subscription Object
The Subscription object represents a request for notification.
Subscription Objects are contained by a Server object and are created as
a result of an IPP Printer issuing a Create-Subscription operation. The
syntax and semantics of a Subscription object exactly mirror those of
the Subscription object defined in the IPP Notification spec [ipp-ntfy].
3.2 Notification Delivery Service Operation
The figure below illustrates four different configurations through which
an IPP Printer may implement support for IPP notification. Each
configuration is discussed in this section.
Legend:
INDPx represents three different subsets of INDP operations the IPP
Printer uses to communicate with the Notification Delivery
Service to realize three different levels of support.
any represents any protocol, including INDP, that the IPP Printer
or the Notification Delivery Service may support for notifying
interested Notification Recipients.
Parra, Hastings [page 8]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
O +------+ +-----------+
/|\ |client| --IPP--> |IPP Printer|
/ \ +------+ +-----------+
^ |
+-------any-------+
Notification Dlvry. Svc.
+-----------+
+------INDPa------> | Extended |
O +------+ +-----------+ / +--+ Support |
/|\ |client| --IPP--> |IPP Printer| | for |
/ \ +------+ +-----------+ +---+ Delivery |
^ | Methods |
\ +-------------------+
\ |
+-----------------------any-----------------------+
Notification Dlvry. Svc.
+-----------+
| Extended |
O +------+ +-----------+ +--+ Support |
/|\ |client| --IPP--> |IPP Printer| -----INDPb-----> | for |
/ \ +------+ +-----------+ +---+ Natural |
^ | Languages |
\ +-------------------+
\ |
+-----------------------any-----------------------+
Notification Dlvry. Svc.
+-----------+
| Extended |
O +------+ +-----------+ +---+ Support |
/|\ |client| --IPP--> |IPP Printer| | for |
/ \ +------+ +-----------+ \ +---+ Subscription|
^ +--INDPc--> | Objects |
\ +-------------------+
\ |
+-----------------------any-----------------------+
3.2.1 Notification without Notification Delivery Services
An IPP Printer working without the assistance of a Notification Delivery
Service must implement on its own at least the minimum set of
functionality required by the IPP Notification spec. This section gives
a summary of the process a typical IPP Printer may employ to support IPP
notifications on its own. The IPP Notification spec [ipp-ntfy] provides
a detailed description of this process. Subsequent sections will
describe how an IPP Printer may use INDP to indirectly accomplish some
of the following tasks.
Parra, Hastings [page 9]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
a)Creating a Subscription object. The IPP notification spec [ipp-ntfy]
describes a number of mechanisms for IPP clients to request
notification of an IPP printer. The end result, however, is that a
Subscription object is instantiated at the IPP printer containing the
information needed by the printer to know who to notify, how, and of
what events.
b)Validating the Subscription object. At Subscription object
instantiation time, the IPP printer validates its contents to make
sure the requested events and delivery methods are supported. The
IPP printer may also perform some validation on the recipient uri,
requested natural language, and other information contained in the
Subscription object.
c)Storing the Subscription object. The IPP printer provides persistent
and non-persistent storage for Subscription objects until de object's
lease expires (in the case of per-printer subscriptions) or their
associated print job is removed (in the case of per-job
subscriptions). The IPP notification spec [ipp-ntfy] outlines the
minimum number of Subscription objects a printer MUST be able to
store. In practice, this requirement will vary widely depending on
the administrative practices and usage patterns of the printer's
users.
d)Event condition. Normal printer operation as well as printer
exception circumstances will cause event conditions to be raised.
e)Matching event with subscriptions. For each raised event condition
the printer finds all the Subscription objects that request
notification of that event. Rather than inspecting each Subscription
object each time an event condition is raised, an IPP Printer may
keep a list of the events the combined Subscription objects have
requested to quickly discard event conditions no one is interested
in.
f)Generating human-readable notification data. The IPP Printer
examines each Subscription object found in step (e) to determine if
it needs to generate human-readable notification information for it.
IPP Printers with users of different language preferences may need to
provide translation for multiple natural languages.
g)Dispatching the notification via the specified delivery method. The
IPP Printer may need to generate slightly different Notification
payloads for different delivery methods. With Notifications
generated for each target Recipient, the IPP Printer uses its
implementation of the delivery method specified in the corresponding
Parra, Hastings [page 10]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
Subscription object to dispatch the notification to its intended
Recipient.
Though in this scenario the IPP Printer does not need to interact with a
Notification Delivery Service, it may use INDP to dispatch Notifications
encoded in "application/ipp" and transported over HTTP to interested
notification Recipients. IPP Printers may use the Send-Notifications
operation to accomplish this task.
3.2.2 Delivery method support extension (INDPa)
An IPP Printer may use a Notification Delivery Service simply to extend
the list of delivery methods it supports. Doing so offloads a printer
from having to implement all the common delivery methods its potential
clients might require. It also enables a generic printer to support
very specialized delivery methods implemented by a site's Notification
Delivery Service. Moreover, by using existing Notification Delivery
Methods, an IPP Printer can take advantage of present, widely deployed
notification infrastructure, standards-based or proprietary.
Using a Notification Delivery Service for the sole purpose of extending
the notification delivering capabilities on and IPP Printer results in
very small changes to the notification process described in the previous
section. Specifically, the following changes apply.
1)Before accepting requests to create Subscription objects, step (a)
above, the IPP Printer gets a list of the uri schemes the
Notification Delivery Service supports and adds the values to its
"notify-schemes-supported" attribute. To obtain this list, the IPP
Printer uses the Get-Notify-Service-Attributes operation requesting
the "notify-schemes-supported" attribute from the Notification
Delivery Service. To an IPP client reading the printer's "notify-
schemes-supported" attribute, the entries with internal support and
those supported via a Notification Delivery Service are
indistinguishable.
2)During Subscription object validation, step (b) above, the IPP
Printer may communicate with the Notification Delivery Service to
validate a target uri requesting a delivery method implemented in the
Notification Delivery Service. This IPP Printer accomplishes through
the Validate-Notification-Uri operation.
3)For dispatching notifications that require a delivery method
implemented in the Notification Delivery Service, step (g) above, the
IPP Printer forwards the Notification on to the Notification Delivery
Parra, Hastings [page 11]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
Service through the Send-Notifications operation. The IPP Printer
must provide the target uri and human-readable data, when the case
requires it. The Notification Delivery Service is then responsible
for creating a Notification payload suitable for the requested
delivery method and for dispatching the notification to the specified
Recipient.
3.2.3 Natural language support extension (INDPb)
An IPP Printer may use a Notification Delivery Service to generate
human-readable notification data in addition to extending its delivery
methods support. By using a Notification Delivery Service in this
manner, an IPP Printer can dynamically support notifications in any
number of natural languages, as long as the Notification Delivery
Service being used supports them.
In addition to the modifications to the notification process listed in
section 3.2, the following changes result from using a Notification
Delivery Service to generate human-readable notification data.
1)Before accepting requests to create Subscription objects, step (a)
above, the IPP Printer must communicate with the Notification
Delivery Service to get a list of the natural languages it supports
for human-readable message generation and add these values to its own
"notify-natural-languages-supported" attribute.
ISSUE 01: Do we have any use for the printer description attribute
"notify-natural-languages-supported"?
2)The IPP Printer no longer needs to perform steps (f) and (g) above.
Instead it uses the Send-Notifications operation to send the
Notification to the Notification Delivery Service along with the
language specified in the corresponding Subscription object.
3.2.4 Subscription object management outsource (INDPc)
Through INDP an IPP Printer can employ the full services of a
Notification Delivery Service, which includes storing and managing
Subscription objects on behalf of the printer. Outsourcing this type of
functionality greatly reduces the logic and resources requirements for
an IPP Printer to support notification. Suitably hosted Notification
Delivery Services can meet the notification needs of an environment
without having to increase the capabilities of each printer in that
Parra, Hastings [page 12]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
environment. This section describes how an IPP Printer interacts with a
Notification Delivery Service to accomplish this level of interaction.
This notification configuration requires the IPP Printer to establish a
temporary registration with the Notification Delivery Service. Through
a lease-based relationship, the Notification Delivery Service can keep
track of what Subscription objects belong to what IPP Printer and
generate the appropriate notifications when events are reported. This
mechanism also enables the Notification Delivery Service to clean up
orphaned Subscription objects. The IPP Printer uses the Register-Event-
Producer operation to establish this type of relationship with the
Notification Delivery Service. The model requires that an IPP Printer
renew its lease periodically using the Renew-Registration operation.
When registering, an IPP Printer can specify a location for a
Notification Delivery Service to store Subscription objects
persistently. Subscription objects stored persistently in previous
registrations are automatically re-instantiated when an IPP Printer
registers with a Notification Delivery Service. The printer instructs
the Notification Delivery Service what Subscription objects should be
stored persistently and which one should be automatically disposed when
the registration expires.
Once registered, the IPP Printer may forward requests to create
Subscription objects on to the Notification Delivery Service. The IPP
Printer uses the Create-Subscription operation to accomplish this task.
In this notification configuration an IPP Printer only needs to keep
track of the superset of events requested by all the Subscription
objects combined. The Notification Delivery Service assists the IPP
Printer accomplish this task. First, in the response of a successful
registration request, the Notification Delivery Service returns to the
printer the list of events that it must generate to satisfy any
Subscription objects that might have been reinstated from persistent
storage. Then, in the response to every successful request to add or
delete Subscription objects, the Notification Delivery Service returns
to the printer a list of the new events needed and those to be
discontinued as a result of the operation.
The following summarizes an IPP Printer's process for handling
notification when making full use of a Notification Delivery Service's
capabilities. For simplification, the description assumes that the IPP
Printer supports these capabilities only via a Notification Delivery
Service and not directly. However, for printers that implement some
delivery methods internally and support others through a Notification
Delivery Service, the notification process is a combination of the
process outlined below and the one summarized in section 3.1.1.
Parra, Hastings [page 13]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
a)Register with Notification Delivery Service. Early in its
initialization process the IPP Printer should use the Register-Event-
Producer operation to register with a Notification Delivery Service
if configured to do so. It must indicate to the Notification
Delivery Service the location of its persistent Subscription object
storage, if applicable. The IPP Printer must store away the
registration Id returned by the operation and remember any events
listed in the response so it can start generating them.
b)Get Notification Delivery Service information. Right after
registering with a Notification Delivery Service, the IPP Printer
should query the Notification Delivery Service's "notify-uri-schemes-
supported" and "notify-natural-languages-supported" attributes. The
printer must populate its "notify-uri-schemes-supported" and "notify-
natural-languages-supported" attributes with the information
obtained.
c)Create Subscription objects. When the IPP Printer receives a client
request to create a new Subscription object, it must forward the
request to the Notification Delivery Service using the Create-
Subscription operation. This results in the Notification Delivery
Service instantiating and validating a Subscription object. If the
operation to create a new Subscription object succeeds, its response
portion will tell the IPP Printer what, if any, new events it must
generate to satisfy the new request. As with print jobs Subscription
objects do not become active while the job is in "job-pending" state,
the IPP Printer would not send a request to create a new Subscription
object to the Notification Delivery Service until just before the job
changes states from "job-pending". For these types of notification
requests, the IPP Printer may instead issue the Validate-Subscription
operation to request that the Notification Delivery Service simply
validate the request, thus allowing the printer to return an accurate
status code to IPP operations requesting per-job notifications.
d)Event condition. The IPP Printer uses the consolidated list of
events it maintains with the help of the Notification Delivery
Service to know what events are of interest.
e)Send event report. When the IPP Printer raises an event condition,
it reports the event to the Notification Delivery Service using the
Send-Notification operation. At that point the IPP Printer is
finished processing the event condition. The Notification Delivery
Service is responsible for matching the event with the Subscription
objects that requested it, generating any human-consumable data in
the natural language specified in the Subscription object, and
dispatching the appropriately formatted Notification using the
requested delivery method.
Parra, Hastings [page 14]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
4 Notification Operations
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. INDP operations use the Operation Attributes group, but
currently have 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.
The following operations form version 1.0 of INDP. All operations are
targeted at the Server object. This section formally defines each INDP
1.0 operation.
- Get-Notify-Service-Attributes
- Validate-Notify-Target-Uri,
- Send-Notifications
- Register-Notification-Source
- Cancel-Notification-Source-Registration
- Renew-Notification-Source-Registration
- Create-Subscription
- Validate-Subscription
- Cancel-Subscription
- Renew-Subscription
- Get-Subscriptions
Every operation request contains the following REQUIRED parameters (see
[ipp-mod] section 3.1.1):
- a "version-number"
- an "operation-id"
- a "request-id"
Every operation response contains the following REQUIRED parameters (see
[ipp-mod] section 3.1.1}:
- a "version-number"
- a "status-code"
- the "request-id" that was supplied in the corresponding request
4.1 Get-Notify-Service-Attributes
This REQUIRED operation allows an IPP Printer to request the values of
attributes of a Server object. In the request, the IPP Printer supplies
the set of Server attribute names it's interested in. In the response,
the Service object returns a corresponding attribute set with the
appropriate attribute values filled in.
Parra, Hastings [page 15]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
4.1.1 Get-Notify-Service-Attributes Request
The following sets of attributes are part of the Get-Service-Attributes
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.
"server-uri":
The URI of the Notification Delivery Service.
"requested attributes" (1setOf keyword):
The IPP Printer OPTIONALLY supplies a set of attribute names
in whose values the requester is interested. The Service
object MUST support this attribute. If the IPP Printer omits
this attribute, the Notification Delivery Service MUST respond
with a list of all the attributes it supports and it
respective values.
4.1.2 Get-Notify-Service-Attributes Response
The Server object returns the following sets of attributes as part of
the Get-Notify-Service-Attributes Response:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as defined in [rfc 2566] section 3.1.4.1.
Group 2: Unsupported Attributes
A list of the attribute names requested by the IPP Printer but not
supported by the Service object. See [rfc 2566] section 3.1.7 for
details on returning Unsupported Attributes. As in version 1.0 of
INDP all defined Service object attributes are mandatory, this
group is a forward-looking feature when new OPTIONAL attributes may
be defined.
Group 3: Server Object Attributes
This is the set of requested attributes and their current values.
The Server object ignores any requested attribute that is not
supported. The Service object MAY respond with a subset of the
supported attribute and valued, depending on the security policy in
force. However, the Service object MUS respond with the 'unknown'
value for any supported attribute for which the Service object does
Parra, Hastings [page 16]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
not know the value. For a description of "out-of-band" values see
[rfc 2566] section 4.1.
4.2 Validate-Notify-Target-Uri Operation
This REQUIRED operation allows an IPP Printer to request that the
Notification Delivery Service validate a notification target uri. The
Service object successfully validates the uri if the Notification
Delivery Service implements the delivery method implied by the uri
scheme or the target uri. The Service object is free to perform
extended analysis on the validity of the recipient's address provided in
the uri is the semantics of the delivery method so allow.
4.2.1 Validate-Notify-Target-Uri Request
The following sets of attributes are part of the Validate-Notify-Target-
Uri 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.
"server-uri":
The URI of the Notification Delivery Service.
"notify-target-uri" (uri):
The IPP Printer MUST supply this attribute. The Notification
Delivery Service MUST support this attribute. It is the uri
to be validated by the Server object.
4.2.2 Validate-Notify-Target-Uri Response
The Server object returns the following set of attributes as part of the
Validate-Notify-Target-Uri Response:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as defined in [rfc 2566] section 3.1.4.1.
Parra, Hastings [page 17]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
"validation-code" (boolean):
The Server object MUST return this attribute with a value of
TRUE if the notify-target-uri was validates successfully;
FALSE otherwise.
4.3 Send-Notifications Operation
This REQUIRED operation allows an IPP Printer to send one or more
Notifications to a Notification Delivery Service. The Send-Notification
operation can be used to transport Notification data in all four
notification configurations described in section 3.2. Different
attributes will be required depending on whether the operation is being
used a) by an IPP Printer or Notification Delivery Service to send
Notifications directly to a notification Recipient, b) by an IPP Printer
to Send a localized Notification to a Notification Delivery Service
(INDPa), c) by an IPP Printer to Send a Notification to be localized and
dispatched by the Notification Delivery Service (INDPb), or d) by an IPP
Printer to send a target-less notification using an established
registration to a Notification Delivery Service (INDPc).
Both Machine-Consumable and Human-Consumable notifications may be
included in the Send-Notification operation.
4.3.1 Send-Notifications Request
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 as defined in [rfc 2566] section 3.1.4.1.
Target:
The Target can a) The URI of the Notification Delivery Service
if an IPP Printer is using Send-Notifications to dispatch
notifications, or b) the URI of the Notification Recipient if
the IPP Printer or the Notification Delivery Service are using
the operation to dispatch notifications directly to a
Notification Recipient.
"ultimate-target-uri":
This attribute MUST be supplied by the IPP Printer when it
uses the Send-Notifications operation to send notifications to
a Notification Delivery Service without having registered as a
Notification Source, i.e., configurations INDPa and INDPb
above.
Parra, Hastings [page 18]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
"registration-id":
This attribute MUST be supplied by the IPP Printer when it
uses the Send-Notifications operation to send notifications to
a Notification Delivery Service after having registered a as a
Notification Source, i.e., configuration INDPc above.
Group 2 to N: Notification Attributes
"human-readable-report" (text)
The 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
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.
Parra, Hastings [page 19]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
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] with the following exception: if the Send-Notifications
operation is being used by an IPP Printer to communicate events to
a Notification Delivery Service using a "registration-id", Group 2
of this operation MUST only include the "trigger-event", "trigger-
time", and "trigger-date-time" Notification attributes.
4.3.2 Send-Notifications Response
The target of the Send-Notifications operation, Notification Delivery
Method or 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 "success-ok". If the Notification
Recipient receives a Notification report that it can't pair up with a
subscription it knows about, it can return an error status-code to
indicate that events associated with that subscription should no longer
be sent to it.
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.
Group 2 to N: Notification Attributes
"notification-report-status-code" (type2 enum)
Indicates whether the intended target, i.e., Notification
Delivery Service or Notification Recipient was able to consume
the n-th Notification Report.
4.4 Register-Notification-Source Operation
This REQUIRED operation allows an IPP Printer to register itself as a
Notification Source with a Notification Delivery Service. While
registered, the Printer can add Subscription objects to the Server
object. The Printer can then send Notifications to the Server object
for the Server object to dispatch Notifications to all interested
Recipients.
Parra, Hastings [page 20]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
4.4.1 Register-Notification-Source Request
The following sets of attributes are part of the Register-Notification-
Source 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.
"server-uri":
The URI of the Notification Delivery Service.
"registration-lease-time-requested" (integer(0:86,400)):
This REQUIRED attribute specifies the time in the future when
the IPP Printer would like its registration lease to expire.
When the Server object accepts a Registration request, it
keeps track of this information. When the expiration time
arrives, the Server object purges the registration.
An IPP Printer is able to extend its registration lease using
the Renew-Notification-Source-Registration operation. The
maximum value for a registration lease is one day.
"notification-source-name" (name(127)):
This REQUIRED attribute specifies the name of the IPP Printer.
The Server object may use this information to organize current
registrations. This information may also be useful to a
Notification Delivery Service's manager. Note: Management of
a Notification Delivery Service is outside the scope of INDP
v1.0.
"persistent-registration-storage-uri" (uri):
Through this OPTIONAL attribute an IPP Printer may communicate
to the Service object where to retrieve persistent
Subscriptions from previous registrations. The Service object
also uses this location to store away future persistent
Subscriptions. It the IPP Printer doesn't provide this
attribute, it will not be able to add Subscription objects
that require persistent storage.
4.4.2 Register-Notification-Source Response
The Server object returns the following set of attributes as part of the
Register-Notification-Source Response:
Group 1: Operation Attributes
Parra, Hastings [page 21]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as defined in [rfc 2566] section 3.1.4.1.
"registration-id" (integer(0:MAX)):
The Server object MUST return the registration ID that the IPP
Printer can use in subsequent calls such as Renew-
Notification-Source-Registration, Create-Subscription, etc.
"notify-events" (1setOf type2 keyword):
If in this operation's request the IPP Printer specifies a
"persistent-registration-storage-uri" and as a result one or
more Registrations are instantiated by the Server object
during registrations, this attribute MUST contain the list of
events that the printer must notify the Server object of to
satisfy those Subscriptions.
"registration-lease-expiration-time" (integer(0:86,400)):
This REQUIRED attribute specifies the time in the future when
the registration lease will expire. If the Server object is
not able to grant the lease-time requested by the IPP Printer,
this attribute may contain a different value that the one
provided in the request.
An IPP Printer is able to extend its registration lease using
the Renew-Notification-Source-Registration operation. The
maximum value for a registration lease is one day.
4.5 Cancel-Notification-Source-Registration Operation
This REQUIRED operation allows an IPP Printer to terminate a current
registration to a Notification Delivery Service. This causes the Server
object to saves all current persistent Subscriptions into the location
specified for this purpose at registration time, if one was specified.
The Server object then cleans up any data and processes associated with
that registration. Notification Delivery Service implementations should
consider periodically saving away persistent Subscription objects to
reduce the risk of failing to save everything at deregistration time.
4.5.1 Cancel-Notification-Source-Registration Request
The following set of attributes is part of the Cancel-Notification-
Source-Registration 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.
Parra, Hastings [page 22]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
"server-uri":
The URI of the Notification Delivery Service.
"registration-id" (integer(0:MAX)):
The IPP Printer MUST specify this REQUIRED attribute using the
registration-id it obtained from the Server object via the
Register-Notification-Source operation.
4.5.2 Cancel-Notification-Source-Registration Response
The Server object returns the following set of attributes as part of the
Cancel-Notification-Source-Registration Response:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as defined in [rfc 2566] section 3.1.4.1.
"notify-events" (1setOf type2 keyword):
The Server object MUST return in this attribute the list of
events that the printer must discontinue as a result of ending
its registration to the Notification Delivery Service. This
feature may be useful to IPP Printers that implement some
delivery methods internally and others via a Notification
Delivery Service and those who may use more than one
Notification Delivery Service simultaneously.
4.6 Renew-Notification-Source-Registration Operation
This REQUIRED operation allows an IPP Printer to renew its lease on an
existing registration to a Notification Delivery Service. It MUST be
issued before the lease-time specified in the Register-Notification-
Source operation or the previous Renew-Notification-Source-Registration
operation expires.
4.6.1 Renew-Notification-Source-Registration Request
The following set of attributes is part of the Renew-Notification-
Source-Registration 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.
"server-uri":
Parra, Hastings [page 23]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
The URI of the Notification Delivery Service.
"registration-id" (integer(0:MAX)):
The IPP Printer MUST specify this REQUIRED attribute using the
registration-id it obtained from the Server object via the
Register-Notification-Source operation.
"registration-lease-time-requested" (integer(0:86,400)):
This REQUIRED attribute specifies the time in the future when
the IPP Printer would like the registration lease to expire.
4.6.2 Renew-Notification-Source-Registration Response
The Server object returns the following set of attributes as part of the
Renew-Notification-Source-Registration Response:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as defined in [rfc 2566] section 3.1.4.1.
"registration-lease-expiration-time" (integer(0:86,400)):
This REQUIRED attribute specifies the time in the future when
the registration lease will expire. If the Server object is
not able to grant the lease-time requested by the IPP Printer,
this attribute may contain a different value that the one
provided in the request.
4.7 Create-Subscription Operation
This REQUIRED operation allows an IPP Printer to cause a Subscription
object to be instantiated in a Server object to which it is currently
registered as a Notification Source. The Server object is responsible
for keeping track of all registrations until their corresponding IPP
Printer removes them via the Cancel-Subscription operation or until the
registration is terminated by the Printer or it expires. The Server
object uses Subscription object to know who and how to notify when it
receives Notifications specifying a registration-id.
4.7.1 Create-Subscription Request
The Request for this operation includes the union of all of the REQUIRED
attributes and any of the OPTIONAL attributes indicated in [ipp-ntfy]
for the Create-Job-Subscription and Create-Printer-Subscription
operations, with the following chages:
Parra, Hastings [page 24]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
a)The "printer-uri" operational attribute is replaced by "server-uir"
and MUST contain the URI of the Notification Delivery Service.
b)The request MUST include the operational attribute "registration-id"
(integer(0:MAX)) specifying the registration-id the IPP Printer
obtained from the Server object via the Register-Notification-Source
operation.
The rules that govern when each individual attribute MUST or MAY be
included in this operation precisely mirror those specified in [ipp-
ntfy] for the Create-Job-Subscription and Create-Printer-Subscription
operations, but obviously not simultaneously. If the request contains a
"job-id" the Server object enforces applies the validation rules defined
for the Create-Job-Subscription operation. If the "job-id" is not
present, the Server object enforces the validation rules defined for the
Create-Printer-Subscription operation.
4.7.2 Create-Subscription Response
The Response for this operation is defined to be identical to the
Response for the Create-Printer-Subscription operation as specified in
[ipp-ntfy] except for the following changes:
a)The Response MUST include the operational attribute "notify-events"
(1setOf type2 keyword) containing the list of events that the printer
must notify the Server object of to satisfy the creatioin of the new
Subscription object.
b)The "notify-server-up-time" operational attribute contains the up-
time of the Notification Delivery Service instead of the IPP Printer.
c)The Response does not include the "Unsupported Attribute" Group.
The Response that results from creating a job-related Subscription
object doesn't include the "notify-lease-expiration-time" and "notify-
server-up-time" attributes.
4.8 Validate-Subscription Operation
This REQUIRED operation allows an IPP Printer to request the Sever
object to validate the contents of what could become a Subscription
object without actually creating the object. It employs the same logic
used by the Create-Subscription operation to validate a request.
4.8.1 Validate-Subscription Request
The Request for this operation is identical to the Create-Subscription
operation Request.
Parra, Hastings [page 25]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
4.8.2 Validate-Subscription Response
The Server object returns the following set of attributes as part of the
Validate-Subscription Registration Response:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as defined in [rfc 2566] section 3.1.4.1.
4.9 Cancel-Subscription Operation
This REQUIRED operation allows an IPP Printer to cause the Server object
to cancel a Subscription object currently associated with a given
registration-id.
4.9.1 Cancel-Subscription Request
The following set of attributes is part of the Cancel-Subscription
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.
"server-uri":
The URI of the Notification Delivery Service.
"registration-id" (integer(0:MAX)):
The IPP Printer MUST specify this REQUIRED attribute using the
registration-id it obtained from the Server object via the
Register-Notification-Source operation.
"subscription-id" (integer(0:MAX)):
This REQUIRED attribute specifies the ID of the Subscription
object to be cancelled. The IPP Printer must provide here the
same "subscription-id" that it received back from the Create-
Subscription or Get-Subscriptions operations.
4.9.2 Cancel-Subscription Response
The Server object returns the following set of attributes as part of the
Cancel-Subscription Response:
Parra, Hastings [page 26]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as defined in [rfc 2566] section 3.1.4.1.
"notify-events" (1setOf type2 keyword):
The Server object MUST return in this attribute the list of
events that the printer must discontinue as a result of
canceling the Subscription object.
4.10 Renew-Subscription Operation
The REQUIRED Renew-Subscription operation permits an IPP Printer to
request the Server object to extend the lease on a Subscription object
instance. This operation is only valid for Subscription object that
don't specify a "job-id", or Per-Printer Subscription objects as they
are referred to in [ipp-ntfy].
4.10.1 Renew-Subscription Request
The following set of attributes is part of the Renew-Subscription
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.
"server-uri":
The URI of the Notification Delivery Service.
"registration-id" (integer(0:MAX)):
The IPP Printer MUST specify this REQUIRED attribute using the
registration-id it obtained from the Server object via the
Register-Notification-Source operation.
"subscription-id" (integer(0:MAX))
The IPP Printer MUST specify the ID of the Subscription object
whose lease is being extended.
"notify-lease-time-requested" (integer(0:MAX))
The IPP Printer MUST specify the time by which it wishes to
extend the Subscription object's lease.
Parra, Hastings [page 27]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
4.10.2 Renew-Subscription Response
The Server object returns the following set of attributes as part of the
Renew-Subscription Response:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as defined in [rfc 2566] section 3.1.4.1.
"subscription-lease-expiration-time" (integer(0:86,400)):
This REQUIRED attribute specifies the time in the future when
the Subscription's lease will expire. If the Server object is
not able to grant the lease-time requested by the IPP Printer,
this attribute may contain a different value that the one
provided in the request.
4.11 Get-Subscriptions Operation
This REQUIRED operation allows an IPP Printer to get a list of the
Subscription objects associated with a given registration ID.
4.11.1 Get-Subscriptions Request
The Request for this operation is defined to be identical to the Request
for the Get-Subscriptions operation as specified in [ipp-ntfy], except
for the following changes:
a)The "printer-uri" operational attribute is replaced by "server-uir"
(uri) and MUST contain the URI of the Notification Delivery Service.
b)The request MUST include the operational attribute "registration-id"
(integer(0:MAX)) specifying the registration-id the IPP Printer
obtained from the Server object via the Register-Notification-Source
operation.
4.11.2 Get Subscriptions Response
The Response for this operation is defined to be identical to the
Response for the Get-Subscriptions operation as specified in [ipp-ntfy].
5 Encoding of the Operation Layer
INDP uses the same operation layer encoding model and syntax as IPP
[ipp-pro] with the following extensions:
Parra, Hastings [page 28]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
5.1 New attribute tag
A new notification attributes tag is defined:
notification-attributes-tag = %x07 ; tag of 7
5.2 New status codes
ISSUE 02 - Should we move the status codes into the Notification Model
document in order to have the same status codes for any other delivery
method that might be defined?
The following status codes are defined:
5.2.1 unknown-notification-recipient. (0xXXX)
The Notification Recipient returns this status code in order to indicate
that the intended Ultimate Notification Recipient is not known to the
Notification Recipient.
5.2.2 unable-to-delivery-notification-report (0xXXX)
The Notification Recipient returns this status code in order to indicate
that it was unable to deliver the event Notification to the intended
Ultimate Notification Recipient.
5.2.3 successful-ok-but-cancel-subscription (0xXXXX)
The Notification Recipient indicates that it no longer wants to receive
Notifications for this Subscription object. Therefore, the Subscription
object is canceled. Note: this status code allows the Notification
Recipient to cancel a Subscription object without having to be the owner
of the Subscription object. Only the owner of the Subscription object
can cancel a Subscription object using the Cancel-Subscription
operation.
Parra, Hastings [page 29]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
5.2.4 unknown-registration-id (0xXXX)
5.2.5 successful-ok-but-error-accessing-persistent-storage (0xXXXX)
5.3 Encoding
The encoding of INDP is based strictly on the encoding used by IPP.
This specification, however, defines a new Group tag which is used it to
encode multiple notifications in a Request. As multiple instances of
the same group type have only been included in operation Responses in
the past, this section describes the encoding of an operation that uses
the new tag for illustration purposes.
The encoding for the Send-Notification Request consists of:
-----------------------------------
| version-number | 2 byte
-----------------------------------
| operation-id | 2 bytes
-----------------------------------
| request-id | 4 bytes
-----------------------------------
| operation-attributes-tag | 1 byte
-----------------------------------
| attributes-charset | u bytes
-----------------------------------
| attributes-natural-language | v bytes
-----------------------------------
| target-attribute | w bytes
----------------------------------------------
| notification-attributes-tag | 1 byte |
----------------------------------- | - 1 or more
| notification-attr-list | x bytes |
----------------------------------------------
| end-of-attributes-tag | 1 byte
-----------------------------------
Where:
version-number is made up of a major-version-number of %d1 and a minor-
version-number of %d0 indicating the 1.0 version of the INDP protocol.
operation-id, in the 1.0 version of the protocol, can be 0xXXXX _
0xXXXX.
Parra, Hastings [page 30]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
request-id is any 4 byte number provided by the notification source and
must be matched by the notification recipient in the corresponding
response to a request. It assists the notification source in associating
operation responses with their corresponding requests. Note that this
request id is independent of the request id embedded in the notification
report, which is opaque to the delivery method but assists the
notification recipient order and identity missing or duplicate
notification reports.
operation-attribute tag, natural-language-attribute, charset-attribute,
target-attribute, and end-of-attributes-tag have the same syntax and
semantics as in [ipp-pro].
notification-attr-list contains a list of the attributes that make up a
single notification (see section 2 above) encoded using the syntax
specified in [ipp-pro].
The encoding for the Send-Notification Response consists of:
-----------------------------------
| version-number | 2 byte
-----------------------------------
| status-code | 2 bytes
-----------------------------------
| request-id | 4 bytes
-----------------------------------
| operation-attributes-tag | 1 byte
-----------------------------------
| attributes-charset | u bytes
-----------------------------------
| attributes-natural-language | v bytes
-----------------------------------
| target-attribute | w bytes
----------------------------------------------
| notification-attributes-tag | 1 byte |
----------------------------------- | - 1 or more
| ntfy-status-code | 2 bytes |
----------------------------------------------
| end-of-attributes-tag | 1 byte
-----------------------------------
6 Encoding of Transport Layer
HTTP/1.1 [rfc2616] is the transport layer for this protocol.
The operation layer has been designed with the assumption that the
transport layer contains the following information:
Parra, Hastings [page 31]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
- the URI of the target INDP operation.
- the total length of the data in the operation layer, either as a
single length or as a sequence of chunks each with a length.
It is REQUIRED that a Notification Delivery Service and a 'indp://'
Notification Recipient implementation support HTTP over the IANA
assigned Well Known Port XXX (INDP's default port), though a
notification recipient implementation MAY support HTTP over some other
port as well.
Each HTTP operation MUST use the POST method where the request-URI is
the object target of the operation, and where the "Content-Type" of the
message-body in each request and response MUST be "application/ipp-
notify-send". The message-body MUST contain the operation layer and MUST
have the syntax described in section 3, "Encoding of Operation Layer".
An INDP client implementation (be it an IPP Printer or a Notification
Delivery Service) MUST adhere to the rules for a client described for
HTTP1.1 [rfc2616]. An INDP server implementation (be it a Notification
Delivery Method or a notification Recipient) MUST adhere the rules for
an origin server described for HTTP1.1 [rfc2616].
An INDP server implementation sends a response for each request that it
receives. If it detects an error, it MAY send a response before it has
read the entire request. If the HTTP layer of the INDP server
implementation completes processing the HTTP headers successfully, it
MAY send an intermediate response, such as "100 Continue", with no
notification data before sending the notification response. The INDP
client implementation MUST expect such a variety of responses. For
further information on HTTP/1.1, consult the HTTP documents [rfc2616].
An INDP server implementation MUST support chunking for HTTP
notification requests, and an INDP client implementation MUST support
chunking for HTTP notification responses according to HTTP/1.1[rfc2616].
Note: this rule causes a conflict with non-compliant implementations of
HTTP/1.1 that don't support chunking for POST methods, and this rule may
cause a conflict with non-compliant implementations of HTTP/1.1 that
don't support chunking for CGI scripts
INDP uses 'indp://' as its URI scheme.
7 IANA Considerations
IANA will be asked to register this 'ipp-notify-send' notification
delivery scheme and protocol and will be asked to assign a default port.
Parra, Hastings [page 32]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
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.
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.
Parra, Hastings [page 33]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
10 References
[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.
[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
Parra, Hastings [page 34]
Expires: Sep 9, 2000
INTERNET-DRAFT IPP: The IPP Notification Delivery Protocol Mar 9, 2000
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
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 35]
Expires: Sep 9, 2000
