INTERNET-DRAFT Y. Y. Goland Expires: April 1998 Microsoft Corporation Standards Track November 20, 1997 TIP Working Group Using the Transaction Internet Protocol (TIP) with HTTP draft-ietf-tip-usehttp-00.txt Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This specification defines how to use TIP transaction identifiers to transaction arbitrary HTTP communications. 1. Introduction This specification defines how to use [TIP] transaction identifiers to transaction arbitrary HTTP communications. Transaction Ids are introduced into HTTP through the use of the Transaction request header. The Transaction request header is used to specify that a method is to be made part of the identified transaction. The Transaction response header indicates the resource's support of the Transaction request header along with, optionally, endpoints for the resource's Transaction Manager (TM). 2. Terminology The terms "endpoint", "PUSH", "PULL", Transaction Id", and "Transaction Manager (TM)" are used as defined in [TIP]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Bradner]. Y. Y. Goland [Page 1] INTERNET-DRAFT Using TIP with HTTP November 20, 1997 3. Transaction Request Header To transact an HTTP request the client includes in the request the transaction ID associated with the desired TIP transaction. The client obtains the transaction ID from its TM. It is the client's TM that implements a TIP transport; such as the TCP/IP transport defined in [TIP]. This specification assumes the existence of the client's TM and the client's ability to communicate with its TM through an unspecified means such as inter-process communication, functional calls, etc. The transaction ID is included with a request using the Transaction request header. Transaction = "Transaction" ":" 1*("<" URI ">") ; Please refer to section 3.2.1 of [RFC2068] for the definition of URI Transaction Ids, as defined by [TIP], are URIs. As TIP supports multiple transports it is possible to have multiple transaction Ids, one for each supported transport, identify the same transaction. Hence the Transaction request header allows for multiple Ids to be listed; these Ids MUST all refer to the same transaction. A resource MUST NOT accept a method with a transaction request header if the resource's TM is not a member of the specified transaction. If the resource's TM is not already a member of the specified transaction then it MUST join the transaction. It can do so, for example, by contacting the TM handling the transaction, identified by the transaction Id(s), and PULLing the transaction. 4. Transaction Response Header A client can discover if a resource supports the Transaction request header by executing the OPTIONS method on the resource. If the resource supports the use of the transaction request header then it MUST return a Transaction response header with an OPTIONS response. Transaction = "Transaction" ":" *("<" URI ">") The Transaction response header provides a list of endpoints for the resource's TM(s). Not all resource's TMs have endpoints. As such the transaction header MAY return with no values. Note that this is different from the behavior of the Transaction request header, which MUST always contain at least one value. Y. Y. Goland [Page 2] INTERNET-DRAFT Using TIP with HTTP November 20, 1997 Additionally a resource MAY return a Transaction response header in an error response in order to indicate supported endpoints. This is useful when the resource's TM may not be able to PULL the desired transaction but the client's TM could PUSH the transaction to the resource's TM, thus allowing the transaction request to succeed in the future. If the Transaction response header is empty then the client must determine how to communicate with the resource's TM through another means. For example, the resource's TM may have contacted the client's TM and PUSHed a transaction to it. The client's TM then contacted the client and provided it with the transaction Id. Since the resource's TM originated the transaction, it would recognize the transaction Id when submitted by the client. 5. Response Codes 208 Abort - This response code indicates that the method was rejected and its associated transaction was aborted. Note that 208 Abort is a new HTTP response code, introduced by this specification. 405 Method Not Allowed - The resource's TM is not able to transact this particular method. As such the method has been rejected but the transaction has not been aborted. 412 Precondition Failed - The transaction identified by the Transaction header is not active. This could mean it never existed or that it did exist but has been aborted or committed. The client is expected to determine the disposition of the transaction through the use of [TIP]. 502 Bad Gateway - The resource's TM was not able to communicate with the TM(s) controlling the transaction through any of the transports identified by the transaction Ids. This problem could arise either because the resource's TM does not support any of the protocols identified by the transaction Id or because other problems are preventing the successful use of the identified transports. The resource SHOULD return a Transaction response header with endpoints in order to allow the client's TM to directly establish the transaction. 6. Security Considerations Transaction Ids, do not, in and of themselves, pose a security threat. The mere possession of a transaction Id is not sufficient to perform an action. Rather the combination of knowledge of a transaction Id along with authentication of identity is necessary to request a method be transacted. A method with a Transaction request header but without proper authentication MUST be rejected. To this end all resources that support the Transaction header MUST, at minimum, support the [TLS] protocol. Alternative authentication mechanisms MAY be used as appropriate. Y. Y. Goland [Page 3] INTERNET-DRAFT Using TIP with HTTP November 20, 1997 As with all HTTP communications, man in the middle attacks pose a potential threat. Please refer to the security considerations section of [RFC2068] for a discussion of this and other HTTP related security issues. 7. Internationalization There are no internationalization issues as this specification does not provide for any human readable elements. 8. Author's Addresses Yaron Y. Goland Microsoft 1 Microsoft Way Redmond, WA 98052 Email: yarong@microsoft.com 9. Bibliography [Bradner] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, BCP 14. Harvard University. March, 1997. [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", Work In Progress, November 12, 1997. [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- Lee, 'Hypertext Transfer Protocol -- HTTP/1.1', RFC 2068, January 1997, [TIP] J. Lyon, K. Evans, J. Klein, 'Transaction Internet Protocol', Work In Progress, October 20th, 1997, Y. Y. Goland [Page 4]