[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                               P. Garnero
Internet-Draft                                                Villamicro
Intended status: Informational                             June 29, 2013
Expires: December 31, 2013


    The WebSocket Protocol as a Transport for the Remote Framebuffer
                             Protocol (RFB)
                     draft-garnero-rfb-websocket-00

Abstract

   The WebSocket protocol enables two-way realtime communication between
   clients and servers in web-based applications.  This document
   specifies a WebSocket sub-protocol as a reliable transport mechanism
   between RFB (Remote Framebuffer Protocol) entities to enable usage of
   RFB in web-oriented deployments.

Status of This Memo

   This Internet-Draft is submitted 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 December 31, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.












Garnero                 Expires December 31, 2013               [Page 1]


Internet-Draft      WebSocket as a Transport for RFB           June 2013


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The WebSocket Protocol  . . . . . . . . . . . . . . . . . . .   3
   4.  The WebSocket RFB Sub-Protocol  . . . . . . . . . . . . . . .   4
     4.1.  Handshake . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  RFB Encoding  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  RFB WebSocket Transport . . . . . . . . . . . . . . . . . . .   5
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  FramebufferUpdate Server-to-Client message handling . . .   6
   6.  Connection Keep-Alive . . . . . . . . . . . . . . . . . . . .   7
   7.  Authentication  . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.1.  Secure WebSocket Connection . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Registration of the WebSocket RFB Sub-Protocol  . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The WebSocket [RFC6455] protocol enables message exchange between
   clients and servers on top of a persistent TCP connection (optionally
   secured with TLS [RFC5246]).  The initial protocol handshake makes
   use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to
   reuse existing HTTP infrastructure.

   Modern web browsers include a WebSocket client stack complying with
   the WebSocket API [WS-API] as specified by the W3C. It is expected
   that other client applications (those running in personal computers
   and devices such as smartphones) will also make a WebSocket client
   stack available.  The specification in this document enables usage of
   RFB in these scenarios.




Garnero                 Expires December 31, 2013               [Page 2]


Internet-Draft      WebSocket as a Transport for RFB           June 2013


   This specification defines a WebSocket sub-protocol (as defined in
   section 1.9 in [RFC6455]) for transporting RFB messages between a
   WebSocket client and server, a reliable and (as far as possible)
   message-boundary preserving transport for RFB and procedures for RFB
   entities implementing the WebSocket transport.

2.  Terminology

   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 [RFC2119].

2.1.  Definitions

   RFB WebSocket Client:  A RFB entity capable of opening outbound
         connections to WebSocket servers and communicating using the
         WebSocket RFB sub-protocol as defined by this document.

   RFB WebSocket Server:  A RFB entity capable of listening for inbound
         connections from WebSocket clients and communicating using the
         WebSocket RFB sub-protocol as defined by this document.

3.  The WebSocket Protocol

   The WebSocket protocol [RFC6455] is a transport layer on top of TCP
   (optionally secured with TLS [RFC5246]) in which both client and
   server exchange message units in both directions.  The protocol
   defines a connection handshake, WebSocket sub-protocol and extensions
   negotiation, a frame format for sending application and control data,
   a masking mechanism, and status codes for indicating disconnection
   causes.




















Garnero                 Expires December 31, 2013               [Page 3]


Internet-Draft      WebSocket as a Transport for RFB           June 2013


   The WebSocket connection handshake is based on HTTP [RFC2616] and
   utilizes the HTTP GET method with an "Upgrade" request.  This is sent
   by the client and then answered by the server (if the negotiation
   succeeded) with an HTTP 101 status code.  Once the handshake is
   completed the connection upgrades from HTTP to the WebSocket
   protocol.  This handshake procedure is designed to reuse the existing
   HTTP infrastructure.  During the connection handshake, client and
   server agree on the application protocol to use on top of the
   WebSocket transport.  Such application protocol (also known as a
   "WebSocket sub-protocol") defines the format and semantics of the
   messages exchanged by the endpoints.  This could be a custom protocol
   or a standardized one (as the WebSocket RFB sub-protocol defined in
   this document).  Once the HTTP 101 response is processed both client
   and server reuse the underlying TCP connection for sending WebSocket
   messages and control frames to each other.  Unlike plain HTTP, this
   connection is persistent and can be used for multiple message
   exchanges.

   WebSocket defines message units to be used by applications for the
   exchange of data, so it provides a message boundary-preserving
   transport layer.  These message units can contain either UTF-8 text
   or binary data, and can be split into multiple WebSocket text/binary
   transport frames as needed by the WebSocket stack.

      The WebSocket API [WS-API] for web browsers only defines callbacks
      to be invoked upon receipt of an entire message unit, regardless
      of whether it was received in a single Websocket frame or split
      across multiple frames.

4.  The WebSocket RFB Sub-Protocol

   The term WebSocket sub-protocol refers to an application-level
   protocol layered on top of a WebSocket connection.  This document
   specifies the WebSocket RFB sub-protocol for carrying RFB messages
   through a WebSocket connection.

4.1.  Handshake

   The RFB WebSocket Client and RFB WebSocket Server negotiate usage of
   the WebSocket RFB sub-protocol during the WebSocket handshake
   procedure as defined in section 1.3 of [RFC6455].  The Client MUST
   include the value "rfb" in the Sec-WebSocket-Protocol header in its
   handshake request.  The 101 reply from the Server MUST contain "rfb"
   in its corresponding Sec-WebSocket-Protocol header.

   Below is an example of a WebSocket handshake in which the Client
   requests the WebSocket RFB sub-protocol support from the Server:




Garnero                 Expires December 31, 2013               [Page 4]


Internet-Draft      WebSocket as a Transport for RFB           June 2013


   GET / HTTP/1.1
   Host: rfb-ws.example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Origin: http://www.example.com
   Sec-WebSocket-Protocol: rfb
   Sec-WebSocket-Version: 13


   The handshake response from the Server accepting the WebSocket RFB
   sub-protocol would look as follows:

   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
   Sec-WebSocket-Protocol: rfb


   Once the negotiation has been completed, the WebSocket connection is
   established and can be used for the transport of RFB messages.  The
   WebSocket messages transmitted over this connection MUST conform to
   the negotiated WebSocket sub-protocol.

4.2.  RFB Encoding

   WebSocket messages can be transported in either UTF-8 text frames or
   binary frames.  RFB [RFC6143] defines binary bodies in RFB messages.
   Therefore RFB WebSocket Clients and RFB WebSocket Servers MUST accept
   binary frames and MUST NOT accept text frames.

   Encoding of RFB messages over WebSocket transport remains identical
   to the encoding defined in [RFC6143]

5.  RFB WebSocket Transport

5.1.  General

   WebSocket [RFC6455] is a reliable protocol and therefore the RFB
   WebSocket sub-protocol defined by this document is a reliable RFB
   transport.

   Each RFB message, excepted FramebufferUpdate message, MUST be carried
   within a single WebSocket message, and a WebSocket message MUST NOT
   contain more than one RFB message.





Garnero                 Expires December 31, 2013               [Page 5]


Internet-Draft      WebSocket as a Transport for RFB           June 2013


      Because the WebSocket transport preserves message boundaries, this
      simplifies decoding of (most) RFB messages for both clients and
      servers.

      However, FramebufferUpdate message SHOULD be handled differently
      for performance reasons.

5.2.  FramebufferUpdate Server-to-Client message handling

   According to [RFC6143] section 7.6.1 "FramebufferUpdate", a
   framebuffer update consists of a sequence of rectangles of pixel data
   that the client should put into its framebuffer.  Therefore a RFB
   Websocket Server should have to transfer a certain number of
   rectangles of pixel data to a remote RFB Websocket Client.  The
   amount of data could be quite large depending on the number of
   rectangles, the number of pixel in each rectangle and the encoding of
   the pixels.  It could make sense for the RFB Websocket Server to
   avoid to wait to gather the full amount of rectangles before starting
   to transfer the data to the remote RFB Websocket Client.  That way,
   the remote RFB Websocket Client could start to process "small" parts
   of the framebuffer update in a timely manner instaed of processing
   the full amount of data in one time, which could be a really CPU
   intensive process.  Then, preservation of message boundaries is no
   more required for this RFB message and such an RFB message could be
   transfered by mean of several WebSocket messages.

   Of course, due to the fact that [RFC6143] define a TCP transport, the
   nature of the Remote Framebuffer Protocol let it easily support a non
   preservation of message boundaries.

   However, the RFB Websocket Server should respect the following
   principles:

      The RFB Websocket Server SHOULD elect to send an RFB
      FramebufferUpdate in a single WebSocket message

      Or the RFB Websocket Server SHOULD elect to send an RFB
      FramebufferUpdate in multiple WebSocket messages.  In that case:



            It MUST send the RFB FramebufferUpdate content in a set of
            consecutive WebSocket messages.  That is, It MUST NOT
            transfer any other RFB message until the RFB
            FramebufferUpdate full message is transfered.

            It MUST send the RFB FramebufferUpdate header (see [RFC6143]
            section 7.6.1 "FramebufferUpdate") in a single WebSocket



Garnero                 Expires December 31, 2013               [Page 6]


Internet-Draft      WebSocket as a Transport for RFB           June 2013


            message.  This WebSocket message should be the first message
            related to the transfert of the full RFB FramebufferUpdate
            content.  The RFB FramebufferUpdate header should be alone
            in the WebSocket message, without any rectangle information.

            It MUST send RFB FramebufferUpdate rectangle header
            ([RFC6143] section 7.6.1 "FramebufferUpdate") in a single
            WebSocket message, potentially with a part or all of the
            pixel data associated to this rectangle

            It MUST send rectangle pixel data in a single WebSocket
            message or several consecutive WebSocket messages.

            It MUST NOT mix information related to different rectangles
            in the same WebSocket message.

6.  Connection Keep-Alive

   RFB WebSocket Clients and Servers may keep their WebSocket
   connections open by sending periodic WebSocket "Ping" frames as
   described in [RFC6455] section 5.5.2.

      The WebSocket API [WS-API] does not provide a mechanism for
      applications running in a web browser to control whether or not
      periodic WebSocket "Ping" frames are sent to the server.  The
      implementation of such a keep-alive feature is the decision of
      each web browser manufacturer and may also depend on the
      configuration of the web browser.

7.  Authentication

   Authentication process is fully described in [RFC6143] and remains
   valid if WebSocket transport is used.

8.  Security Considerations

8.1.  Secure WebSocket Connection

   It is recommended that the RFB traffic transported over a WebSocket
   communication be protected by using a secure WebSocket connection
   (using TLS [RFC5246] over TCP).

   When establishing a connection using RFB over secure WebSocket
   transport, the client MUST authenticate the server using the server's
   certificate according to the WebSocket validation procedure in
   [RFC6455].





Garnero                 Expires December 31, 2013               [Page 7]


Internet-Draft      WebSocket as a Transport for RFB           June 2013


9.  IANA Considerations

   RFC Editor Note: Please set the RFC number assigned for this document
   in the sub-sections below and remove this note.

9.1.  Registration of the WebSocket RFB Sub-Protocol

   This specification requests IANA to register the WebSocket RFB sub-
   protocol under the "WebSocket Subprotocol Name" Registry with the
   following data:

   Subprotocol Identifier:  rfb

   Subprotocol Common Name:  WebSocket Transport for RFB (Remote
      Framebuffer Protocol)

   Subprotocol Definition:  Included in this cocument.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
              6455, December 2011.

10.2.  Informative References

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

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6143]  Richardson, T. and J. Levine, "The Remote Framebuffer
              Protocol", RFC 6143, March 2011.

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              April 2011.

   [WS-API]   W3C and I. Hickson, Ed., "The WebSocket API", April 2013.



Garnero                 Expires December 31, 2013               [Page 8]


Internet-Draft      WebSocket as a Transport for RFB           June 2013


Author's Address

   Pierre Garnero
   Villamicro
   Grasse  06130
   France

   Email: pierre.garnero@villamicro.fr











































Garnero                 Expires December 31, 2013               [Page 9]


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