Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05

Martin Thomson <martin.thomson@gmail.com> Fri, 01 November 2013 21:10 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 D20D411E813D for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 14:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level:
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 L9tJg1LMS5b8 for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 14:10:44 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 73E8221E80E1 for <rtcweb@ietf.org>; Fri, 1 Nov 2013 14:10:40 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id t60so59772wes.2 for <rtcweb@ietf.org>; Fri, 01 Nov 2013 14:10:39 -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=o2/CM4NKTqCe6gPpC2DNTsyPUsBryLIMcXFlRJjH314=; b=ZJCl9ibxkm+PtRqt+hzFeDPVPP+N0oDu9cs5KVotI104iTxb0pjvi591FawZGwRKi0 jkK9EkYCOLp2BLv67zlqViQ/MyPVEzBiPnW7vJxe2d19SD/c745RrJf2PWiJtefgmU7m SNnbZw77HE/un3prxsy+00F9CmdvLD1WpuYees5NuJronVuYxjiLuVMqhyOoVn6ZoSzA 4d09sdTBC2KPN5qIPrqGhZhSmPGVN7jt6mFf7rpH+InKVcKJruVubLtLUyU/NqbAftpA ZLV8jEZew6DkK0+xWUmIBZvR1l8gDhEjKX/tEfmzsLhodUg6kZLKBR5FsFs1wiULK2/3 I1Og==
MIME-Version: 1.0
X-Received: by 10.180.9.139 with SMTP id z11mr3887673wia.22.1383340239647; Fri, 01 Nov 2013 14:10:39 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Fri, 1 Nov 2013 14:10:39 -0700 (PDT)
In-Reply-To: <527414A5.9090904@alum.mit.edu>
References: <526FCEC1.7000904@alum.mit.edu> <CABkgnnV4OpPNV41g4owehWOXRv0eiFb6njiu9tChQyOVR8-E3A@mail.gmail.com> <52700422.4020002@alum.mit.edu> <CABkgnnX0+ii2am8LhUHVmP1DHr1ygmVxYZxFMe-AVgL56ZJgOg@mail.gmail.com> <527414A5.9090904@alum.mit.edu>
Date: Fri, 1 Nov 2013 14:10:39 -0700
Message-ID: <CABkgnnXKKe-HVo_Z4nP=B7bEYDDp+LzcAoc=p-UKi=WrDtm81g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05
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, 01 Nov 2013 21:10:44 -0000

On 1 November 2013 13:52, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
> "MediaStreamTrack.readonly Read only
>     Is a boolean value with a value of true if the track is readonly (such a
> video file source or a camera that settings can't be modified), false
> otherwise."
>
> That seems to imply that one that isn't read-only must be read-write. I
> don't see any mention of write-only.


This attribute only really pertains to the constraints API, which is
used to do things like switch cameras between capture modes.  This is
to do things like change resolutions or capture rates on physical
devices.  The assumption here is that this interface is not
appropriate for tracks that originate from the network and so this is
a clear signal to an application that trying to apply constraints is
going to fail.

I know that this oversimplifies the process and that constraints could
be used to provide indications back to RTCPeerConnection about what
constraints to apply to its negotiation functions, but I think that
the conclusion was that this was overcomplicating things.  And we know
very well that it is already complicated beyond the comprehension of
mere mortals anyway.