INTERNET-DRAFT Hugo Parra Novell, Inc. Tom Hastings Xerox Corp. March 9, 2000 Internet Printing Protocol (IPP): The INDP Notification Delivery Method Copyright (C) The Internet Society (2000). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [rfc2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed as http://www.ietf.org/shadow.html. Abstract The IPP event notification specification [ipp-ntfy] is an OPTIONAL extension to IPP/1.0, IPP/1.1, and future versions. [ipp-ntfy] requires the definition of one or more delivery methods for dispatching Notifications to Notification Recipients. This document describes the semantics and syntax of the INDP Notification Delivery Method that is itself a request/response protocol. For this delivery method, an IPP Printer sends (pushes) IPP event Notifications to the Notification Recipients using the IPP Notification Delivery Protocol (INDP) defined in [indp]. The Notification Recipient can either be the Ultimate Recipient of the Notification or can be a Notification Service that forwards the Notification to the Ultimate Recipient. Parra, Hastings [page 1] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 The full set of IPP documents includes: Design Goals for an Internet Printing Protocol [RFC2567] Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568] Internet Printing Protocol/1.1: Model and Semantics (this document) Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569] The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1. The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions. The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting a message body over HTTP whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs. The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included. The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations. Parra, Hastings [page 2] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 Table of Contents 1 Introduction ......................................................4 2 Terminology .......................................................4 3 Model and Operation ...............................................4 4 Notification Operations ...........................................5 4.1 SEND-NOTIFICATIONS OPERATION.....................................6 4.1.1 Send-Notifications Request ..................................6 4.1.2 Send-Notifications Response .................................7 4.2 NOTIFICATION PROTOCOL URI SCHEME.................................8 5 Encoding of the Operation Layer ...................................9 6 Encoding of Transport Layer .......................................9 7 IANA Considerations ...............................................9 8 Internationalization Considerations ...............................9 9 Security Considerations ...........................................9 9.1 SECURITY CONFORMANCE............................................10 10 References .......................................................10 11 Author's Addresses ...............................................11 12 Full Copyright Statement .........................................11 Parra, Hastings [page 3] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 1 Introduction An IPP Printer that supports the OPTIONAL IPP event notification extension [ipp-ntfy] is called a Notification Source which sends event Notifications to Notification Recipients. As such, a Printer either a) accepts, stores, and uses notification Subscription objects to generate event Notification and implements one or more delivery methods for notifying interested parties, or b) supports a subset of these tasks and farms out the remaining tasks to a Notification Delivery Service. The INDP Notification Delivery Method specified in this document employs a request/response protocol, which is a subset of the IPP Notification Delivery Protocol (INDP), defined in [indp]. A Notification Source may implement the INDP Notification Delivery Method to send (push) event notifications to Notification Recipients using the INDP Send- Notifications operation (see section 4.1) over HTTP. 2 Terminology This document uses terms such as "attributes", "keywords", and "support". These terms have special meaning and are defined in the model terminology [ipp-mod] section 12.2. Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance. These terms are defined in [ipp-mod] section 12.1 on conformance terminology, most of which is taken from RFC 2119 [RFC2119]. This section defines the following additional terms that are used throughout this document: REQUIRED: if an implementation supports the extensions described in this document, it MUST support a REQUIRED feature. OPTIONAL: if an implementation supports the extensions described in this document, it MAY support an OPTIONAL feature. Event Notification (Notification for short) - See [ip-ntfy] Notification Source - See [ipp-ntfy] Notification Recipient - See [ipp-ntfy] Subscription object - See [ipp-ntfy] Ultimate Notification Recipient - See [ipp-ntfy] 3 Model and Operation In the IPP Notification Model [ipp-ntfy], a client is able to: Parra, Hastings [page 4] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 1.supply one or more Per-Job Subscriptions in the Job Creation operation 2.OPTIONALLY supply Per-Job Subscriptions as subsequent Create-Job- Subscription operations 3.Supply one Per-Printer Subscription in the Create-Printer- Subscription operation. The client that creates these Subscription objects becomes the owner of the Subscription object. When creating each Subscription object, the client supplies the "notify- recipient" (uri) attribute. The "notify-recipient" attribute specifies both a single Notification Recipient that is to receive the Notifications when subsequent events occur and the method for notification delivery that the IPP Printer is to use. For the Notification delivery method defined in this document, the notification method is 'indp' and the rest of the URI is the address of the Notification Recipient to which the IPP Printer will send the INDP Send- Notifications operation. The INDP Notification Delivery Method defined in this document also uses a client/server protocol paradigm. The "client" in this HTTP relationship is the Notification Source described in [ipp-ntfy] while the "server" is the Notification Recipient. The Notification Source invokes the Send-Notifications operation supported in INDP to communicate IPP event Notification contents to the Notification Recipient. The Notification Recipient only conveys information to the Notification Source in the form of responses to the operations initiated by the Notification Source. Notification Sources that implement the INDP Notification Delivery Method will need to include an INDP client stack (and hence an HTTP client stack) while notification recipients that implement this delivery method will need to support an INDP server stack (and hence an HTTP server stack). See section 6 for more details. 4 Notification Operations The Notification Source composes the information defined for an IPP Notification [ipp-ntfy] and sends it using the Sent-Notifications operation to the Notification Recipient supplied in the Subscription object. Parra, Hastings [page 5] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 INDP makes extensive use of the operations model defined by IPP [rfc2566]. This includes, the use of a URI as the identifier for the target of each operation, the inclusion of a version number, operation- id, and request-id in each request, and the definition of attribute groups. The Send-Notifications operation uses the Operation Attributes group, but currently has no need for the Unsupported Attributes, Printer Object Attributes, and Job-Object Attributes groups. However, it uses a new attribute group, the Notification Attributes group (see [indp]). 4.1 Send-Notifications Operation This REQUIRED operation allows a Notification Source to send one or more Notifications to a Notification Recipient using HTTP. The operation has been tailored to accommodate the current definition of IPP Notification [ipp-ntfy]. Both Machine-Consumable and Human-Consumable notifications may be sent to a Notification Recipient through this operation. 4.1.1 Send-Notifications Request Every operation request contains the following REQUIRED parameters (see [ipp-mod] section 3.1.1): - a "version-number" - an "operation-id" - a "request-id" The following groups of attributes are part of the Send-Notifications Request: Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes ads defined in [rfc 2566] section 3.1.4.1. Target: The "notification-recipient-uri" (uri) operation attribute which is the target of this operation as described in [ipp- mod] section 3.1.5, i.e., the URI of the 'indp' Notification Recipient. Group 2 to N: Notification Attributes "human-readable-report" (text) The 'indp' Notification Source OPTIONALLY supports this attribute. This attribute is a text string generated by the IPP printer or Notification Delivery Service from the contents of the IPP Parra, Hastings [page 6] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 Notification suitable for human consumption. If the Notification Source supports this attribute, it MUST supply this attribute if the Subscription object contains the "notify-text-format" (mimeMediaType) attribute. The text value of this attribute MUST be localized in the charset identified by the "notify-charset" (charset) attribute and the natural language identified by the notify-natural-language" (naturalLanguage) attribute supplied in the associated Subscription object that generates this event Notification. The format of the text value is specified by the value of the "notify-text-format" (mimeMediaType) supplied in the associated Subscription object. "human-readable-report-format" (mime) This attribute MUST be supplied by the Notification Source whenever the "human-readable-report" attribute is present. It indicates the format, e.g., text/plain, text/html, etc. of the "human-readable- report" attribute. All of the REQUIRED attributes and any of the OPTIONAL attributes indicated in [ipp-ntfy] for a Push event Notification, including "notify-text-format-type" (mimeMediaType), if the "human-readable- report" (text) attribute is included, so that the Notification Recipient will know the text format of the "human-readable-report" (text) attribute value. These attributes communicate the same information as the notification attributes by the same name described in sections 7.4, 7.5, and 7.6 of [ipp-ntfy]. The rules that govern when each individual attribute MUST or MAY be included in this operation precisely mirror those specified in [ipp-ntfy]. 4.1.2 Send-Notifications Response The 'indp' Notification Recipient returns a status code for the entire operation and one for each Notification Report in the request if the operation's status code is other than "successful-ok". If the 'indp' Notification Recipient receives a Notification report that it can't pair up with a Subscription it knows about, it can return a 'client-error- unknown-subscription' error status-code to indicate that events associated with that subscription should no longer be sent to it. Alternatively, the Notification Recipient can return the 'successful-ok- but-cancel-subscription' to the Notification Source and cancel a Subscription that is no longer wanted. Every operation response contains the following REQUIRED parameters (see [ipp-mod] section 3.1.1}: - a "version-number" - a "status-code" Parra, Hastings [page 7] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 - the "request-id" that was supplied in the corresponding request Group 1: Operation Attributes Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes ads defined in [rfc 2566] section 3.1.4.1. ISSUE 01 _ Should there be an Unsupported Attributes group to return attributes that are not supported to the client? Group 2 to N: Notification Attributes "notification-report-status-code" (type2 enum) Indicates whether the 'ipp-notify-send' Notification Recipient was able to consume the n-th Notification Report. The following standard enum values are defined: 'successful-ok' 'successful-ok-but-cancel-subscription' 'client-error-unknown-subscription' 'client-error-bad-request' ISSUE 02 _ Should this use the same status code space as IP, namely: "successful" _ 0x0000 to 0x00FF "informational" _ 0x0100 to 0x01FF "redirection" _ 0x0400 to 0x04FF "server-error" _ 0x0500 to 0x05FF ISSUE 03 _ What status code from IPP can we re-use? ISSUE 04 _ Where should the status code be defined? Here, in [indp], in [ipp-ntfy], or in [ipp-mod]? ISSUE 05 _ Since there is an overall status code for the entire operation and one fore each Notification, what status code is returned for the overall operation, if one Notification succeeds and another fails? Do we need a status code for this such as 'client-error-some- notifications-failed'? 4.2 Notification Protocol URI Scheme The INDP Notification Delivery Method uses the 'indp://' URI scheme in the "notify-recipients" attribute in the Subscription object in order to indicate the notification delivery method defined in this document. The remainder of the URI indicates the host and address of the Notification Recipient that is to receive the Send-Notification operation. Parra, Hastings [page 8] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 5 Encoding of the Operation Layer The INDP Notification Delivery Method uses the INDP operation layer encoding described in [indp]. 6 Encoding of Transport Layer The INDP Notification Delivery Method uses the INDP transport layer encoding described in [indp]. It is REQUIRED that an 'indp' Notification Recipient implementation support HTTP over the IANA assigned Well Known Port XXX (the INDP default port), though a notification recipient implementation MAY support HTTP over some other port as well. 7 IANA Considerations The 'indp://' URL scheme and the IDNP default fort will be registered with IANA. 8 Internationalization Considerations When the client requests Human Consumable form by supplying the "notify- text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or any Notification Service that the IPP Printer might be configured to use) supplies and localizes the text value of the "human-readable- report" attribute in the Notification according to the charset and natural language requested in the notification subscription. 9 Security Considerations The IPP Model and Semantics document [ipp-mod] discusses high level security requirements (Client Authentication, Server Authentication and Operation Privacy). Client Authentication is the mechanism by which the client proves its identity to the server in a secure manner. Server Authentication is the mechanism by which the server proves its identity to the client in a secure manner. Operation Privacy is defined as a mechanism for protecting operations from eavesdropping. The Notification Recipient can cancel unwanted Subscriptions created by other parties without having to be the owner of the subscription by returning the 'successful-ok-but-cancel-subscription' status code in the Send-Notifications response returned to the Notification Source. Parra, Hastings [page 9] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 9.1 Security Conformance Notification Sources (client) MAY support Digest Authentication [rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess MUST be supported, but the Message Integrity feature NEED NOT be supported. Notification Recipient (server) MAY support Digest Authentication [rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess MUST be supported, but the Message Integrity feature NEED NOT be supported. Notification Recipients MAY support TLS for client authentication, server authentication and operation privacy. If a notification recipient supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites are OPTIONAL. Notification recipients MAY support Basic Authentication (described in HTTP/1.1 [rfc2616]) for client authentication if the channel is secure. TLS with the above mandated cipher suite can provide such a secure channel. 10 References [indp] Parra, H., T. Hastings, "Internet Printing Protocol (IPP): IPP Notification Delivery Protocol (INDP)", , February 29, 2000. [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", , 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", , February 2, 2000. [ipp-pro] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 05.txt, March 1, 2000. [rfc2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. Parra, Hastings [page 10] Expires: Sep 9, 2000 INTERNET-DRAFT IPP: The INDP Notification Delivery Method Mar 9, 2000 [rfc2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999. [rfc2617] J.