Re: [rtcweb] API requirements

Martin Thomson <martin.thomson@gmail.com> Fri, 20 July 2012 16:39 UTC

Return-Path: <martin.thomson@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 0F68C21F8555 for <rtcweb@ietfa.amsl.com>; Fri, 20 Jul 2012 09:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.94
X-Spam-Level:
X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[AWL=-0.341, 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 Ip8FdMdmbnKP for <rtcweb@ietfa.amsl.com>; Fri, 20 Jul 2012 09:39:15 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20D7D21F8554 for <rtcweb@ietf.org>; Fri, 20 Jul 2012 09:39:14 -0700 (PDT)
Received: by lbbgo11 with SMTP id go11so5773227lbb.31 for <rtcweb@ietf.org>; Fri, 20 Jul 2012 09:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6HJ2DuriKTVQ/R7AEPD8VPUXXy/oGyLzgKNQ8cRspSw=; b=gpjlxTBwWaRc4gEL3D+16IYriKWPMMOsKiooNDyr0fUSNTv+ZF+UC33V86Ix7drhP1 s66fpv3nx1v9hJ8fH5GUqVwSY8aJekgEdF37UrD0bLahk4vnDqydtn1qTj+0PCpNiHmu 0aq9p/ha+QcXwDWZ/ytplDimbL5kXt+DQQwtlUNMWRKenooduSIMWB0zCOjthG0iHRPM oLxx1nownciS1qqA6JY6P4urGj9s6G47dnnInoy9PZPdTXHaO52zGLSD6kk+F76S7BTG USBDentaYn+/q47yb5JTCTUAFuVQh89IO78+RZqkTShaLfkg9/u7PRHjCxx3I4D3C1WW aMHg==
MIME-Version: 1.0
Received: by 10.152.146.169 with SMTP id td9mr6948607lab.42.1342802410532; Fri, 20 Jul 2012 09:40:10 -0700 (PDT)
Received: by 10.112.95.40 with HTTP; Fri, 20 Jul 2012 09:40:10 -0700 (PDT)
In-Reply-To: <5007D9B4.6020008@alvestrand.no>
References: <CABkgnnWfes+v0eGjP=CavKnp5xri0yJu3XO1zr3jLHR-MvUL+A@mail.gmail.com> <5007D9B4.6020008@alvestrand.no>
Date: Fri, 20 Jul 2012 09:40:10 -0700
Message-ID: <CABkgnnUa+SAi4S9TE8iN9e4R1R4+p6UdbYmaZigxcwLAJoEk+g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=UTF-8
Cc: rtcweb@ietf.org
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: Fri, 20 Jul 2012 16:39:16 -0000

On 19 July 2012 02:56, Harald Alvestrand <harald@alvestrand.no> wrote:
> 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.

The point was to describe the minimal set of information that needs to
pass between application and browser in order to accomplish the tasks
described in (draft-rtcweb-use-cases-...) using the protocols and
security mechanisms described in (-rtp-usage and -security-*).  This
aims to be more specific than Section 10 of -rtp-usage and to cover
the other features.

It's a -00 draft.  We acknowledge that the rationale is a little light
(read: not there).

>    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?

This would enable proprietary STUN extensions that include session
identification, authorization, bandwidth negotiation, data transfer,
and other purposes.  Primarily, this is associated with the
"connectivity check" made to a STUN server.

> What are the security implications?

I'm sure you can invent some if you think about it hard enough.  As I
understand it, the application is in complete control over the
username fragment, so this adds no greater advantage to an application
than is already present.  This is just added flexibility that will
enable greater interoperability.  As long as the browser ensures that
the STUN packet fits within the defined size limit, there are none.

>    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?

This is another interoperability requirement.  What you say is only
true if both peers perform compatible allocations.  You will note that
by moving candidates between m= lines, JSEP already offers this
capability.  Assuming of course that the browsers implement that.

>    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?

Same reason as above.

>> 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!

I'm still working on this.  Don't expect the impossible though.