* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rtcweb Status Pages

Real-Time Communication in WEB-browsers (Concluded WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2011-May-03 — 2019-Aug-14 

2011-05-03 charter

Real-Time Communication in WEB-browsers (rtcweb)


 Current Status: Active

     Magnus Westerlund <magnus.westerlund@ericsson.com>
     Cullen Jennings <fluffy@cisco.com>
     Ted Hardie <ted.ietf@gmail.com>

 Real-time Applications and Infrastructure Area Directors:
     Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
     Robert Sparks <rjsparks@nostrum.com>

 Real-time Applications and Infrastructure Area Advisor:
     Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>

 Mailing Lists:
     General Discussion: rtcweb@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/rtcweb
     Archive:            http://www.ietf.org/mail-archive/web/rtcweb/

Description of Working Group:

  There are a number of proprietary implementations that provide direct
  interactive rich communication using audio, video, collaboration,
  games, etc. between two peers' web-browsers. These are not
  interoperable, as they require non-standard extensions or plugins to
  work.  There is a desire to standardize the basis for such
  communication so that interoperable communication can be established
  between any compatible browsers. The goal is to enable innovation on
  top of a set of basic components.  One core component is to enable
  real-time media like audio and video, a second is to enable data
  transfer directly between clients.

  This work will be done in collaboration with the W3C.  The IETF WG
  will produce architecture and requirements for selection and profiling
  of the on the wire protocols. The architecture needs to be coordinated
  with W3C.  The IETF WG work will identify state information and events
  that need to be exposed in the APIs as input to W3C. The W3C will be
  responsible for defining APIs to ensure that application developers
  can control the components. We will reach out to the developer
  community for consultation and early feedback on implementation.

  The security and privacy goals and requirements will be developed by
  the WG. The security model needs to be coordinated with the W3C.  The
  work will also consider where support for extensibility is needed. RTP
  functionalities, media formats, security algorithms are example of
  things that commonly need extensions, additions or replacement, and
  thus some support for negotiation between clients is required.

  The WG will perform the following work:

  1.  Define the communication model in detail, including how session
      management is to occur within the model.

  2.  Define a security model that describes the security and privacy
      goals and specifies the security protocol mechanisms necessary
      to achieve those goals.

  3.  Define the solution - protocols and API requirements - for
      firewall and NAT traversal.

  4.  Define which media functions and extensions shall be supported in
      the client and their usage for real-time media, including media
      adaptation to ensure congestion safe usage.

  5.  Define what functionalities in the solution, such as media codecs,
      security algorithms, etc., can be extended and how the
      extensibility mechanisms works.

  6.  Define a set of media formats that must or should be supported by
      a client to improve interoperability.

  7.  Define how non media data is transported between clients in a
      secure and congestion safe way.

  8.  Provide W3C input for the APIs that comes from the communication
      model and the selected components and protocols that are part of
      the solution.

  9.  The group will consider options for interworking with legacy VoIP

  This work will be done primarily by using already defined protocols or
  functionalities. If there is identification of missing protocols or
  functionalities, such work can be requested to be done in another
  working group with a suitable charter or by requests for chartering it
  in this WG or another WG. The following topics will be out of scope
  for the initial phase of the WG: RTSP, RSVP, NSIS, Location services,
  Resource Priority, and IM & Presence specific features.

  The products of the working group will support security and keying as
  required by BCP 61 and be defined for IPv4, IPv6, and dual stack
  deployments. The Working Group will consider the possibility of
  defining a browser component that implements an existing session
  negotiation and management protocol. The working group will follow BCP
  79, and adhere to the spirit of BCP 79. The working group cannot
  explicitly rule out the possibility of adopting encumbered
  technologies; however, the working group will try to avoid encumbered
  technologies that require royalties or other encumbrances that would
  prevent such technologies from being easy to use in web browsers.

Goals and Milestones:
  Aug 2011 - Architecture, Security, Privacy and Threat Model sent to W3C
  Aug 2011 - Use cases, Scenarios, and Requirements document (I-D) sent to W3C
  Sep 2011 - Architecture and Security, Privacy, and Threat Model document(s) to IESG as Informational
  Sep 2011 - Use cases, Scenarios, and Requirements for RTCWeb document sent to IESG as Informational
  Dec 2011 - RTCWeb protocol profiles and Media format specification(s) to IESG as PS
  Dec 2011 - Information elements and events APIs Input to W3C
  Apr 2012 - API to Protocol mapping document submitted to the IESG as Informational (if needed)

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/rtcweb/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -