INTERNET-DRAFT
<draft-ietf-ipp-not-http-delivery-00.txt>
Hugo Parra
Novell, Inc.
October 19, 1999
Internet Printing Protocol/1.1: HTTP-Based IPP Notification Delivery
Protocol
Copyright (C) The Internet Society (1999). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html.
Abstract
The IPP notification specification [ipp-ntfy] requires the availability
of one or more delivery methods for dispatching notification reports to
interested parties. This document describes the semantics and syntax of
a protocol that a delivery method may use to deliver IPP notifications
using HTTP for a transport.
Parra [page 1]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
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 over HTTP a message
body whose Content-Type is "application/ipp". This document defines a
new scheme named 'ipp' for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
insight and advice to implementers of IPP clients and IPP objects. It
is intended to help them understand IPP/1.1 and some of the
considerations that may assist them in the design of their client and/or
IPP object implementations. For example, a typical order of processing
requests is given, including error checking. Motivation for some of the
specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
Parra [page 2]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
Table of Contents
1 Introduction......................................................4
2 Model and Operation...............................................4
2.1HTTP NOTIFICATION OPERATIONS.....................................4
2.1.1 Report-Ipp-Notifications....................................5
2.2HTTP NOTIFICATION PROTOCOL URI SCHEME............................7
3 Encoding of the Operation Layer...................................7
4 Encoding of Transport Layer.......................................9
5 IANA Considerations..............................................10
6 Internationalization Considerations..............................10
7 Security Considerations..........................................10
7.1SECURITY CONFORMANCE............................................10
8 References.......................................................11
9 Author's Addresses...............................................11
10 Full Copyright Statement.........................................11
Parra [page 3]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
1 Introduction
IPP printers that support IPP notification either a) accept, store, and
use notification subscriptions to generate notification reports and
implement one or more delivery methods for notifying interested parties,
or b) support a subset of these tasks and farm out the remaining tasks
to a Notification Delivery Service. The protocol specified in this
document may be used in a variety of notification scenarios. Its primary
intended use is for IPP printers to send notifications to notification
recipients over HTTP. However, it may also be used by IPP printers to
send notification to Notification Services and by Notification Delivery
Services to send notifications to notification recipients.
2 Model and Operation
The HTTP-Based IPP Notification Protocol, hereafter referred to as HTTP
notification protocol, is a client/server protocol. The "client" in this
HTTP relationship is the notification source described in [ipp-ntfy]
while the "server" is the notification recipient. The notification
source invokes operations supported by the HTTP notification protocol to
communicate IPP Notification contents to the notification recipient. The
notification recipient only conveys information to the notification
source in the form of responses to the operations initiated by the
notification source.
HTTP notification requests will be issued as HTTP POST operations and
their corresponding HTTP notification responses will be returned in the
responses to those HTTP POST operations. Hence, notification sources
that implement the HTTP notification protocol will need to include an
HTTP client stack while notification recipients that implement this
protocol will need to support an HTTP server stack (see section 4 for
more details).
1.12.1 HTTP Notification Operations
The job of an HTTP notification source is to use the contents of an IPP
Notification as defined in [ipp-ntfy] to compose and invoke the
appropriate HTTP notification operation and send it to the specified
HTTP notification recipient.
The HTTP notification protocol makes extensive use of the operations
model defined by IPP [rfc2566]. This includes, the use of a URI as the
identifier for the target of each operation, the inclusion of a version
number, operation-id, and request-id in each request, and the definition
of attribute groups. The HTTP notification protocol uses the Operation
Attributes group, but currently has no need for the Unsupported
Parra [page 4]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
Attributes, Printer Object Attributes, and Job-Object Attributes groups.
However, it defines a new attribute group, the Notification Attributes
group.
In its 1.0 version, the HTTP notification protocol is composed of a
single operation, but may be extended in the future as needed (e.g., to
find out specific capabilities of an HTTP notification listener). The
operation currently defined is Send-Notifications.
1.1.12.1.1Report-Ipp-Notifications
This REQUIRED operation allows a notification source to send one or more
notifications to notification recipient using HTTP. The operation has
been tailored to accommodate the current definition of IPP Notification.
Both 'machine-consumable' and 'human-consumable' notifications may be
sent to an HTTP notification recipient through this operation.
1.1.1.12.1.1.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 ads defined in [rfc 2566] section 3.1.4.1.
Target:
The URI of the HTTP notification recipient.
Group 2 to N: Notification Attributes
"human-readable-report" (text)
The HTTP notification source OPTIONALLY supplies this attribute. A
text string generated by the IPP printer or Notification Delivery
Service from the contents of the IPP Notification suitable for
human consumption.
ISSUE 1 - Ok to extend Notification Model to allow a single
notification to have both Human Consumable form and Machine
Consumable form when the client asks for Human Consumable form by
supplying the "notify-text-format" attribute.
Parra [page 5]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
"version-number" (integer (0:32767))
"status-code" (integer (0:32767))
"request-id" (integer (0:MAX))
"attributes-charset" (charset)
"attributes-natural-language" (naturalLanguage)
"printer-uri" (uri)
"printer-name" (name(127))
"job-id" (integer(1:MAX))
"job-name" (name(MAX))
"trigger-event" (type2 keyword)
"trigger-time" (integer(MIN:MAX))
"trigger-date-time" (dateTime)
"subscription-id" (integer(1:MAX))
"subscriber-user-name" (name(MAX))
"subscriber-user-data" (octetString(63))
"job-state" (type1 enum)
"job-state-reasons" (1setOf type2 keyword)
"job-k-octets-processed" (integer(0:MAX))
"job-impressions-completed" (integer(0:MAX))
"job-media-sheets-completed" (integer(0:MAX))
"job-collation-type" (type2 enum)
"sheet-completed-copy-number" (integer(-2:MAX))
"sheet-completed-document-number" (integer(-2:MAX))
"impressions-interpreted" (integer(-2:MAX))
"impressions-completed-current-copy" (integer(-2:MAX))
"printer-state" (type1 enum)
"printer-state-reasons" (1setOf type2 keyword)
"printer-is-accepting-jobs" (boolean)
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].
1.1.1.22.1.1.2 Send-Notifications Response
The HTTP 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 HTTP
notification listener 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
Parra [page 6]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
"notification-report-status-code" (type2 enum)
Indicates whether the HTTP notification listener was able to consume
the n-th Notification Report.
1.22.2 HTTP Notification Protocol URI Scheme
ISSUE 2 - Should the URI scheme for this protocol be "http://",
"ipp://", or something else like "ipp-ntfy://". If we intent this
proposal to go to the IESG, something along the lines of the third
option might be our only alternative
3 Encoding of the Operation Layer
The HTTP notification protocol uses the same operation layer encoding
model and syntax as IPP [ipp-pro] with two extensions:
a) A new attribute tag is defined:
notification-report-tag = %x07 ; tag of 7
b) The following status codes are defined
0xYYYY - unknown-notification-recipient.
0xZZZZ - unable-to-delivery-notification-report
ISSUE 3 - Should we add a success status code, say,
'successful-ok-but-cancel-subscription' which requests that
the subscription be canceled. Then the Notification Recipient
can cancel a subscription that another party established even
though the Notification Recipient is not the owner of the
Subscription.
The encoding for the Report-IPP-Notification Request consists of:
-----------------------------------
| version-number | 2 byte
-----------------------------------
| operation-id | 2 bytes
-----------------------------------
| request-id | 4 bytes
-----------------------------------
| operation-attributes-tag | 1 byte
-----------------------------------
| natural-language-attribute | u bytes
-----------------------------------
| charset-attribute | v bytes
-----------------------------------
| target-attribute | w bytes
----------------------------------------------
| notification-tag | 1 byte |
Parra [page 7]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
----------------------------------- | - 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 HTTP
notification protocol.
operation-id, in the 1.0 version of the protocol, can only be 0x00003,
Report-IPP-Notification.
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 |
----------------------------------- |
| natural-language-attribute | u bytes | Not needed in 1.0
----------------------------------- > <ISSUE 4: Do we
| charset-attribute | v bytes | want to keep it?>
----------------------------------- |
| target-attribute | w bytes |
---------------------------------------------- /
| notification-tag | 1 byte |
----------------------------------- | - 1 or more
Parra [page 8]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
| ntfy-status-code | 2 bytes |
----------------------------------------------
| end-of-attributes-tag | 1 byte
-----------------------------------
4 Encoding of Transport Layer
HTTP/1.1 [rfc2068] is the transport layer for this protocol.
The operation layer has been designed with the assumption that the
transport layer contains the following information:
- the URI of the target job or printer 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 an HTTP notification recipient implementation
support HTTP over the IANA assigned Well Known Port XXX (the HTTP
notification protocol 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-
ntfy". The message-body MUST contain the operation layer and MUST have
the syntax described in section 3, "Encoding of Operation Layer". An
HTTP notification source implementation MUST adhere to the rules for a
client described for HTTP1.1 [rfc2068]. An HTTP notification recipient
implementation MUST adhere the rules for an origin server described for
HTTP1.1 [rfc2068].
An HTTP notification source sends a response for each request that it
receives. If a notification recipient detects an error, it MAY send a
response before it has read the entire request. If the HTTP layer of the
notification recipient 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. HTTP notification sources MUST expect such a variety of
responses from notification recipients. For further information on
HTTP/1.1, consult the HTTP documents [rfc2068].
An HTTP server MUST support chunking for HTTP notification requests, and
an HTTP notification source MUST support chunking for HTTP notification
responses according to HTTP/1.1[rfc2068]. 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
Parra [page 9]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
5 IANA Considerations
IANA will be asked to register this HTTP notification delivery scheme
and assign a default port.
6 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) 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.
7 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.
If we add the 'successful-ok-but-cancel-subscription' (see ISSUE 3 in
section 3), then the Notification Recipient can cancel unwanted
Subscriptions created by other parties without having to be the owner of
the subscription.
1.17.1 Security Conformance
Notification sources MAY support:
- Digest Authentication [rfc2069].
- MD5 and MD5-sess MUST be implemented and supported.
- The Message Integrity feature NEED NOT be used.
Notification Recipient MAY support:
- Digest Authentication [rfc2069].
- MD5 and MD5-sess MUST be implemented and supported.
- The Message Integrity feature NEED NOT be used.
Notification recipients MAY support TLS for client authentication,
server authentication and operation privacy. If a notification recipient
Parra [page 10]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
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 [rfc2068]) for client authentication if the
channel is secure. TLS with the above mandated cipher suite can provide
such a secure channel.
8 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-04.txt>, June, 1999.
[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-01.txt>,
October 14, 1999.
[ipp-pro]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
03.txt, June, 1999.
[rfc2068]
R. Fielding, et al, "Hypertext Transfer Protocol . HTTP/1.1" RFC
2068, January 1997.
[rfc2566]
deBry, R., Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April 1999.
9 Author's Addresses
Hugo Parra
Novell, Inc.
122 E 1700 S
Provo, UT 84606
Phone: 801-861-3307
Fax: 801-861-2517
e-mail: hparra@novell.com
10 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
Parra [page 11]
Expires: April 19, 2000
INTERNET-DRAFTIPP/1.1: HTTP Notification Delivery SchemeOctober 19, 1999
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 [page 12]
Expires: April 19, 2000
