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
- [rtcweb] Checkpointing decisions in RTCWEB Ted Hardie
- Re: [rtcweb] Checkpointing decisions in RTCWEB Mary Barnes
- Re: [rtcweb] Checkpointing decisions in RTCWEB Jim Barnett
- Re: [rtcweb] Checkpointing decisions in RTCWEB Adam Roach
- Re: [rtcweb] Checkpointing decisions in RTCWEB Peter Thatcher
- Re: [rtcweb] Checkpointing decisions in RTCWEB Mary Barnes
- Re: [rtcweb] Checkpointing decisions in RTCWEB Adam Roach
- Re: [rtcweb] Checkpointing decisions in RTCWEB Mary Barnes
- Re: [rtcweb] Checkpointing decisions in RTCWEB Robin Raymond
- Re: [rtcweb] Checkpointing decisions in RTCWEB Jim Barnett
- Re: [rtcweb] Checkpointing decisions in RTCWEB (U… Roy, Radhika R CIV USARMY (US)
- Re: [rtcweb] Checkpointing decisions in RTCWEB Martin Thomson