draft-ietf-ipp-notify-get-02.txt   draft-ietf-ipp-notify-get-03.txt 
INTERNET-DRAFT Robert Herriot (editor) INTERNET-DRAFT Robert Herriot (editor)
<draft-ietf-ipp-notify-get-02.txt> Xerox Corp. <draft-ietf-ipp-notify-get-03.txt> Xerox Corp.
[Target category: standards track] Carl Kugler [Target category: standards track] Carl Kugler
IBM, Corp. IBM, Corp.
Harry Lewis Harry Lewis
IBM, Corp. IBM, Corp.
February 28, 2001 April 5, 2001
Internet Printing Protocol (IPP): Internet Printing Protocol (IPP):
The 'ippget' Delivery Method for Event Notifications The 'ippget' Delivery Method for Event Notifications
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Status of this Memo: Status of this Memo:
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [rfc2026]. Internet-Drafts are all provisions of Section 10 of [rfc2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
skipping to change at page 1, line 36 skipping to change at page 1, line 36
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The notification extension document [ipp-ntfy] defines operations This document describes an extension to the Internet Printing
that a client can perform in order to create Subscription Objects in Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910].
a Printer and carry out other operations on them. A Subscription This document specifies the 'ippget' Delivery Method for use with the
Object represents a Subscription abstraction. The Subscription Object IPP Event Notification Specification [ipp-ntfy].The 'ippget' Delivery
specifies that when one of the specified Events occurs, the Printer Method is a 'pull and push' Delivery Method. That is, when an Event
sends an asynchronous Event Notification to the specified occurs, the Printer saves the Event Notification for a period of time
Notification Recipient via the specified Delivery Method (i.e., called the Event Notification Lease Time. The Notification Recipient
protocol). fetches (pulls) Event Notifications using the Get-Notifications
operation. If the Notification Recipient has selected the option to
The notification extension document [ipp-ntfy] specifies that each wait for additional Event Notifications, the Printer continues to
Delivery Method is defined in another document. This document is one return (push) Event Notifications to the Notification Recipient as
such document, and it specifies the 'ippget' delivery method. Get-Notification responses as Events occur.
The 'ippget' Delivery Method is a 'pull and push' Delivery Method.
That is, the Printer saves Event Notification for a period of time
and expects the Notification Recipient to fetch the Event
Notifications (the pull part). The Printer continues to send Event
Notifications to the Notification Recipient as Events occur (the push
part) if the client has selected the option to wait for additional
Event Notifications.
When a Printer supports this Delivery Method, it holds each Event
Notification for an amount of time, called the Event Notification
Lease Time.
When a Notification Recipient wants to receive Event Notifications,
it performs an IPP operation called 'Get-Notifications', which this
document defines. This operation causes the Printer to return all
Event Notifications held for the Notification Recipient. If the
Notification Recipient has selected the option to wait for additional
Event Notifications, the Printer continues sending Event
Notifications to the Notification Recipient as additional Events
occur.
The basic 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 [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
Internet Printing Protocol/1.0 & 1.1: IPP Event Notification
Specification [ipp-ntfy]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that
are satisfied in IPP/1.0. A few OPTIONAL operator operations have
been added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol" document describes IPP from a high level
view, defines a roadmap for the various documents that form the suite
of IPP specification documents, and gives background and rationale
for the IETF working group's major decisions.
The "Internet Printing Protocol/1.1: Model and Semantics" document
describes a simplified model with abstract objects, their attributes,
and their operations that are independent of encoding and transport.
It introduces a Printer and a Job object. The Job object optionally
supports multiple documents per Job. It also addresses security,
internationalization, and directory issues.
The "Internet Printing Protocol/1.1: Encoding and Transport" document
is a formal mapping of the abstract operations and attributes defined
in the model document onto HTTP/1.1 [RFC2616]. It defines the
encoding rules for a new Internet MIME media type called
"application/ipp". This document also defines the rules for
transporting over HTTP a message body whose Content-Type is
"application/ipp". This document defines a new scheme named 'ippget'
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.
The "Event Notification Specification" document describes an
extension to the IPP/1.0, IPP/1.1, and future versions. This
extension allows a client to subscribe to printing related Events.
Subscriptions are modeled as Subscription Objects. The Subscription
Object specifies that when one of the specified Event occurs, the
Printer sends an asynchronous Event Notification to the specified
Notification Recipient via the specified Delivery Method (i.e.,
protocol). A client associates Subscription Objects with a
particular Job by performing the Create-Job-Subscriptions operation
or by submitting a Job with subscription information. A client
associates Subscription Objects with the Printer by performing a
Create-Printer-Subscriptions operation. Four other operations are
defined for Subscription Objects: Get-Subscriptions-Attributes, Get-
Subscriptions, Renew-Subscription, and Cancel-Subscription.
Table of Contents Table of Contents
1 Introduction....................................................6 1 Introduction....................................................4
2 Terminology.....................................................6 2 Terminology.....................................................4
3 Model and Operation.............................................7 3 Model and Operation.............................................5
4 General Information.............................................8 4 General Information.............................................6
5 Get-Notifications operation....................................10 5 Get-Notifications operation.....................................8
5.1 Get-Notifications Request...................................12 5.1 Get-Notifications Request...................................10
5.2 Get-Notifications Response..................................13 5.2 Get-Notifications Response..................................11
6 Subscription Template Attributes...............................18 6 Subscription Template Attributes...............................16
6.1 Subscription Template Attribute Conformance.................18 6.1 Subscription Template Attribute Conformance.................16
6.2 Additional Information about Subscription Template Attributes18 6.2 Additional Information about Subscription Template Attributes16
6.2.1 notify-recipient-uri (uri)................................18 6.2.1 notify-recipient-uri (uri)................................16
6.3 Subscription Description Attribute Conformance..............19 6.3 Subscription Description Attribute Conformance..............17
7 Additional Printer Description Attributes......................19 7 Additional Printer Description Attributes......................17
7.1 Printer Description Attribute Conformance...................19 7.1 Printer Description Attribute Conformance...................17
7.2 New Values for Existing Printer Description Attributes......19 7.2 New Values for Existing Printer Description Attributes......17
7.2.1 notify-schemes-supported (1setOf uriScheme)...............19 7.2.1 notify-schemes-supported (1setOf uriScheme)...............17
7.2.2 operations-supported (1setOf type2 enum)..................19 7.2.2 operations-supported (1setOf type2 enum)..................17
7.3 begin-to-expire-time-interval (integer(0:MAX))..............20 7.3 begin-to-expire-time-interval (integer(0:MAX))..............18
8 New Status Codes...............................................20 8 New Status Codes...............................................18
8.1 redirection-other-site (0x300)..............................21 8.1 redirection-other-site (0x300)..............................19
9 The IPPGET URL Scheme..........................................21 9 The IPPGET URL Scheme..........................................19
9.1 The IPPGET URL Scheme Applicability and Intended Usage......21 9.1 The IPPGET URL Scheme Applicability and Intended Usage......19
9.2 The IPPGET URL Scheme Associated Port.......................21 9.2 The IPPGET URL Scheme Associated Port.......................19
9.3 The IPPGET URL Scheme Associated MIME Type..................21 9.3 The IPPGET URL Scheme Associated MIME Type..................19
9.4 The IPPGET URL Scheme Character Encoding....................22 9.4 The IPPGET URL Scheme Character Encoding....................20
9.5 The IPPGET URL Scheme Syntax in ABNF........................22 9.5 The IPPGET URL Scheme Syntax in ABNF........................20
9.5.1 IPPGET URL Examples.......................................23 9.5.1 IPPGET URL Examples.......................................21
9.5.2 IPPGET URL Comparisons....................................23 9.5.2 IPPGET URL Comparisons....................................22
10 Encoding.......................................................24 10 Encoding.......................................................22
11 Conformance Requirements.......................................24 11 Conformance Requirements.......................................22
11.1 Conformance for IPP Printers................................24 11.1 Conformance for IPP Printers................................22
11.2 Conformance for IPP Clients.................................25 11.2 Conformance for IPP Clients.................................23
12 IANA Considerations............................................25 12 IANA Considerations............................................23
12.1 Operation Registrations.....................................26 12.1 Operation Registrations.....................................24
12.2 Additional values of existing attributes....................26 12.2 Additional values of existing attributes....................24
12.2.1 Additional values for the "notify-schemes-supported" Printer 12.2.1 Additional values for the "notify-schemes-supported" Printer
attribute..............................................26 attribute..............................................24
12.2.2 Additional values for the "operations-supported" Printer 12.2.2 Additional values for the "operations-supported" Printer
attribute..............................................26 attribute..............................................24
12.3 Attribute Registrations.....................................27 12.3 Attribute Registrations.....................................25
12.4 Status code Registrations...................................27 12.4 Status code Registrations...................................25
13 Internationalization Considerations............................27 13 Internationalization Considerations............................25
14 Security Considerations........................................27 14 Security Considerations........................................25
15 References.....................................................28 15 References.....................................................26
16 Authors' Addresses.............................................29 16 Authors' Addresses.............................................28
17 Full Copyright Statement.......................................30 17 Description of Base IPP documents..............................28
18 Full Copyright Statement.......................................30
Table of Tables Table of Tables
Table 1 - Information about the Delivery Method....................9 Table 1 - Information about the Delivery Method....................7
Table 2 - Attributes in Event Notification Content................16 Table 2 - Attributes in Event Notification Content................14
Table 3 - Additional Attributes in Event Notification Content for Job Table 3 - Additional Attributes in Event Notification Content for Job
Events ........................................................17 Events ........................................................15
Table 4 - Combinations of Events and Subscribed Events for "job- Table 4 - Combinations of Events and Subscribed Events for "job-
impressions-completed" ........................................17 impressions-completed" ........................................15
Table 5 - Additional Attributes in Event Notification Content for Table 5 - Additional Attributes in Event Notification Content for
Printer Events ................................................18 Printer Events ................................................16
Table 6 - Operation-id assignments................................20 Table 6 - Operation-id assignments................................18
Table 7 - The "event-notification-attributes-tag" value...........24 Table 7 - The "event-notification-attributes-tag" value...........22
1 Introduction 1 Introduction
The notification extension document [ipp-ntfy] defines operations The "IPP Event Notification Specification" document [ipp-ntfy]
that a client can perform in order to create Subscription Objects in defines an extension to Internet Printing Protocol/1.0 (IPP)
a Printer and carry out other operations on them. A Subscription [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. This extension
Object represents a Subscription abstraction. The Subscription Object defines operations that a client can perform in order to create
Subscription Objects in a Printer and carry out other operations on
them. A Subscription Object represents a Subscription abstraction.
A client associates Subscription Objects with a particular Job by
performing the Create-Job-Subscriptions operation or by submitting a
Job with subscription information. A client associates Subscription
Objects with the Printer by performing a Create-Printer-Subscriptions
operation. Four other operations are defined for Subscription
Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-
Subscription, and Cancel-Subscription. The Subscription Object
specifies that when one of the specified Events occurs, the Printer specifies that when one of the specified Events occurs, the Printer
sends an asynchronous Event Notification to the specified sends an asynchronous Event Notification to the specified
Notification Recipient via the specified Delivery Method (i.e., Notification Recipient via the specified Delivery Method (i.e.,
protocol). protocol).
The notification extension document [ipp-ntfy] specifies that each The "IPP Event Notification Specification" document [ipp-ntfy]
Delivery Method is defined in another document. This document is one specifies that each Delivery Method is defined in another document.
such document, and it specifies the 'ippget' delivery method. This document is one such document, and it specifies the 'ippget'
delivery method.
The 'ippget' Delivery Method is a 'pull and push' Delivery Method. The 'ippget' Delivery Method is a 'pull and push' Delivery Method.
That is, the Printer saves Event Notification for a period of time That is, when an Event occurs, the Printer saves the Event
and expects the Notification Recipient to fetch the Event Notification for a period of time called the Event Notification Lease
Notifications (the pull part). The Printer continues to send Event Time. The Notification Recipient fetches (pulls) the Event
Notifications to the Notification Recipient as Events occur (the push Notifications using the Get-Notifications operation. This operation
part) if the client has selected the option to wait for additional causes the Printer to return all Event Notifications held for the
Event Notifications. Notification Recipient. If the Notification Recipient has selected
the option to wait for additional Event Notifications, the Printer
When a Printer supports this Delivery Method, it holds each Event continues to return (push) Event Notifications to the Notification
Notification for an amount of time, called the Event Notification Recipient as Get-Notification responses as Events occur.
Lease Time.
When a Notification Recipient wants to receive Event Notifications,
it performs an IPP operation called 'Get-Notifications', which this
document defines. This operation causes the Printer to return all
Event Notifications held for the Notification Recipient. If the
Notification Recipient has selected the option to wait for additional
Event Notifications, the Printer the Printer continues to send Event
Notifications to the Notification Recipient as Events occur.
2 Terminology 2 Terminology
This section defines the following terms that are used throughout This section defines the following terms that are used throughout
this document: this document:
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
conformance to this specification. These terms are defined in conformance to this specification. These terms are defined in
[RFC2911 section 13.1 on conformance terminology, most of which is [RFC2911 section 13.1 on conformance terminology, most of which is
skipping to change at page 9, line 18 skipping to change at page 7, line 18
Requirement Requirement
1. What is the URL scheme name ippget 1. What is the URL scheme name ippget
for the Delivery Method? for the Delivery Method?
2. Is the Delivery Method RECOMMENDED 2. Is the Delivery Method RECOMMENDED
REQUIRED, RECOMMENDED or REQUIRED, RECOMMENDED or
OPTIONAL for an IPP Printer OPTIONAL for an IPP Printer
to support? to support?
3. What transport and delivery 3. What transport and delivery IPP with one new operation.
protocols does the Printer protocols does the Printer
use to deliver the Event use to deliver the Event
Notification Content, i.e., Notification Content, i.e.,
what is the entire network IPP with one new operation. what is the entire network
stack? stack?
4. Can several Event Yes. 4. Can several Event Yes.
Notifications be combined Notifications be combined
into a Compound Event into a Compound Event
Notification? Notification?
5. Is the Delivery Method This Delivery Method is a pull 5. Is the Delivery Method This Delivery Method is a pull
initiated by the Notification and a push. initiated by the Notification and a push.
Recipient (pull), or by the Recipient (pull), or by the
skipping to change at page 16, line 18 skipping to change at page 14, line 18
notify-subscription-id (integer(1:MAX)) MUST Subscription notify-subscription-id (integer(1:MAX)) MUST Subscription
notify-printer-uri (uri) MUST Subscription notify-printer-uri (uri) MUST Subscription
notify-subscribed-event (type2 keyword) MUST Event notify-subscribed-event (type2 keyword) MUST Event
Notification Notification
printer-up-time (integer(MIN:MAX)) MUST Printer printer-up-time (integer(MIN:MAX)) MUST Printer
printer-current-time (dateTime) * MUST * Printer printer-current-time (dateTime) MUST * Printer
notify-sequence-number (integer (0:MAX)) MUST Subscription notify-sequence-number (integer (0:MAX)) MUST Subscription
notify-charset (charset) MUST Subscription notify-charset (charset) MUST Subscription
notify-natural-language (naturalLanguage) MUST Subscription notify-natural-language (naturalLanguage) MUST Subscription
notify-user-data (octetString(63)) ** MUST Subscription notify-user-data (octetString(63)) MUST ** Subscription
notify-text (text) MUST Event notify-text (text) MUST Event
Notification Notification
attributes from the "notify-attributes" MUST Printer attributes from the "notify-attributes" MUST *** Printer
attribute *** attribute
attributes from the "notify-attributes" MUST Job attributes from the "notify-attributes" MUST *** Job
attribute *** attribute
attributes from the "notify-attributes" MUST Subscription attributes from the "notify-attributes" MUST *** Subscription
attribute *** attribute
* The Printer MUST send the "printer-current-time" attribute if * The Printer MUST send the "printer-current-time" attribute if
and only if it supports the "printer-current-time" attribute on and only if it supports the "printer-current-time" attribute on
the Printer object. the Printer object.
** If the associated Subscription Object does not contain a ** If the associated Subscription Object does not contain a
"notify-user-data" attribute, the Printer MUST send an octet- "notify-user-data" attribute, the Printer MUST send an octet-
string of length 0. string of length 0.
*** If the "notify-attributes" attribute is present on the *** If the "notify-attributes" attribute is present on the
skipping to change at page 17, line 22 skipping to change at page 15, line 22
Source Value Sends Source Source Value Sends Source
Object Object
job-id (integer(1:MAX)) MUST Job job-id (integer(1:MAX)) MUST Job
job-state (type1 enum) MUST Job job-state (type1 enum) MUST Job
job-state-reasons (1setOf type2 keyword) MUST Job job-state-reasons (1setOf type2 keyword) MUST Job
job-impressions-completed (integer(0:MAX)) * MUST Job job-impressions-completed (integer(0:MAX)) MUST * Job
* The Printer MUST send the "job-impressions-completed" * The Printer MUST send the "job-impressions-completed"
attribute in an Event Notification only for the combinations of attribute in an Event Notification only for the combinations of
Events and Subscribed Events shown in Table 4. Events and Subscribed Events shown in Table 4.
Table 4 - Combinations of Events and Subscribed Events for "job- Table 4 - Combinations of Events and Subscribed Events for "job-
impressions-completed" impressions-completed"
Job Event Subscribed Job Event Job Event Subscribed Job Event
skipping to change at page 18, line 48 skipping to change at page 17, line 4
attribute for other Delivery Method is defined in other Delivery attribute for other Delivery Method is defined in other Delivery
Method Documents. Method Documents.
In order to support the 'ippget' Delivery Method and Protocol, the In order to support the 'ippget' Delivery Method and Protocol, the
Printer MUST support the following syntax: Printer MUST support the following syntax:
The 'ippget://' URI scheme. The remainder of the URI indicates The 'ippget://' URI scheme. The remainder of the URI indicates
something unique about the Notification Recipient, such as its host something unique about the Notification Recipient, such as its host
name or host address (and optional path) that the Printer uses to name or host address (and optional path) that the Printer uses to
match the "notify-recipient-uri" Operation attribute supplied in match the "notify-recipient-uri" Operation attribute supplied in
the Get-Notifications request. the Get-Notifications request. See section 9 for a complete
definition of the syntax of the IPPGET URL.
6.3 Subscription Description Attribute Conformance 6.3 Subscription Description Attribute Conformance
The 'ippget' Delivery Method has the same conformance requirements The 'ippget' Delivery Method has the same conformance requirements
for Subscription Description attributes as defined in [ipp-ntfy]. for Subscription Description attributes as defined in [ipp-ntfy].
The 'ippget' Delivery Method does not define any addition The 'ippget' Delivery Method does not define any addition
Subscription Description attributes. Subscription Description attributes.
7 Additional Printer Description Attributes 7 Additional Printer Description Attributes
skipping to change at page 20, line 38 skipping to change at page 18, line 38
Subscription Object associated with this Delivery Method, AND Subscription Object associated with this Delivery Method, AND
2.an Event associated with the new Job occurs immediately after 2.an Event associated with the new Job occurs immediately after
the Subscription Object is created, AND the Subscription Object is created, AND
3.the same client or some other client performs a Get- 3.the same client or some other client performs a Get-
Notifications operation N seconds after the Job Creation Notifications operation N seconds after the Job Creation
operation. operation.
Then, if N is less than the value of this attribute, the client Then, if N is less than the value of this attribute, the client
performing the Get-Notifications operations can expect not miss any performing the Get-Notifications operations can expect not to miss
Event-Notifications, barring some unforeseen lack of memory space in any Event-Notifications, barring some unforeseen lack of memory space
the Printer. in the Printer.
8 New Status Codes 8 New Status Codes
The following status codes are defined as extensions for this The following status codes are defined as extensions for this
Delivery Method and are returned as the status code of the Get- Delivery Method and are returned as the status code of the Get-
Notifications operation. Notifications operation.
8.1 redirection-other-site (0x300) 8.1 redirection-other-site (0x300)
This status code means that the Printer doesn't perform that Get- This status code means that the Printer doesn't perform that Get-
skipping to change at page 22, line 10 skipping to change at page 20, line 10
[IANA-MIMEREG]. An 'ippget' URL MUST uniquely identify an IPP Client [IANA-MIMEREG]. An 'ippget' URL MUST uniquely identify an IPP Client
that support this 'application/ipp' MIME media type. that support this 'application/ipp' MIME media type.
See: IANA MIME Media Types Registry [IANA-MIMEREG]. See: IANA MIME Media Types Registry [IANA-MIMEREG].
9.4 The IPPGET URL Scheme Character Encoding 9.4 The IPPGET URL Scheme Character Encoding
The 'ippget' URL scheme defined in this document is based on the ABNF The 'ippget' URL scheme defined in this document is based on the ABNF
for the URI Generic Syntax [RFC2396] and further updated by [RFC2732] for the URI Generic Syntax [RFC2396] and further updated by [RFC2732]
and [RFC2373] (for IPv6 addresses in URLs). The 'ippget' URL scheme and [RFC2373] (for IPv6 addresses in URLs). The 'ippget' URL scheme
is case-insensitive in the host name or host address part; however, is case-insensitive in the scheme and 'authority' part; however, the
the path part is case-sensitive, as in [RFC2396]. Code points 'abs_path' part is case-sensitive, as in [RFC2396]. Code points
outside [US-ASCII] MUST be hex escaped by the mechanism specified in outside [US-ASCII] MUST be hex escaped by the mechanism specified in
[RFC2396]. [RFC2396].
9.5 The IPPGET URL Scheme Syntax in ABNF 9.5 The IPPGET URL Scheme Syntax in ABNF
This document is intended for use in registering the 'ippget' URL This document is intended for use in registering the 'ippget' URL
scheme with IANA and fully conforms to the requirements in [RFC2717]. scheme with IANA and fully conforms to the requirements in [RFC2717].
This document defines the 'ippget' URL (Uniform Resource Locator) This document defines the 'ippget' URL (Uniform Resource Locator)
scheme for specifying a unique identifier for an IPP Client which scheme for specifying a unique identifier for an IPP Client which
implements IPP 'Get-Notifications' operation specified in this implements IPP 'Get-Notifications' operation specified in this
skipping to change at page 23, line 27 skipping to change at page 21, line 27
The following are examples of valid 'ippget' URLs for IPP Clients The following are examples of valid 'ippget' URLs for IPP Clients
(using DNS host names): (using DNS host names):
ippget://abc.com ippget://abc.com
ippget://abc.com/listener ippget://abc.com/listener
ippget://bob@abc.com/listener/1232 ippget://bob@abc.com/listener/1232
Note: The use of IP addresses in URLs SHOULD be avoided whenever Note: The use of IP addresses in URLs SHOULD be avoided whenever
possible (see [RFC1900]). possible (see [RFC1900]).
The choice of 'userinfo@hostport' versus the simpler 'hostport' The IPP Client that creates the Subscription object and the
production in an 'ippget' URL may be influenced by the intended Notification Recipient have to agree on a unique IPPGET URL value in
usage. order for the Get-Notifications operations to retrieve the proper
Event Notifications. Therefore, the choice of 'userinfo@hostport'
versus the simpler 'hostport' production in an 'ippget' URL may be
influenced by the intended usage.
If a given IPP Client creates an IPP Subscription object for event If a given IPP Client creates an IPP Subscription object for event
notifications intended for retrieval by the same IPP Client, then the notifications intended for retrieval by the same IPP Client, then the
simple 'hostport' production may be most appropriate. simple 'hostport' production may be most appropriate. In this case,
the IPP Client and the Notification Recipient both know the
'hostport' of the client.
On the other hand, if a given IPP Client creates an IPP Subscription On the other hand, if a given IPP Client creates an IPP Subscription
object for event notifications intended for retrieval by a different object for event notifications intended for retrieval by a different
IPP Client, then the 'userinfo@hostport' production (using, for IPP Client, then the 'userinfo@hostport' production (using, for
example, the right-hand side of a 'mailto:' URL, see [RFC2368]) may example, the right-hand side of a 'mailto:' URL, see [RFC2368]) may
be most appropriate. be most appropriate. For this case, a mail address serves as the
prior agreement on the IPPGET URL value between the IPP Client and
the Notification Recipient.
9.5.2 IPPGET URL Comparisons 9.5.2 IPPGET URL Comparisons
When comparing two 'ippget' URLs to decide if they match or not, an When comparing two 'ippget' URLs to decide if they match or not,
IPP Client or IPP Printer SHOULD use a case-sensitive octet-by-octet an IPP Client or IPP Printer MUST use the same rules as those
comparison of the entire URLs, with these exceptions: defined for HTTP URI comparisons in [RFC2616].
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;
- An empty 'abs_path' is equivalent to an 'abs_path' of "/".
Characters other than those in the "reserved" and "unsafe" sets (see
[RFC2396] and [RFC2732]) are equivalent to their ""%" HEX HEX"
encoding.
For example, the following three URIs are equivalent:
ippget://abc.com/~smith/listener
ippget://ABC.com/%7Esmith/listener
ippget://ABC.com:/%7esmith/listener
10 Encoding 10 Encoding
This notification delivery method uses the IPP transport and encoding This notification delivery method uses the IPP transport and encoding
[RFC2910] for the Get-Notifications operation with one extension [RFC2910] for the Get-Notifications operation with one extension
allocated in [ipp-ntfy]: allocated in [ipp-ntfy]:
Table 7 - The "event-notification-attributes-tag" value Table 7 - The "event-notification-attributes-tag" value
Tag Value (Hex) Meaning Tag Value (Hex) Meaning
skipping to change at page 25, line 34 skipping to change at page 23, line 29
1.MUST create unambiguously unique 'ippget' URLs in all cases; 1.MUST create unambiguously unique 'ippget' URLs in all cases;
2.MUST send 'ippget' URLs (e.g., in the "notify-recipient-uri" 2.MUST send 'ippget' URLs (e.g., in the "notify-recipient-uri"
attribute in a Get-Notifications request) that conform to the attribute in a Get-Notifications request) that conform to the
ABNF specified in section 9.5 of this document; ABNF specified in section 9.5 of this document;
3.MUST send IPP Get-Notifications operation requests via the port 3.MUST send IPP Get-Notifications operation requests via the port
specified in the associated 'ipp' URL (if present) or otherwise specified in the associated 'ipp' URL (if present) or otherwise
via IANA assigned well-known port 631; via IANA assigned well-known port 631;
4.MUST convert the associated 'ipp' URLs to their corresponding 4.MUST convert the associated 'ipp' URLs for use in IPP Get-
'http' URL forms according to the rules in section 5 "IPP URL Notifications operation to their corresponding 'http' URL forms
Scheme" in [RFC2910]. for use in the HTTP layer according to the rules in section 5
"IPP URL Scheme" in [RFC2910].
Note: The use of ambiguous 'ippget' URLs is NOT an optional feature Note: The use of ambiguous 'ippget' URLs is NOT an optional feature
for IPP Clients; it is a non-conformant implementation error. for IPP Clients; it is a non-conformant implementation error.
12 IANA Considerations 12 IANA Considerations
IANA is requested to register the 'ippget' URL scheme as defined in IANA is requested to register the 'ippget' URL scheme as defined in
section 9 according to the procedures of [RFC2717]. section 9 according to the procedures of [RFC2717].
The rest of this section contains the exact information for The rest of this section contains the exact information for
skipping to change at page 29, line 4 skipping to change at page 26, line 49
P. Hoffman, L. Masinter, J. Zawinski. The "mailto" URL Scheme, RFC P. Hoffman, L. Masinter, J. Zawinski. The "mailto" URL Scheme, RFC
2368, July 1998. 2368, July 1998.
[RFC2373] [RFC2373]
R. Hinden, S. Deering. IP Version 6 Addressing Architecture, RFC R. Hinden, S. Deering. IP Version 6 Addressing Architecture, RFC
2373, July 1998. 2373, July 1998.
[RFC2396] [RFC2396]
Berners-Lee, T. et al. Uniform Resource Identifiers (URI): Generic Berners-Lee, T. et al. Uniform Resource Identifiers (URI): Generic
Syntax, RFC 2396, August 1998 Syntax, RFC 2396, August 1998
[RFC2565]
Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
1999.
[RFC2566]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, and P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April 1999.
[RFC2567]
Wright, D., "Design Goals for an Internet Printing Protocol", RFC
2567, April 1999.
[RFC2568]
Zilles, S., "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2569]
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2567] [RFC2567]
Wright, D., "Design Goals for an Internet Printing Protocol", RFC Wright, D., "Design Goals for an Internet Printing Protocol", RFC
2567, April 1999. 2567, April 1999.
[RFC2568] [RFC2568]
Zilles, S., "Rationale for the Structure and Model and Protocol for Zilles, S., "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", RFC 2568, April 1999. the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2569] [RFC2569]
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
skipping to change at page 30, line 20 skipping to change at page 28, line 34
Harry Lewis Harry Lewis
IBM IBM
P.O. Box 1900 P.O. Box 1900
Boulder, CO 80301-9191 Boulder, CO 80301-9191
Phone: 303-924-5337 Phone: 303-924-5337
FAX: FAX:
e-mail: harryl@us.ibm.com e-mail: harryl@us.ibm.com
17 Full Copyright Statement 17 Description of Base IPP documents
The base 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 [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
Internet Printing Protocol (IPP): IPP Event Notification
Specification [ipp-ntfy]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that
are satisfied in IPP/1.0. A few OPTIONAL operator operations have
been added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol" document describes IPP from a high level
view, defines a roadmap for the various documents that form the suite
of IPP specification documents, and gives background and rationale
for the IETF working group's major decisions.
The "Internet Printing Protocol/1.1: Model and Semantics" document
describes a simplified model with abstract objects, their attributes,
and their operations that are independent of encoding and transport.
It introduces a Printer and a Job object. The Job object optionally
supports multiple documents per Job. It also addresses security,
internationalization, and directory issues.
The "Internet Printing Protocol/1.1: Encoding and Transport" document
is a formal mapping of the abstract operations and attributes defined
in the model document onto HTTP/1.1 [RFC2616]. It defines the
encoding rules for a new Internet MIME media type called
"application/ipp". This document also defines the rules for
transporting over HTTP a message body whose Content-Type is
"application/ipp". This document defines the 'ippget' scheme 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.
The "IPP Event Notification Specification" document defines an
extension to IPP/1.0 [RFC2566, RFC2565] and IPP/1.1 [RFC2911,
RFC2910]. This extension allows a client to subscribe to printing
related Events and defines the semantics for delivering asynchronous
Event Notifications to the specified Notification Recipient via a
specified Delivery Method (i.e., protocols) defined in (separate)
Delivery Method documents.
18 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/