Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)

Harald Alvestrand <harald@alvestrand.no> Thu, 15 September 2011 13:07 UTC

Return-Path: <harald@alvestrand.no>
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 22B9821F8A95 for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 06:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.496
X-Spam-Level:
X-Spam-Status: No, score=-108.496 tagged_above=-999 required=5 tests=[AWL=2.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 u8YC24rrSfg5 for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 06:07:23 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8429121F8A80 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 06:07:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9D4C39E0CD; Thu, 15 Sep 2011 15:09:34 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYqBwzRxq-Ki; Thu, 15 Sep 2011 15:09:34 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 388CF39E072; Thu, 15 Sep 2011 15:09:34 +0200 (CEST)
Message-ID: <4E71F90D.8030302@alvestrand.no>
Date: Thu, 15 Sep 2011 15:09:33 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Lorenzo Miniero <lorenzo@meetecho.com>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <4E71927C.1090606@skype.net> <CALiegfnEaYVsZpKQOoVtT=2gGCzssX79pxLGo7H2Ez0GcMTG-A@mail.gmail.com> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <CALiegfnE9G_vxXDha7pb57pmd=rovLOz=-uWTOirSPDV-pLyMg@mail.gmail.com> <20110915140248.4cc17977@lminiero-acer>
In-Reply-To: <20110915140248.4cc17977@lminiero-acer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)
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: Thu, 15 Sep 2011 13:07:24 -0000

On 09/15/11 14:02, Lorenzo Miniero wrote:
> Il giorno Thu, 15 Sep 2011 13:52:38 +0200
> Iñaki Baz Castillo<ibc@aliax.net>;  ha scritto:
>
>> 2011/9/15 Tim Panton<tim@phonefromhere.com>;:
>>> Are we saying that SDP is so impossible to parse that the only way
>>> to do it is with a pre-existing native library ?!? If not I think
>>> we can do that transformation (when needed) in JavaScript.
>> No, I just said that _maybe_ it wouldl be useful to provide such
>> parsing functions natively (given the fact that various protocol use
>> SDP bodies, as SIP and XMPP).
>>
>> I'm fine with parsing SDP bodies in custom JavaScript code however :)
>>
>
> I don't understand the need for it to be SDP actually: Javascript
> already has native and efficient ways to describe information (JSON,
> XML), if SDP is what everybody wants then it would be easier to just
> map SDP over them.
The disadvantage of parsing to another structure (I am fond of JSON 
myself) is that one has to maintain a data definition for the format 
being parsed to, a defined transform between that and the "canonical SDP 
structure" has to be implemented in user space when one does SDP 
interoperability, both of those have to be updated for every SDP 
extension that someone defines somewhere, and one is still not free to 
define extensions on the non-SDP side if one still requires the ability 
to map them into SDP.

If one uses the "native" SDP format, which is the format in which every 
extension to the format gets documented, the browsers are the ones who 
*have* to parse it (although others are likely to).

                    Harald