Re: [rtcweb] SDP lines (JSEP Issue 27)

Adam Roach <adam@nostrum.com> Mon, 30 March 2015 19:36 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A446E1AD0CF for <rtcweb@ietfa.amsl.com>; Mon, 30 Mar 2015 12:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BH1GDoWIkAN for <rtcweb@ietfa.amsl.com>; Mon, 30 Mar 2015 12:36:11 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F831AD0C9 for <rtcweb@ietf.org>; Mon, 30 Mar 2015 12:36:11 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2UJaAkY082315 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2015 14:36:10 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <5519A5A4.4070205@nostrum.com>
Date: Mon, 30 Mar 2015 14:36:04 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>
References: <5519753D.1080907@nostrum.com> <30772BF4-B814-4CB2-932F-96885D0BD76E@iii.ca>
In-Reply-To: <30772BF4-B814-4CB2-932F-96885D0BD76E@iii.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/CDExQtZWXobKgFHbZ9vkrGAR_Ns>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP lines (JSEP Issue 27)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Mar 2015 19:36:14 -0000

On 3/30/15 14:18, Cullen Jennings wrote:
>> On Mar 30, 2015, at 10:09 AM, Adam Roach <adam@nostrum.com> wrote:
>>
>> i=, u=, e=, p=, z=, r=
>>   SHOULD NOT send, MUST ignore.
> I don't think MUST ignore is correct. First to be clear, I'm not saying the browser needs to do anything with the info in theses lines.
>
> I think MAY ignore or not typically used by a webrtc browser might be a better way to say it. For example, if rtcweb device was taking a streaming video session via webrtc protocols, it might make sense for it to use the i= or u= particularly if the SDP had originally come from an RTSP stream that was gatewayed to WebRTC. Similarly if a browser reported the full SDP it had received in some stats interface, I would expect it not to ignore the lines but actually report what it was it received.
>
> To be clear, I'm not saying the browser needs to do anything with the info in theses lines - it's fine to ignore them. But that's very different from all webrtc things must ignore them. (and I agree with SHOULD NOT send part)

I think we're in agreement about the principle, but might be at cross 
purposes regarding the venue: I agree that non-browsers may well have 
reasons to use these fields, but I don't think this document has much 
bearing on what those implementations do; at least, not as it currently 
describes itself.

 From the introduction section, JSEP "describes how the W3C WEBRTC 
RTCPeerConnection interface is used to control the setup, management and 
teardown of a multimedia session." So, in the context of *this* 
document, it would *appear* that we're in agreement that the proper 
normative behavior is to ignore the values in these lines. So I can see 
why we might be quibbling about "SHOULD" versus "MUST," but your 
objection seems much broader than that.

If our difference of opinion here arises from differing views about 
intended scope for the JSEP document, then we need to start a broader 
conversation around, minimally, the introduction section of the current 
draft.

/a