[rtcweb] Proposed new milestones for RTCWEB

Ted Hardie <ted.ietf@gmail.com> Wed, 18 July 2012 19:08 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823F611E8182 for <rtcweb@ietfa.amsl.com>; Wed, 18 Jul 2012 12:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level:
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erR9R3DTybOC for <rtcweb@ietfa.amsl.com>; Wed, 18 Jul 2012 12:08:01 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C982011E817F for <rtcweb@ietf.org>; Wed, 18 Jul 2012 12:08:00 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so1503269vcb.31 for <rtcweb@ietf.org>; Wed, 18 Jul 2012 12:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=00D/pfGYAUPz7wAmOVLGJAWAtXVU+LHpd5CLgvZIxoM=; b=TJ65PGHOlDxqLWWbYTyTq1FsWs6VmrLHOPLbOq+lO8Xikg9kT99xQs4z7GXaxPq2NU K0frMw3zhuYkrCb2d2xdgeG3CnY+NmZJ3odHDxKjnh8iwZ8pNd79pdzfZZoZKPIi6JZn tUtYhvN07pXDACc3Fus2pQgJ1Jm4Fw45IrQ8rVFcUQdWZ/GCd3jOeAuGx9PBw7lc/5Yh rfyx6FqlAF3lxJXFRY3KaChnqNDv2e7lIDy1eH3z51J8lRjEh0Qo48+KDYhuH+PfnefO 4CwJz93CWcej43GzmVRewhSud4Y3kuNnhxbaqNTbbmVf9eu1rzXjWNuZg0j5ZTfDnIjS bvbQ==
MIME-Version: 1.0
Received: by 10.52.73.42 with SMTP id i10mr1258995vdv.116.1342638531167; Wed, 18 Jul 2012 12:08:51 -0700 (PDT)
Received: by 10.52.170.68 with HTTP; Wed, 18 Jul 2012 12:08:51 -0700 (PDT)
Date: Wed, 18 Jul 2012 12:08:51 -0700
Message-ID: <CA+9kkMCqAL+Mi1FV-rkNa5Hd67pg7+_8Ztns8j7O6cxtECo8Gw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: rtcweb@ietf.org, Robert Sparks <rjsparks@nostrum.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [rtcweb] Proposed new milestones for RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2012 19:08:01 -0000

As folks know, we are behind on our milestones.  The following
milestones represent a proposal from me and Magnus, based on some text
from Cullen.  Please review in light of our deliverable list:

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

Timeline:

Sep 2012 - Send Use Cases document to IESG for publication as Informational
Sep 2012 - Complete Overview (and hold for dependency resolution)
Sep 2012 - Send Security and Privacy Problem Statement to IESG for
publication as Informational

Jan 2013 - Send Signalling Negotiation and NAT Traversal to IESG for
publication as Proposed Standard
Jan 2013 - Send Security Solution to IESG for publication as Proposed Standard
Jan 2013 - Send Media Transport, Media Processing, and Codecs to
IESG for publication as Proposed Standard

May 2013 - Send Data Stream Transport for non-media data to IESG for
publication as Proposed Standard

Comments, please!

Ted