HYBI S. Loreto
Internet-Draft Ericsson
Intended status: Informational March 8, 2010
Expires: September 9, 2010
HyBi Requirements and Features
draft-loreto-hybi-requirements-01
Abstract
This document considers the requirements and resulting features
needed for the design of the WebSocket Protocol. The goal of the
document is to provide a stable base for protocol design and related
discussion.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Loreto Expires September 9, 2010 [Page 1]
Internet-Draft HyBi Requirements March 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. HyBi Terminology . . . . . . . . . . . . . . . . . . . . . 3
3. WebSocket Requirements . . . . . . . . . . . . . . . . . . . . 4
3.1. WebSocket Client Requirements . . . . . . . . . . . . . . . 5
3.2. WebSocket Server Requirements . . . . . . . . . . . . . . . 6
3.3. WebSocket Proxies Requirements . . . . . . . . . . . . . . 6
3.4. WebSocket Security Requirements . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Loreto Expires September 9, 2010 [Page 2]
Internet-Draft HyBi Requirements March 2010
1. Introduction
HTTP [RFC2616] is a client/server protocol, where the HTTP servers
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
HTTP requests to the server, and the server returns the requested
data in HTTP responses. So the client has to poll continuously the
server in order to receive new data.
Recently techniques that enable bidirectional communication over HTTP
have become more pervasive. Those techniques reduce the need to poll
continuously the server thanks to the usage of HTTP hanging requests
and multiple connections between the client and the server
[I-D.loreto-http-bidirectional].
The goal of HyBi is to provide an efficient and clean two-way
communication channel between client and server.
The communication channel will:
o allow each side to, independently from the other, send data when
is willing and ready to do it;
o rely on a single TCP connection for traffic in both the
directions.
o reduce the high overhead produced by HTTP headers in each request/
response.
The goal of this work is to provide the set of requirements the
WebSocket Protocol MUST meet.
In the following sections we list and analyse the requirements from
the perspective of clients and servers.
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:
Loreto Expires September 9, 2010 [Page 3]
Internet-Draft HyBi Requirements March 2010
connection: A transport layer virtual circuit established between a
client and a server for the purpose of communication.
frame: The basic unit of WebSocket communication, consisting of a
structured sequence of octets matching the syntax defined in the
actual protocol and transmitted on the established communication
channel.
message: user message: a block of related data with identified
boundaries.
origin server: The server on which a given resource resides or is to
be created.
3. WebSocket Requirements
The following requirements fro WebSocket Protocol have been
identified both in the HyBi wg input document
[I-D.hixie-thewebsocketprotocol] and in the HyBi mailing list
dicussion.
REQ. 1: The WebSocket Protocol MUST run directly on top of a
transport protocol (e.g. TCP, UDP or SCTP, DCCP).
REQ. 2: The WebSocket Protocol MUST be able to handle (send and
receive) messages on top of a TCP data stream connection.
Reason: transfer data as message prevents the receiver to parse/
handle partial content.
REQ. 3: It MUST be possible to sent a message when the total size is
either unknown or exceeds a fixed buffer size.
Reason: This will allow dynamic messages to be constructed and sent
without the need to buffer the entire message.
REQ. 4: Textual data MUST be encoded as UTF-8.
REQ. 5: The protocol MUST be designed to support different frame
types (e.g. binary).
REQ. 6: The WebSocket protocol MUST allow HTTP and WebSocket
connections to be served from the same port. Consideration MUST
be given:
Loreto Expires September 9, 2010 [Page 4]
Internet-Draft HyBi Requirements March 2010
* to provide WebSocket services via modules that plug in to
existing web infrastructure.
* to making it possible and practical to implement standalone
implementations of the protocol without requiring a fully
conforming HTTP implementation.
Reason: Some server developers would like to integrate WebSocket
support into existing HTTP servers. In addition, the default HTTP
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
WebSocket over ports 80 and 443, even when running a We server on the
same host. However there could be scenarios where it is not
opportune or possible to setup a proxy on the same HTTP server.
REQ. 7: When sharing host and "well known" port with HTTP, the
WebSocket protocol MUST be HTTP compatible until both ends have
established the WebSocket protocol.
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
existing HTTP components where appropriate.
Reason: the re-usage of existing well-debugged software decreases the
number of implementation errors as well as the possibility to
introduce security holes especially and at the same time speed up the
development especially when the Web Socket server is implemented as
modules that plug in to existing popular Web servers.
3.1. WebSocket Client Requirements
REQ. 9: The WebSocket Client MUST be able to set up a communication
channel sending to a WebSocket Server a well defined handshake.
REQ. 10: WebSocket Protocol MUST provide for graceful close of an
active WebSocket connection on request from the user Application.
Reason: a clean shutdown signals that the other endpoint has
definitely received all the messages sent prior the the close, so
there is no protocol uncertainty about what has been processed / what
can be retried on another connection.
Loreto Expires September 9, 2010 [Page 5]
Internet-Draft HyBi Requirements March 2010
OPEN ISSUE: WebSocket Protocol MUST also allow ungraceful close,
either on request from the user application or as a result of a
detected error condition.
REQ. 11: The WebSocket Client MUST be able to request the server,
during the handshake, to use a specific WebSocket sub-protocol.
REQ. 12: The WebSocket Client MUST have the ability to send
arbitrary text content to the server on the established
communication channel, in the form of ordered discrete blocks.
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
REQ. 14: The WebSocket Server that accept to set up, with a
WebSocket Client, a communication channel MUST send back to the
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
arbitrary binary content to the client on the established
communication channel, in the form of ordered discrete blocks.
3.3. WebSocket Proxies Requirements
Todo
3.4. WebSocket Security Requirements
REQ. 17: The WebSocket Protocol MUST use the Origin-based security
model commonly used by Web browsers to restrict which Web pages
can contact a WebSocket sever when the WebSocket protocol is used
from a Web page.
REQ. 18: When used directly (not from a Web page), the WebSocket
Protocol MUST use an equivalent security model.
Loreto Expires September 9, 2010 [Page 6]
Internet-Draft HyBi Requirements March 2010
REQ. 19: WebSocket should be designed to be robust against cross-
protocol attacks. The protocol design should consider and
mitigate the risk presented by WebSocket clients to existing
servers (including HTTP servers). It should also consider and
mitigate the risk to WebSocket servers presented by clients for
other protocols (including HTTP).
Reason: As the Web Socket protocol is expected to be mainly used in
browsers, a careful design is necessary to mitigate the chances for
hostile JavaScript to use WebSocket for a cross-protocol attack
against vanilla HTTP resources or non-HTTP servers. More the design
should prevent the possibility for cross-site XMLHttpRequest (using
CORS or XDomainRequest) to be used for a cross-protocol attack
against WebSocket resources, potentially violating integrity (though
not confidentiality).
4. Security Considerations
5. IANA Considerations
This requirements document does not mandate any immediate IANA
actions. However, such IANA considerations may arise from future
HyBi specification documents which try to meet the requirements given
here.
6. Acknowledgments
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.loreto-http-bidirectional]
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]
Loreto Expires September 9, 2010 [Page 7]
Internet-Draft HyBi Requirements March 2010
Hickson, I., "The Web Socket protocol",
draft-hixie-thewebsocketprotocol-75 (work in progress),
February 2010.
Author's Address
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Loreto Expires September 9, 2010 [Page 8]