Re: [rtcweb] New Draft - WebRTC JS Object API Model (UNCLASSIFIED)

"Roy, Radhika R CIV USARMY (US)" <radhika.r.roy.civ@mail.mil> Tue, 02 July 2013 10:44 UTC

Return-Path: <radhika.r.roy.civ@mail.mil>
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 D109021F9E6D for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 03:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, 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 IzOBYSppF1gB for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 03:44:34 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 879C421F944F for <rtcweb@ietf.org>; Tue, 2 Jul 2013 03:44:07 -0700 (PDT)
Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by edge-cols.mail.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 2 Jul 2013 10:44:05 +0000
Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.175]) by UCOLHP3H.easf.csd.disa.mil ([131.64.100.149]) with mapi id 14.03.0123.003; Tue, 2 Jul 2013 10:44:04 +0000
From: "Roy, Radhika R CIV USARMY (US)" <radhika.r.roy.civ@mail.mil>
To: Tim Panton <tim@phonefromhere.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model (UNCLASSIFIED)
Thread-Index: AQHOcibVdEuE4rVfokmLdlNIiK8D3plRGMcAgAAixSA=
Date: Tue, 02 Jul 2013 10:44:03 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49B1412B@ucolhp9b.easf.csd.disa.mil>
References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <CALiegfmsahUM6w00thQSCu3CpKse2C3LKSb1LzkwodNgKTOK0g@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <CALiegfnAN9SJx0nLyegFJoQscG-18Gs4umd-pe7S3y6xREpByQ@mail.gmail.com> <CA+9kkMC5FoxKSz7DuHxN8cEO=0PDpoAGrLshpFmnDe3gco06cw@mail.gmail.com> <CALiegfnpj+nBdhn0g8A7iTdXKZdqvwyffjdLAOuM_qQkhTuKew@mail.gmail.com> <CA+9kkMA1PhoJB9qGUnXDUHRJNac5OszM4o5O7-6aCU-ahszMNw@mail.gmail.com> <CALiegfkei-dS-EHt2vqofft_uhKNz+UuK7R5LX3bgDkh=0ZwqQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> <CAD5OKxs3Zb2CMHsAGUA2hcdDA7tWxUCmH6RbnRt7MGU+JCknqw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> <E6230622-C447-44B4-8F7B-108760792A16@phonefromhere.com>
In-Reply-To: <E6230622-C447-44B4-8F7B-108760792A16@phonefromhere.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [131.64.62.4]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0000_01CE76EF.88EBF730"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model (UNCLASSIFIED)
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: Tue, 02 Jul 2013 10:44:41 -0000

Classification: UNCLASSIFIED
Caveats: NONE

Inline [RRR]

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Tim Panton
Sent: Tuesday, July 02, 2013 4:31 AM
To: Stefan Håkansson LK
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model


On 2 Jul 2013, at 08:21, Stefan Håkansson LK wrote:

	
	But I think we should not underestimate the work needed to describe
all 
	the nitty gritty details using another "language" than SDP.
	


Conversely we shouldn't underestimate (again) the difficulty of describing
all the nitty gritty details in SDP. 

I have the sense that we may have pushed the flexibility of SDP beyond it's
elastic limit.

[<RRR] SDP has been and is basically a session "description" protocol, not a
session "negotiation" protocol unless and until a new method like UPDATE and
O/A have added to increase SDP's "elasticity" to perform a crude type of
negotiations with one dimensional intelligence. [</RRR>]

I think that over the last year we have discovered that a dynamically
programmable browser is a fundamentally different beast from a deskphone and
that what suits one may well not suit the other.

Tim.




Classification: UNCLASSIFIED
Caveats: NONE