INTERNET-DRAFT Y. Y. Goland Expires: June 1998 Microsoft Corporation Standards Track January 30, 1998 TIP Working Group Using the Transaction Internet Protocol (TIP) with HTTP draft-ietf-tip-usehttp-01.txt Status of this emo 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). Distribution of this document is unlimited. Please send comments to the Transaction Internet Protocol (TIP) working group at , which may be joined by sending a message with subject "subscribe tip" to . Abstract This specification defines how to use Transaction Internet Protocol (TIP) URLs to transaction arbitrary HTTP communications. 1. Introduction This specification defines how to use [TIP] URLs to transaction arbitrary HTTP communications. Transaction URLs are introduced into HTTP through the use of the Transaction header. When used with a request it indicates that the request is to be made part of the identified transaction. When used with a response it indicates that the method has been transactioned. 2. Terminology The terms "endpoint", "PUSH", "PULL", "Transaction Id", and "Transaction anager (TM)" are used as defined in [TIP]. The key words "UST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD NOT", "RECOMENDED", "MAY", and "OPTIONAL" in this Y. Y. Goland [Page 1] INTERNET-DRAFT Using TIP with HTTP January 30, 1998 document are to be interpreted as described in RFC 2119 [Bradner, 1997]. 3. Transaction Request Header Transaction = "Transaction" ":" 1#("<" absoluteURI ">") ; see section 4.2 of [Berners-Lee] for definition of absoluteURI To transaction an HTTP method is to ensure that any operations performed as a result of the request shall be part of the identified transaction and thus subject to being either committed or rolled back. A method is transacted by including the transaction request header with a transaction URI. If the transaction URI used to identify the transaction is not known to the server then the server could use the URI to PULL the transaction. If, however, the operation cannot be performed as part of the indicated transaction then the response UST return a 412 Precondition Failed error. As TIP supports multiple transports it is possible to have multiple transaction URIs, one for each supported transport, identify the same transaction. Additionally a client may submit the transaction URI used by the superior and the subordinate. Hence the Transaction request header allows for multiple URIs to be listed; these URIs UST all refer to the same transaction. If a client knows the name of the transaction used by the client and the server then it SHOULD, at minimum, send the name known by the server and AY also send the name by which the transaction is known at the client. 4. Transaction Response Header Transaction = "Transaction" ":" #("<" absoluteURI ">") A successful response to a transacted method UST always return a Transaction response header. This is done primarily to indicate that not only has the method been accepted, it has also been transacted. The response header AY contain one or more URIs identifying the transaction. As returning the URIs is not a requirement it is possible that the header will have no value. Additionally a resource AY return a Transaction response header in an error response in order to indicate supported endpoints. This is useful when the resource's T may not be able to PULL the desired transaction but the client's T could PUSH the transaction to the resource's T, thus allowing the transaction request to succeed in the future. Y. Y. Goland [Page 2] INTERNET-DRAFT Using TIP with HTTP January 30, 1998 If the Transaction response header is empty then the client must determine how to communicate with the resource's T through another means. For example, the resource's T may have contacted the client's T and PUSHed a transaction to it. The client's TM then contacted the client and provided it with the transaction URI. Since the resource's T originated the transaction, it would recognize the transaction URI when submitted by the client. A transaction response header AY be included with the response to a method that did not include a transaction request header. This unsolicited transaction response header allows the server to inform the client that the request has been transactioned. Servers UST NOT send an unsolicited transaction response header unless no action is required on the part of the client. If some action is expected of the client then the server UST contact the client's TM. This specification does not define how the client's T is discovered. 5. Discovering the server's T location and support for the Transaction header To discover if a resource supports the Transaction request header one sends an OPTIONS method to the resource. If the resource supports this specification then it UST return the Transaction response header. The Transaction response header AY provide a list of endpoints for the resource's T(s). Not all resource's Ts have endpoints. As such the transaction header AY return with no values. 6. Failure to support the Transaction Header It is possible that in the time between performing OPTIONS discovery of transaction header support and actually executing a method with the Transaction request header, the resource may have stopped supporting the header. This is especially the case when a client caches the information that a resource supports the Transaction request header. If the resource were to loose support for the Transaction request header then upon receiving such a header it would ignore it and execute the requested method. Having the method executed without having been transacted could be an unacceptable situation. To prevent this sort of situation one requires the andatory header feature proposed in [Mandatory]. Please refer to that specification for further details. 7. HTTP/1.1 Response Codes 405 ethod 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. Y. Y. Goland [Page 3] INTERNET-DRAFT Using TIP with HTTP January 30, 1998 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]. 426 Abort - This response code indicates that the method was rejected and its associated transaction was aborted. Note that 426 Abort is a new HTTP response code, introduced by this specification. 502 Bad Gateway - The resource's T was not able to communicate with the T(s) controlling the transaction through any of the transports identified by the transaction URLs. This problem could arise either because the resource's T does not support any of the protocols identified by the transaction URLs 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 T to directly establish the transaction. 8. Example >>Request OPTIONS /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu >>Response HTTP/1.1 200 Success Transaction: The client first determines if the server supports the transaction header. The result tells the client that the server supports the transaction header but it is not advertising any endpoints. However the client has already contacted the server through another means and established a transaction. >>Request OVE /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/~whitehead/index.html Transaction: TIP:tip.ics.uci.edu/studentT?abcdefg >>Response HTTP/1.1 200 Success Transaction: Y. Y. Goland [Page 4] INTERNET-DRAFT Using TIP with HTTP January 30, 1998 The client has asked for the resource to be moved as part of the transaction. The server has responded that the resource has been moved as part of the transaction. 9. Internationalization Considerations There are no internationalization considerations as this specification does not provide for any human readable elements. 10. Security Considerations This section is provided to detail issues concerning the security implications of which TIP applications need to be aware. All of the security considerations of HTTP/1.1 also apply to TIP. 10.1. Authentication of Clients Attacks of particular relevance to this paper are ones based on the introduction, alteration, or removal of transaction headers. The only mechanism to prevent such attacks is one that guarantees both the authentication of the client as well as at least the transaction header. As such all transactions UST be executed over a secure connection. Such a connection can either be created through the use of an isolated network or via Transport Layer Security (TLS) [TLS]. As such all clients and servers which support the transaction header UST support HTTP over TLS [Rescorla, 1998]. 11. IANA Considerations This document defines a new HTTP header Transaction and a new HTTP response code 426 Abort. To ensure correct interoperation IANA UST reserve both the HTTP header name Transaction and the HTTP response code 426 Abort. 12. Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society January 30, 1998. All Rights Reserved. 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 Y. Y. Goland [Page 5] INTERNET-DRAFT Using TIP with HTTP January 30, 1998 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 assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IPLIED WARRANTIES OF ERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 14. References [Berners-Lee] T. Berners-Lee, R. Fielding, L. asinter, 'Uniform Resource Identifiers (URI): Generic Syntax and Semantics', Work In Progress, November 18, 1997, Y. Y. Goland [Page 6] INTERNET-DRAFT Using TIP with HTTP January 30, 1998 [Bradner, 1996] S. Bradner, "The Internet Standards Process - Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996. [Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, BCP 14. Harvard University. arch, 1997. [andatory] H. F. Nielsen, P. Leach, S. Lawrence, "Mandatory Extensions in HTTP", Work In Progress, January 20th, 1998, [Rescorla, 1998] E. Rescorla, "HTTP Over TLS", Work In Progress, January 1998, [TIP] J. Lyon, K. Evans, J. Klein, "Transaction Internet Protocol Version 3.0", Work In Progress, January 26th, 1998, [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", Work In Progress, November 12, 1997, 15. Author's Address Yaron Y. Goland Microsoft Corporation 1 Microsoft Way Redmond, WA 98052 Email: yarong@microsoft.com Y. Y. Goland [Page 7]