draft-ietf-hybi-websocket-requirements-01.txt   draft-ietf-hybi-websocket-requirements-02.txt 
HYBI Working Group G. Montenegro, Ed. HYBI Working Group G. Montenegro, Ed.
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Intended status: Informational M. Stachowiak, Ed. Intended status: Informational March 14, 2011
Expires: February 24, 2011 Apple Expires: September 15, 2011
August 23, 2010
HyBi WebSocket Requirements and Features HyBi WebSocket Requirements and Features
draft-ietf-hybi-websocket-requirements-01 draft-ietf-hybi-websocket-requirements-02
Abstract Abstract
This document considers the requirements and resulting features This document states the requirements of the WebSocket Protocol. The
needed for the design of the WebSocket Protocol. The goal of the goal of the document is to provide a stable base for protocol design
document is to provide a stable base for protocol design and related and related discussion.
discussion.
Requirements Language
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 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 24, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
3. WebSocket Requirements . . . . . . . . . . . . . . . . . . . . 4 3. WebSocket Requirements . . . . . . . . . . . . . . . . . . . . 4
3.1. WebSocket Client Requirements . . . . . . . . . . . . . . . 5 3.1. WebSocket Client Requirements . . . . . . . . . . . . . . . 6
3.2. WebSocket Server Requirements . . . . . . . . . . . . . . . 6 3.2. WebSocket Server Requirements . . . . . . . . . . . . . . . 6
3.3. WebSocket Proxies Requirements . . . . . . . . . . . . . . 6 3.3. WebSocket Proxies Requirements . . . . . . . . . . . . . . 6
3.4. WebSocket Security Requirements . . . . . . . . . . . . . . 6 3.4. WebSocket Security Requirements . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . 8 publication) . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
HTTP [RFC2616] is a client/server protocol, where the HTTP servers HTTP [RFC2616] is a client/server protocol, where the HTTP servers
store the data and provide it when it is requested by clients. When store the data and provide it when it is requested by clients. When
used to retrieve data from an HTTP server, the client sends HTTP used to retrieve data from an HTTP server, the client sends HTTP
requests to the server, and the server returns the requested data in requests to the server, and the server returns the requested data in
HTTP responses. So the client has to poll continuously the server in HTTP responses. So the client has to poll the server continuously in
order to receive new data. order to receive new data.
Recently, techniques that enable bidirectional communication over Recently, techniques that enable bidirectional communication over
HTTP have become more pervasive. Those techniques reduce the need to HTTP have become more pervasive. Those techniques reduce the need to
poll continuously the server thanks to the usage of HTTP hanging poll continuously the server thanks to the usage of HTTP hanging
requests and multiple connections between the client and the server requests and multiple connections between the client and the server
[I-D.ietf-hybi-design-space]. [I-D.ietf-hybi-design-space].
The goal of HyBi is to provide an efficient and clean two-way The goal of HyBi is to provide an efficient and clean two-way
communication channel between client and server. communication channel between client and server.
skipping to change at page 3, line 33 skipping to change at page 3, line 33
The communication channel will: The communication channel will:
o Allow each side to, independently from the other, send data when o Allow each side to, independently from the other, send data when
it is willing and ready to do so. it is willing and ready to do so.
o Rely on a single TCP connection for traffic in both directions. o Rely on a single TCP connection for traffic in both directions.
o Reduce the high overhead produced by HTTP headers in each request/ o Reduce the high overhead produced by HTTP headers in each request/
response. response.
The goal of this work is to provide the set of requirements the The goal of this work is to provide the set of requirements for the
WebSocket Protocol MUST meet. WebSocket Protocol.
In the following sections we list and analyse the requirements from In the following sections we list and analyse the requirements from
the perspective of clients and servers. the perspective of clients and servers.
2. Terminology 2. Terminology
This document uses the following HyBi-related terms: This document uses the following HyBi-related terms:
connection: A transport layer virtual circuit established between a connection: A transport layer virtual circuit established between a
client and a server for the purpose of communication. client and a server for the purpose of communication.
skipping to change at page 4, line 22 skipping to change at page 4, line 22
negotiation) that sets up the WebSocket communication channel. negotiation) that sets up the WebSocket communication channel.
WebSocket communication channel: After the WebSocket handshake is WebSocket communication channel: After the WebSocket handshake is
complete, the resultant bi-directional communication path between complete, the resultant bi-directional communication path between
client and server over the transport (e.g., TCP, or SSL over TCP). client and server over the transport (e.g., TCP, or SSL over TCP).
WebSocket sub-protocol: The negotiated sub-protocol for use on a WebSocket sub-protocol: The negotiated sub-protocol for use on a
WebSocket communication channel that dictates framing, encoding, WebSocket communication channel that dictates framing, encoding,
etc. etc.
2.1. Requirements Language
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 [RFC2119].
3. WebSocket Requirements 3. WebSocket Requirements
The following requirements for the WebSocket Protocol have been The following requirements for the WebSocket Protocol have been
identified both in the HyBi wg input document identified both in the HyBi wg input document
[I-D.ietf-hybi-thewebsocketprotocol] and in the HyBi mailing list [I-D.ietf-hybi-thewebsocketprotocol] and in the HyBi mailing list
dicussion. dicussion.
REQ. 1: The WebSocket Protocol MUST run directly on top of the REQ. 1: The WebSocket Protocol MUST run directly on top of the
transport protocol (over which the communication was running up to transport protocol (over which the communication was running up to
and including the WebSocket handshake). and including the WebSocket handshake). The transport protocol is
limited to TCP.
REQ. 2: The WebSocket Protocol MUST be able to handle (send and REQ. 2: The WebSocket Protocol MUST be able to handle (send and
receive) messages on the transport protocol (over which the receive) messages on the transport protocol (over which the
communication was running up to and including the WebSocket communication was running up to and including the WebSocket
handshake). handshake).
Reason: transfer data as message obviates the need for the receiver Reason: transfer data as message obviates the need for the receiver
to parse/handle partial content. to parse/handle partial content.
REQ. 3: The protocol MUST support the ability to fragment a message REQ. 3: The protocol MUST support the ability to fragment a message
skipping to change at page 7, line 25 skipping to change at page 7, line 32
Reason: As the WebSocket protocol is expected to be often used in Reason: As the WebSocket protocol is expected to be often used in
browsers, a careful design is necessary to mitigate the chances for browsers, a careful design is necessary to mitigate the chances for
hostile JavaScript to use WebSocket for a cross-protocol attack hostile JavaScript to use WebSocket for a cross-protocol attack
against vanilla HTTP resources or non-HTTP servers. More the design against vanilla HTTP resources or non-HTTP servers. More the design
should prevent the possibility for cross-site XMLHttpRequest (using should prevent the possibility for cross-site XMLHttpRequest (using
CORS or XDomainRequest) to be used for a cross-protocol attack CORS or XDomainRequest) to be used for a cross-protocol attack
against WebSocket resources, potentially violating integrity (though against WebSocket resources, potentially violating integrity (though
not confidentiality). not confidentiality).
Subsequent discussion in the working group has determined consensus
on the use of masking as one of the mechanisms to mitigate this
concern.
4. Security Considerations 4. Security Considerations
5. IANA Considerations 5. IANA Considerations
This requirements document does not mandate any immediate IANA This requirements document does not mandate any immediate IANA
actions. However, such IANA considerations may arise from future actions. However, such IANA considerations may arise from future
HyBi specification documents which try to meet the requirements given HyBi specification documents which try to meet the requirements given
here. here.
6. Acknowledgments 6. Acknowledgments
The initial requirements were created by Salvatore Loreto. Thanks to The initial requirements were created by Salvatore Loreto. Thanks to
Greg Wilkins for fulfilling previous editing duties. Greg Wilkins and Maciej Stachowiak for fulfilling previous editing
duties.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.ietf-hybi-thewebsocketprotocol] [I-D.ietf-hybi-thewebsocketprotocol]
Hickson, I., "The WebSocket protocol", Fette, I., "The WebSocket protocol",
draft-ietf-hybi-thewebsocketprotocol-00 (work in draft-ietf-hybi-thewebsocketprotocol-06 (work in
progress), May 2010. progress), February 2011.
7.2. Informative References 7.2. Informative References
[I-D.ietf-hybi-design-space] [I-D.ietf-hybi-design-space]
Moffitt, J., Loreto, S., Saint-Andre, P., and S. Salsano, Moffitt, J., Loreto, S., Saint-Andre, P., and S. Salsano,
"Design Space for Bidirectional Protocols", "Design Space for Bidirectional Protocols",
draft-ietf-hybi-design-space-00 (work in progress), draft-ietf-hybi-design-space-00 (work in progress),
June 2010. June 2010.
Appendix A. Change Log (to be removed by RFC Editor before publication) Appendix A. Change Log (to be removed by RFC Editor before publication)
From version -01 to version -02:
o In Req. 1, clarified that the transport protocol is TCP.
o Explicit mention of masking as one of the mechanisms to use in
order to mitigate cross-protocol attacks.
o Moved Requirements Language to terminology section.
o Got rid of MUST in intro.
From version -00 to version -01: From version -00 to version -01:
o Modified definition of a Message to reflect recent consensus that o Modified definition of a Message to reflect recent consensus that
it may comprise multiple frames. it may comprise multiple frames.
o Added definitions for WebSocket handshake, WebSocket communication o Added definitions for WebSocket handshake, WebSocket communication
channel and WebSocket sub-protocol. channel and WebSocket sub-protocol.
o Updated references to official IETF documents, moved "design- o Updated references to official IETF documents, moved "design-
space" to informational. space" to informational.
skipping to change at page 9, line 15 skipping to change at page 9, line 35
o Added a requirement in the proxies requirements section along the o Added a requirement in the proxies requirements section along the
lines of the HTTP compliance requirement, per consensus declared lines of the HTTP compliance requirement, per consensus declared
in Maastricht. in Maastricht.
o Modified security requirement when used from outside a browser to o Modified security requirement when used from outside a browser to
avoid wording in terms of a security model equivalent to that of avoid wording in terms of a security model equivalent to that of
browser-based usage. browser-based usage.
o Various editorial changes. o Various editorial changes.
Authors' Addresses Author's Address
Gabriel Montenegro (editor) Gabriel Montenegro (editor)
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond 98052 Redmond 98052
USA USA
Email: gabriel.montenegro@microsoft.com Email: gabriel.montenegro@microsoft.com
Maciej Stachowiak (editor)
Apple
Email: mjs@apple.com
 End of changes. 20 change blocks. 
30 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/