Re: [rtcweb] Checkpointing decisions in RTCWEB (UNCLASSIFIED)

"Roy, Radhika R CIV USARMY (US)" <radhika.r.roy.civ@mail.mil> Fri, 08 March 2013 19:33 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 3648321F890F for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 11:33:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 NpKYCx-+ZnIU for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 11:33:37 -0800 (PST)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id C929421F88E8 for <rtcweb@ietf.org>; Fri, 8 Mar 2013 11:33:36 -0800 (PST)
Received: from UCOLHP3B.easf.csd.disa.mil (131.64.100.151) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 8 Mar 2013 19:33:27 +0000
Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.116]) by UCOLHP3B.easf.csd.disa.mil ([131.64.100.151]) with mapi id 14.02.0309.003; Fri, 8 Mar 2013 19:33:27 +0000
From: "Roy, Radhika R CIV USARMY (US)" <radhika.r.roy.civ@mail.mil>
To: Mary Barnes <mary.ietf.barnes@gmail.com>, Adam Roach <adam@nostrum.com>
Thread-Topic: [rtcweb] Checkpointing decisions in RTCWEB (UNCLASSIFIED)
Thread-Index: AQHOHBsZcNqTVidNBEKjNK/XRAqS8picAGsAgAAGZ4CAACI/UA==
Date: Fri, 08 Mar 2013 19:33:25 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49A615FE@ucolhp9b.easf.csd.disa.mil>
References: <CA+9kkMAtTOAw4hy5yRhdgW5=Ca9a9LjX9paZrR=+ABJGnJAU=w@mail.gmail.com> <CAHBDyN75PncyA1euiZ-9rr=parAGnM43oAL0JQHykxnJ+3YWww@mail.gmail.com> <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com> <CAHBDyN7+DoJcbgT3pYqSX7qycYFPtTVZC3CC-okyDep8NYwddg@mail.gmail.com> <513A159E.4030800@nostrum.com> <CAHBDyN4GnoYFKY4Jwiz_0RHX7LXH5AjE+5frDYmE5+TJ2w2Y5w@mail.gmail.com>
In-Reply-To: <CAHBDyN4GnoYFKY4Jwiz_0RHX7LXH5AjE+5frDYmE5+TJ2w2Y5w@mail.gmail.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_003D_01CE1C09.E28C1E00"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB (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: Fri, 08 Mar 2013 19:33:38 -0000

Classification: UNCLASSIFIED
Caveats: NONE

[MB2] ...  I think we need to decouple our applications from the underlying
session setup protocols.  [/MB2]

[RRR]
It is a good idea to do so as it is also seen somewhat in the centralized
conferencing FW (RFC 5239). Accordingly, all other things were developed and
most of them have been new protocols although SIP and SDP were kept as they
are without any extensions per se. Probably it was the case to do so for
this.

If we use the same principles for RTCWEB, we can write a framework document
based on the experiences that we have gained after almost working nearly
more than a year, we can then start to see where we need to do the
development of new protocols keeping SIP and SDP as they are if we think
that our efforts have met a wall.

The reason that we need to do so because we can do an analysis and see what
exactly our requirements are and why we need to start all over again with a
new approach. So far, we have some ideas in both ways with pros and cons,
but it is not entirely clear why and what we exactly need to do to change
our present approaches. Even we take a new approach, we need to a convincing
analysis beforehand we will succeed in solving problems with our new
approach before changing our direction again. [/RRR]

Classification: UNCLASSIFIED
Caveats: NONE