Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

Adam Roach <adam@nostrum.com> Wed, 08 May 2013 21:19 UTC

Return-Path: <adam@nostrum.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 5536721F8B90 for <rtcweb@ietfa.amsl.com>; Wed, 8 May 2013 14:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.487
X-Spam-Level:
X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 FmIWBbHiNNtL for <rtcweb@ietfa.amsl.com>; Wed, 8 May 2013 14:19:02 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8E421F8B65 for <rtcweb@ietf.org>; Wed, 8 May 2013 14:19:01 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r48LIxtk093327 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 8 May 2013 16:19:00 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <518AC143.2010006@nostrum.com>
Date: Wed, 08 May 2013 16:18:59 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com> <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu>
In-Reply-To: <518AB095.7010401@alum.mit.edu>
Content-Type: multipart/alternative; boundary="------------050004060201060706030001"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
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, 08 May 2013 21:19:03 -0000

On 5/8/13 15:07, Paul Kyzivat wrote:
> The persistent answerer must send a solicitation that describes the 
> offer it wants the persistent offerer to make on its behalf. You don't 
> explain how this would be encoded, but in general it must be like a 
> delta on the last offer it received.

Sorry, I thought I'd spelled this out relatively clearly:

    So, for example, if the
    "persistent answerer" wishes to add a new audio-visual element, it
    sends a solicitation to the "persistent offerer" indicating that it
    requires one new audio m-line section and one new video m-line
    section.


What I was trying to say above is that the only information you would 
need to convey is literally one, two, or three <mediatype,ordinality> 
pairs. You don't say what you're planning to do with them, just that you 
need them.

I intentionally left syntax out of the document because giving a 
non-normative exemplary syntax seems to encourage infinite bikeshedding 
rather than the high-level discussion that is necessary to form consensus.

So, at the risk of encouraging bikeshedders to complain about dictionary 
key names or XML attributes versus cdata, I'm envisioning something that 
looks roughly like this (using JSON format):

{
   'newAudioStreams': 1,
   'newVideoStreams': 1,
   'newDataChannels': 0
}

...or like this (in XML):

<solicitation>
   <newAudio count="1"/>
   <newVideo count="1"/>
   <newData count="0"/>
</solicitiation>


(Given that this isn't necessarily subject to standardization -- at 
least for the WebRTC-only cases --  implementations could really send 
something as minimal as "[1,1,0]" to get the same point across.)

> I remain dubious that this glare situation is a problem that needs to 
> be fixed.

So am I, but Justin seems to be obsessed with it. That's why I'm 
proposing a non-normative recipe that allows people who are 
unnecessarily preoccupied with the issue to indulge their peccadillos. 
The rest of us are free to ignore it.

/a