Re: [rtcweb] #23: Section 4.4 SDP signaling requirement

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 26 August 2013 17:43 UTC

Return-Path: <bernard_aboba@hotmail.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 6BA1D21E80A9 for <rtcweb@ietfa.amsl.com>; Mon, 26 Aug 2013 10:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.298
X-Spam-Level:
X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, 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 T+aHyg10mUWI for <rtcweb@ietfa.amsl.com>; Mon, 26 Aug 2013 10:43:17 -0700 (PDT)
Received: from blu0-omc1-s29.blu0.hotmail.com (blu0-omc1-s29.blu0.hotmail.com [65.55.116.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7948621E80A5 for <rtcweb@ietf.org>; Mon, 26 Aug 2013 10:43:17 -0700 (PDT)
Received: from BLU169-W27 ([65.55.116.8]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Aug 2013 10:43:16 -0700
X-TMN: [UPQHYK/Rt4vSOOeL0SHZ4Z1fNQQd5p/a]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W271B1F7B2441F43D97085793490@phx.gbl>
Content-Type: multipart/alternative; boundary="_dc497aa3-2fb5-4986-b80a-d4a3fc6a85cd_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Mon, 26 Aug 2013 10:43:16 -0700
Importance: Normal
In-Reply-To: <521B2C5B.1060905@alvestrand.no>
References: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org>, <521AF5E0.2050001@ericsson.com>, <521B2C5B.1060905@alvestrand.no>
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Aug 2013 17:43:16.0830 (UTC) FILETIME=[BEF277E0:01CEA283]
Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement
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: Mon, 26 Aug 2013 17:43:23 -0000

Harald said: 
> I think we're pointing at a more general issue here, which is more a 
> separation-of-concerns thing than anything else.
> 
> With regard to the -rtp-usage- draft, the question can be phrased as:
> Should -rtp-usage- make statements about the signalling protocol in use?
> 
> My interpretation is clearly "no". We have consensus not to mandate a 
> signalling protocol, so it's impossible for -rtp-usage- to make 
> normative statements about it.
[BA] I agree. 
> The next question down is:
> Should -rtp-usage- make requirements on the SDP passed across the W3C API?
> Again, my interpretation is "no". I could argue both that this is out of 
> IETF scope and that -jsep- is the only place that should describe it - 
> the two arguments are inconsistent, but both indicate that -rtp-usage- 
> is not the right place to make those statements.
[BA] I agree with this as a general principle (and not just for rtp-usage). Keeping the RTP usage document focused on RTP and removing thingsthat don't need to be there will allow us to complete it more quickly,and with fewer dependencies on other documents.  That also will makethis and other documents easier to maintain. 
> Third level is:
> Should -rtp-usage- use *informative* references to SDP mechanisms as 
> *examples* of how specific features can be negotiated?
> My suggestion would be "yes". At the moment, we don't have a better 
> description mechanism than the one provided by describing SDP extensions 
> that shows clearly how negotiation can occur.
> In my opinion, there can be other mechanisms (including "cheating" ones 
> like saying "Hey, I know this application I'm talking to, it's only 
> going to run on a browser capable of doing X, and it's going to 
> configure the browser to use X" - we should NOT standardize such 
> mechanisms, but people WILL use them, and suffer the consequences) that 
> achieve the goal of configuring the endpoints correctly.
> 
> It is a bit onerous to write, instead of
> 
>   If such RTP session set-up is to be used, this MUST be negotiated during
>   the signalling phase [I-D.ietf-mmusic-sdp-bundle-negotiation].
> 
> formulating oneself as
> 
>   If such RTP session set-up is to be used, both sides MUST agree beforehand on
>   its usage. In an SDP context, [I-D.ietf-mmusic-sdp-bundle-negotiation] will achieve this.
> 
> But I think it's a more reasonable approach.

[BA] Yes, something like this is what I had in mind.