Re: [rtcweb] API requirements

Harald Alvestrand <harald@alvestrand.no> Thu, 19 July 2012 09:55 UTC

Return-Path: <harald@alvestrand.no>
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 1AD7B21F87A5 for <rtcweb@ietfa.amsl.com>; Thu, 19 Jul 2012 02:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 G0eg0tZMkmqa for <rtcweb@ietfa.amsl.com>; Thu, 19 Jul 2012 02:55:14 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EDE1D21F8783 for <rtcweb@ietf.org>; Thu, 19 Jul 2012 02:55:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4253039E16F for <rtcweb@ietf.org>; Thu, 19 Jul 2012 11:56:05 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmqryNroD5+K for <rtcweb@ietf.org>; Thu, 19 Jul 2012 11:56:04 +0200 (CEST)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4166139E062 for <rtcweb@ietf.org>; Thu, 19 Jul 2012 11:56:04 +0200 (CEST)
Message-ID: <5007D9B4.6020008@alvestrand.no>
Date: Thu, 19 Jul 2012 11:56:04 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnWfes+v0eGjP=CavKnp5xri0yJu3XO1zr3jLHR-MvUL+A@mail.gmail.com>
In-Reply-To: <CABkgnnWfes+v0eGjP=CavKnp5xri0yJu3XO1zr3jLHR-MvUL+A@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] API requirements
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: Thu, 19 Jul 2012 09:55:15 -0000

On 07/09/2012 11:10 PM, Martin Thomson wrote:
> We have just submitted a draft for discussion in the rtcweb working group:
>
>      <http://tools.ietf.org/html/draft-thomson-rtcweb-api-reqs-00>
>
> This draft describes the information that must pass between browser
> and application in order to establish real-time communications.  This
> is not user-facing requirements (-rtcweb-use-cases-and-requirements)
> or an outright API specification (-jsep).
>
> The goal here is to enable the creation and consumption of streams of
> media packets within the security constraints.  The draft describes
> the minimum necessary set of information only to achieve this end.
Thanks for submitting this!

I must admit to being quite confused by the actual requirements in the 
draft - I have no idea what use case they're intending to enable, and 
thus I have no idea why the authors have chosen MUST rather than SHOULD 
or MAY as the requirement levels.

For instance.

    ICE-5  The application MUST be able to add STUN attributes to the
           STUN messages that are sent for connectivity checks.

What application does this enable? What are the security implications?

    MED-1   The application MUST be able to select the UDP flow that an
            RTP stream uses.

    MED-2   The application MUST be able select the UDP flow that RTCP
            for a given RTP stream uses.

What application does this enable, compared to mechanisms that assign 
RTP and RTCP to a given UDP flow and report the results back?

    MED-7   The application MUST be able to specify the RTP packet type
            that is used to identify codecs in RTP streams, both inbound
            and outbound.

Again, what application does this enable, compared to mechanisms that 
assign a packet type and inform the application of which one was chosen?

>
> In related news, Microsoft just joined the W3C Web Real-Time
> Communications Working Group.  Once a few clerical issues are
> addressed, new W3C proposals that address these requirements will
> follow.
Looking forward to seeing the proposals, and seeing your proposals for 
how they can be pursued without impacting the progress of the present 
specifications and implementations!

>
> --Martin
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb