draft-ietf-hybi-websocket-requirements-00.txt   draft-ietf-hybi-websocket-requirements-01.txt 
HYBI G. Wilkins, Ed. HYBI Working Group G. Montenegro, Ed.
Internet-Draft Webtide.com Internet-Draft Microsoft Corporation
Intended status: Informational M. Stachowiak, Ed. Intended status: Informational M. Stachowiak, Ed.
Expires: November 11, 2010 Apple Expires: February 24, 2011 Apple
May 10, 2010 August 23, 2010
HyBi WebSocket Requirements and Features HyBi WebSocket Requirements and Features
draft-ietf-hybi-websocket-requirements-00 draft-ietf-hybi-websocket-requirements-01
Abstract Abstract
This document considers the requirements and resulting features This document considers the requirements and resulting features
needed for the design of the WebSocket Protocol. The goal of the needed for the design of the WebSocket Protocol. The goal of the
document is to provide a stable base for protocol design and related document is to provide a stable base for protocol design 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 to IETF 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 November 11, 2010. This Internet-Draft will expire on February 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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. HyBi Terminology . . . . . . . . . . . . . . . . . . . . . 3
3. WebSocket Requirements . . . . . . . . . . . . . . . . . . . . 4 3. WebSocket Requirements . . . . . . . . . . . . . . . . . . . . 4
3.1. WebSocket Client Requirements . . . . . . . . . . . . . . . 5 3.1. WebSocket Client Requirements . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 used to retrieve data from an HTTP server, the client sends used to retrieve data from an HTTP server, the client sends HTTP
HTTP requests to the server, and the server returns the requested requests to the server, and the server returns the requested data in
data in HTTP responses. So the client has to poll continuously the HTTP responses. So the client has to poll continuously the server in
server in order to receive new data. order to receive new data.
Recently techniques that enable bidirectional communication over HTTP Recently, techniques that enable bidirectional communication over
have become more pervasive. Those techniques reduce the need to poll HTTP have become more pervasive. Those techniques reduce the need to
continuously the server thanks to the usage of HTTP hanging requests poll continuously the server thanks to the usage of HTTP hanging
and multiple connections between the client and the server requests and multiple connections between the client and the server
[I-D.loreto-http-bidirectional]. [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.
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
is willing and ready to do it; it is willing and ready to do so.
o rely on a single TCP connection for traffic in both the o Rely on a single TCP connection for traffic in both directions.
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 the
WebSocket Protocol MUST meet. WebSocket Protocol MUST meet.
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
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.
2.1. HyBi 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.
frame: The basic unit of WebSocket communication, consisting of a frame: The basic unit of WebSocket communication, consisting of a
structured sequence of octets matching the syntax defined in the structured sequence of octets matching the syntax defined in the
actual protocol and transmitted on the established communication actual protocol and transmitted on the established communication
channel. channel.
message: user message: a block of related data with identified message: user message: a block of related data with identified
boundaries. boundaries. A message may comprise multiple frames.
origin server: The server on which a given resource resides or is to origin server: The server on which a given resource resides or is to
be created. be created.
WebSocket handshake: The process (and associated capability
negotiation) that sets up the WebSocket communication channel.
WebSocket communication channel: After the WebSocket handshake is
complete, the resultant bi-directional communication path between
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 communication channel that dictates framing, encoding,
etc.
3. WebSocket Requirements 3. WebSocket Requirements
The following requirements fro 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.hixie-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 a REQ. 1: The WebSocket Protocol MUST run directly on top of the
transport protocol (e.g. TCP, UDP or SCTP, DCCP). transport protocol (over which the communication was running up to
and including the WebSocket handshake).
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 top of a TCP data stream connection. receive) messages on the transport protocol (over which the
communication was running up to and including the WebSocket
handshake).
Reason: transfer data as message prevents the receiver to parse/ Reason: transfer data as message obviates the need for the receiver
handle partial content. to parse/handle partial content.
REQ. 3: It MUST be possible to sent a message when the total size is REQ. 3: The protocol MUST support the ability to fragment a message
into frames of a given length.
REQ. 4: It MUST be possible to send a message when the total size is
either unknown or exceeds a fixed buffer size. either unknown or exceeds a fixed buffer size.
Reason: This will allow dynamic messages to be constructed and sent Reason: This will allow dynamic messages to be constructed and sent
without the need to buffer the entire message. without the need to buffer the entire message.
REQ. 4: Textual data MUST be encoded as UTF-8. REQ. 5: Textual data MUST be encoded as UTF-8.
REQ. 5: The protocol MUST be designed to support different frame REQ. 6: The protocol MUST support and clearly distinguish between
types (e.g. binary). textual and binary data types (e.g. binary) via a common framing
with explicit length indication.
REQ. 6: The WebSocket protocol MUST allow HTTP and WebSocket REQ. 7: The WebSocket protocol MUST allow HTTP and WebSocket
connections to be served from the same port. Consideration MUST connections to be served from the same port. Consideration MUST
be given: be given:
* to provide WebSocket services via modules that plug in to * to provide WebSocket services via modules that plug in to
existing web infrastructure. existing web infrastructure.
* to making it possible and practical to implement standalone * to making it possible and practical to implement standalone
implementations of the protocol without requiring a fully implementations of the protocol without requiring a fully
conforming HTTP implementation. conforming HTTP implementation.
Reason: Some server developers would like to integrate WebSocket Reason: Some server developers would like to integrate WebSocket
support into existing HTTP servers. In addition, the default HTTP support into existing HTTP servers. In addition, the default HTTP
and HTTPS ports are ofter favoured for traffic that has to go through and HTTPS ports are ofter favoured for traffic that has to go through
a firewall, so service providers will likely want to be able to use a firewall, so service providers will likely want to be able to use
WebSocket over ports 80 and 443, even when running a We server on the WebSocket over ports 80 and 443, even when running a Web server on
same host. However there could be scenarios where it is not the same host. However there could be scenarios where it is not
opportune or possible to setup a proxy on the same HTTP server. opportune or possible to setup a proxy on the same HTTP server.
REQ. 7: When sharing host and "well known" port with HTTP, the REQ. 8: If using an HTTP Upgrade exchange in the WebSocket
WebSocket protocol MUST be HTTP compatible until both ends have handshake, the protocol MUST be HTTP compatible up to and
established the WebSocket protocol. including the Upgrade exchange.
Reason: when operating on the standard HTTP ports, existing web
infrastructure may handle according to existing standards prior to
the establishment of the new protocol.
REQ. 8: The protocol SHOULD make it possible and practical to reuse REQ. 9: The protocol SHOULD make it possible and practical to reuse
existing HTTP components where appropriate. existing HTTP components where appropriate.
Reason: the re-usage of existing well-debugged software decreases the Reason: Reusing existing well-debugged software decreases the number
number of implementation errors as well as the possibility to of implementation errors as well as the possibility to introduce
introduce security holes especially and at the same time speed up the security holes, and increases development speed, especially when the
development especially when the Web Socket server is implemented as WebSocket server is implemented as modules that plug in to existing
modules that plug in to existing popular Web servers. popular Web servers.
3.1. WebSocket Client Requirements 3.1. WebSocket Client Requirements
REQ. 9: The WebSocket Client MUST be able to set up a communication REQ. 10: The WebSocket Client MUST be able to set up a communication
channel sending to a WebSocket Server a well defined handshake. channel with a WebSocket Server using a well-defined handshake.
REQ. 10: WebSocket Protocol MUST provide for graceful close of an REQ. 11: The WebSocket Protocol MUST provide for graceful close of
active WebSocket connection on request from the user Application. an active WebSocket connection on request from the user
Application.
Reason: a clean shutdown signals that the other endpoint has Reason: a clean shutdown signals that the other endpoint has
definitely received all the messages sent prior the the close, so definitely received all the messages sent prior to the close, so
there is no protocol uncertainty about what has been processed / what there is no protocol uncertainty about what has been processed and
can be retried on another connection. what can be retried on another connection.
OPEN ISSUE: WebSocket Protocol MUST also allow ungraceful close, REQ. 12: WebSocket Protocol MUST also allow ungraceful close, either
either on request from the user application or as a result of a on request from the user application or as a result of a detected
detected error condition. error condition.
REQ. 11: The WebSocket Client MUST be able to request the server, REQ. 13: The WebSocket Client MUST be able to request the server,
during the handshake, to use a specific WebSocket sub-protocol. during the handshake, to use a specific WebSocket sub-protocol.
REQ. 12: The WebSocket Client MUST have the ability to send REQ. 14: The WebSocket Client MUST have the ability to send and
arbitrary text content to the server on the established clearly distinguish between arbitrary text or binary content to
communication channel, in the form of ordered discrete blocks. the server on the established communication channel.
REQ. 13: The WebSocket Client MUST have the ability to send
arbitrary binary content to the server on the established
communication channel, in the form of ordered discrete blocks.
3.2. WebSocket Server Requirements 3.2. WebSocket Server Requirements
REQ. 14: The WebSocket Server that accept to set up, with a REQ. 15: The WebSocket Server that accepts to set up a communication
WebSocket Client, a communication channel MUST send back to the channel with a WebSocket Client MUST use a well-defined handshake.
WebSocket Client a well defined handshake.
REQ. 15: The WebSocket Server MUST have the ability to send
arbitrary text content to the client on the established
communication channel, in the form of ordered discrete blocks.
REQ. 16: The WebSocket Server MUST have the ability to send REQ. 16: The WebSocket Server MUST have the ability to send and
arbitrary binary content to the client on the established clearly distinguish between arbitrary text or binary content to
communication channel, in the form of ordered discrete blocks. the client on the established communication channel.
3.3. WebSocket Proxies Requirements 3.3. WebSocket Proxies Requirements
Todo Todo
REQ. 17: The WebSocket protocol MUST work over existing proxies to
the same extent as HTTP or HTTPS already does.
Reason: This is in line with Req on HTTP compliance.
3.4. WebSocket Security Requirements 3.4. WebSocket Security Requirements
REQ. 17: The WebSocket Protocol MUST use the Origin-based security REQ. 18: The WebSocket Protocol MUST use the Origin-based security
model commonly used by Web browsers to restrict which Web pages model commonly used by Web browsers to restrict which Web pages
can contact a WebSocket sever when the WebSocket protocol is used can contact a WebSocket sever when the WebSocket protocol is used
from a Web page. from a Web page.
REQ. 18: When used directly (not from a Web page), the WebSocket REQ. 19: When used directly (not from a Web page), the WebSocket
Protocol MUST use an equivalent security model. Protocol MUST use a security model equivalent to that of direct
HTTP or HTTPS usage.
REQ. 19: WebSocket should be designed to be robust against cross- REQ. 20: WebSocket should be designed to be robust against cross-
protocol attacks. The protocol design should consider and protocol attacks. The protocol design should consider and
mitigate the risk presented by WebSocket clients to existing mitigate the risk presented by WebSocket clients to existing
servers (including HTTP servers). It should also consider and servers (including HTTP servers). It should also consider and
mitigate the risk to WebSocket servers presented by clients for mitigate the risk to WebSocket servers presented by clients for
other protocols (including HTTP). other protocols (including HTTP).
Reason: As the Web Socket protocol is expected to be mainly 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).
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 the HyBi chair Salvatore The initial requirements were created by Salvatore Loreto. Thanks to
Loreto <salvatore.loreto@ericsson.com>. Greg Wilkins for fulfilling previous editing duties.
7. Normative References 7. 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.loreto-http-bidirectional] [I-D.ietf-hybi-thewebsocketprotocol]
Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Best Practices for the Use of Long Polling and Streaming
in Bidirectional HTTP", draft-loreto-http-bidirectional-02
(work in progress), February 2010.
[I-D.hixie-thewebsocketprotocol]
Hickson, I., "The WebSocket protocol", Hickson, I., "The WebSocket protocol",
draft-hixie-thewebsocketprotocol-76 (work in progress), draft-ietf-hybi-thewebsocketprotocol-00 (work in
May 2010. progress), May 2010.
7.2. Informative References
[I-D.ietf-hybi-design-space]
Moffitt, J., Loreto, S., Saint-Andre, P., and S. Salsano,
"Design Space for Bidirectional Protocols",
draft-ietf-hybi-design-space-00 (work in progress),
June 2010.
Appendix A. Change Log (to be removed by RFC Editor before publication)
From version -00 to version -01:
o Modified definition of a Message to reflect recent consensus that
it may comprise multiple frames.
o Added definitions for WebSocket handshake, WebSocket communication
channel and WebSocket sub-protocol.
o Updated references to official IETF documents, moved "design-
space" to informational.
o Added a new requirement to support the ability to fragment a
message into frames of a given length
o Reworded Req 5 to reflect recent consensus on "binary+data" as
well as common framing with explicit length indication
o Reworded Req 7 to reflect recent consensus (declared in
Maastricht) on "HTTP compliance"
o Reworded Req 12 and 13 into a single Req on the client being able
to send text or binary content. Elided mention of "discrete
blocks" as the structure of messages is captured elsewhere.
o Reworded Req 15 and 16 into a single Req on the server being able
to send text or binary content. Elided mention of "discrete
blocks" as the structure of messages is captured elsewhere.
o Added a requirement in the proxies requirements section along the
lines of the HTTP compliance requirement, per consensus declared
in Maastricht.
o Modified security requirement when used from outside a browser to
avoid wording in terms of a security model equivalent to that of
browser-based usage.
o Various editorial changes.
Authors' Addresses Authors' Addresses
Greg Wilkins (editor) Gabriel Montenegro (editor)
Webtide.com Microsoft Corporation
644 Emerson Street,Suite 200 One Microsoft Way
Palo Alto 94301 Redmond 98052
USA USA
Email: gregw@webtide.com Email: gabriel.montenegro@microsoft.com
Maciej Stachowiak (editor) Maciej Stachowiak (editor)
Apple Apple
Email: mjs@apple.com Email: mjs@apple.com
 End of changes. 48 change blocks. 
110 lines changed or deleted 166 lines changed or added

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