INTERNET-DRAFT 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 ----------------------------------- > ----------------------------------- | | 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", , 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", , 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