Re: [rtcweb] 答复: 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

Martin Thomson <martin.thomson@gmail.com> Tue, 22 May 2012 02:51 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 D63F921F85C9 for <rtcweb@ietfa.amsl.com>; Mon, 21 May 2012 19:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.11
X-Spam-Level:
X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
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 YxuVW6bUXbOb for <rtcweb@ietfa.amsl.com>; Mon, 21 May 2012 19:51:10 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13DBA21F85AE for <rtcweb@ietf.org>; Mon, 21 May 2012 19:51:09 -0700 (PDT)
Received: by bkty8 with SMTP id y8so5444955bkt.31 for <rtcweb@ietf.org>; Mon, 21 May 2012 19:51:09 -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:content-transfer-encoding; bh=/7zWSTNjWofyqa0Rxmrq1INjnh8OraUgYH/WXzg6/jA=; b=BlT4MkGxwxg8aXIvzZ13aNC7ZJCK7V7I7Ak+ZnvmyHRw6+MaVPM35TY1XWbCyf75b/ hsWHemn2ibNwLF6AEl+b3jPhGanO7CMcEJTU62FpRduGAN2UEQT0EWzDCxf0+8GPmCKi mQIIDcG7EFpSo9zjFghFTKqnEgC2qPLwHuoVPZE6BwAewsHSbZEYT60XnE0+IY2mxiCH v9G0WEs3Sin6JW8UoVmfjQ6HDSbN3eWJNIin45rgTOUKW7pZ0Cm1nQijX7snjEopyfqP 2U/eKkHlHVuhvBgblbGOf6Rmp0IjFIaAIV6FOjaKX7Zu8Wmf1eQaAakPqjvhkpytznVN M2KA==
MIME-Version: 1.0
Received: by 10.205.33.136 with SMTP id so8mr8432727bkb.1.1337655069047; Mon, 21 May 2012 19:51:09 -0700 (PDT)
Received: by 10.204.66.4 with HTTP; Mon, 21 May 2012 19:51:09 -0700 (PDT)
In-Reply-To: <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com>
References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> <CABkgnnUs4K3aP7Ge4+sQ7e6UDEwx-hGJi50Tn6hG4rEwiz98HQ@mail.gmail.com> <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com>
Date: Mon, 21 May 2012 19:51:09 -0700
Message-ID: <CABkgnnUanv7oBzhOC1Eg69u7SznZUKORQi_ZBaa0LUEi64mf6g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: 邓灵莉/denglingli <denglingli@chinamobile.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] 答复: 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt
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: Tue, 22 May 2012 02:51:11 -0000

On 21 May 2012 18:25, 邓灵莉/denglingli <denglingli@chinamobile.com> wrote:
> [...] I would suggest two options about the security threat statement:
> 1, remove the item c from Section 8; or
> 2, add a few words to notify what is left out and may be of concern in the field and people would know what to expect in reality.
> Would you agree?

I'm not sure about the full implications of these sorts of mechanisms
yet.  I was speaking more generally about rtcweb.  In general however,
it is true that a site (or any entity on the signaling path) can
degrade the experience.

Adding a mechanism like what Magnus proposes lets any participant in a
call perform the same sorts of degradations.  As a site operator, I
want to ensure that this doesn't happen, so that my users always get
the best experience from my site.  So that's not necessarily an
exposure that I like.  Of course, I haven't really analyzed the upside
of this particular trade-off yet...

--Martin

p.s. it might be possible for a mechanism like this to "fix"
downgrades chosen by the site, though that wouldn't be advisable.  The
proposal indicates otherwise: that the constraints set during
negotiation are firm.