Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications)

Tim Panton <tim@phonefromhere.com> Fri, 21 October 2011 09:56 UTC

Return-Path: <tim@phonefromhere.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 39F5A21F8BA8 for <rtcweb@ietfa.amsl.com>; Fri, 21 Oct 2011 02:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 cI1DtK3iemGC for <rtcweb@ietfa.amsl.com>; Fri, 21 Oct 2011 02:56:16 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8855021F889A for <rtcweb@ietf.org>; Fri, 21 Oct 2011 02:56:16 -0700 (PDT)
Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id AC07937A902; Fri, 21 Oct 2011 11:09:06 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/alternative; boundary="Apple-Mail=_760ADE5D-1000-4E13-B24A-2146784CF7F0"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <6236FA56-9D22-4659-939F-16100F4833DB@ag-projects.com>
Date: Fri, 21 Oct 2011 10:56:26 +0100
Message-Id: <41811EE0-D18A-4F3B-9D0C-DC89CA58C682@phonefromhere.com>
References: <CALiegfmQBEEX+6FuA3tujePh3HUyfCU5Wy3N_=cn_K_GXZ267g@mail.gmail.com> <CALiegf=2Kv1CpS+EONbKZ01R8vvX2g1ofQ+Wgj5EEETr0vQK_g@mail.gmail.com> <931AFC17-0745-439C-ADB4-6E4581855645@phonefromhere.com> <6236FA56-9D22-4659-939F-16100F4833DB@ag-projects.com>
To: Saúl Ibarra Corretgé <saul@ag-projects.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications)
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, 21 Oct 2011 09:56:17 -0000

On 21 Oct 2011, at 10:50, Saúl Ibarra Corretgé wrote:
>> 
>> To answer these questions the JS apps will need to parse the SDP-like blob, so strictly it isn't a Blob anymore.
>> 
> 
> Assuming this SDP-like thing is ROAP, for example, an API could be produced for this purpose. If one wants low level access it ma extract the blob and parse it himself.

My point being that I can't concieve of an app that _didn't_ want to know how big a screen area to
allocate to incoming video (for example). So that JS-window-on-the-blob-API becomes essential,
but we've been told that, it is a) hard b) not necessary to write such a thing.

>> 
>> So in short, I think that treating the SDP-like as a blob has significant disadvantages.
>> 
> 
> Notice the MAY ;-) 

Sure. I'm pointing out that the MAY-NOT is a significant and useful case.

Tim.