[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-loreto-hybi-requirements) 00 01 02

HYBI                                                     G. Wilkins, Ed.
Internet-Draft                                               Webtide.com
Intended status: Informational                        M. Stachowiak, Ed.
Expires: November 11, 2010                                         Apple
                                                            May 10, 2010


                HyBi WebSocket Requirements and Features
               draft-ietf-hybi-websocket-requirements-00

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on November 11, 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
   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 Simplified BSD License.



Wilkins & Stachowiak    Expires November 11, 2010               [Page 1]


Internet-Draft         HyBi WebSocket Requirements              May 2010


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
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8




































Wilkins & Stachowiak    Expires November 11, 2010               [Page 2]


Internet-Draft         HyBi WebSocket Requirements              May 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:




Wilkins & Stachowiak    Expires November 11, 2010               [Page 3]


Internet-Draft         HyBi WebSocket Requirements              May 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:





Wilkins & Stachowiak    Expires November 11, 2010               [Page 4]


Internet-Draft         HyBi WebSocket Requirements              May 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.





Wilkins & Stachowiak    Expires November 11, 2010               [Page 5]


Internet-Draft         HyBi WebSocket Requirements              May 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.







Wilkins & Stachowiak    Expires November 11, 2010               [Page 6]


Internet-Draft         HyBi WebSocket Requirements              May 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

   The initial requirements were created by the HyBi chair Salvatore
   Loreto <salvatore.loreto@ericsson.com>.


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



Wilkins & Stachowiak    Expires November 11, 2010               [Page 7]


Internet-Draft         HyBi WebSocket Requirements              May 2010


              (work in progress), February 2010.

   [I-D.hixie-thewebsocketprotocol]
              Hickson, I., "The WebSocket protocol",
              draft-hixie-thewebsocketprotocol-76 (work in progress),
              May 2010.


Authors' Addresses

   Greg Wilkins (editor)
   Webtide.com
   644 Emerson Street,Suite 200
   Palo Alto  94301
   USA

   Email: gregw@webtide.com


   Maciej Stachowiak (editor)
   Apple

   Email: mjs@apple.com




























Wilkins & Stachowiak    Expires November 11, 2010               [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/