[rtcweb] Checkpointing decisions in RTCWEB
Ted Hardie <ted.ietf@gmail.com> Thu, 07 March 2013 22:48 UTC
Return-Path: <ted.ietf@gmail.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 0770821F8C98 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 14:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 fWZEcd-Vspde for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 14:48:50 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8452F21F8CD0 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 14:48:50 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id c13so1266281ieb.23 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 14:48:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=wHv0vUVL9D9PZUHkE4xq2itIQ4y5ZzjNnTvSoMSl1BI=; b=Y0IrcrBclvXfAeQnUQIVJcV8fTQsv53rCkk/Y2au2V0bRn0MctCvvboNaXw4hzPIkz X24anCDpbHkRv/Xblw/SzmLJMzXciydqPzplzsZIBbfm1xxu2wBTCvYzC9so0bKiHU83 XNcWmS6zUToSw54U9WC3KmRLv19mYhhYk2IGLZpF3VKfaQ6lgr4E/wPPNGHqYEjIU+6+ UR8q1rmWWHVtAVBsRZemgBocQidwoBsOKbq4bH0GnlnBGtVxvrE09JaV5kwsR+S3ZFmm iQORNrhBeM/o6ov4u+FR2KYy95i+PwmxJ4lPv638GUPgxA4cZ9K/824WwTr0S+MYLWjj WkYA==
MIME-Version: 1.0
X-Received: by 10.50.170.102 with SMTP id al6mr16047714igc.20.1362696530080; Thu, 07 Mar 2013 14:48:50 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Thu, 7 Mar 2013 14:48:49 -0800 (PST)
Date: Thu, 07 Mar 2013 14:48:49 -0800
Message-ID: <CA+9kkMAtTOAw4hy5yRhdgW5=Ca9a9LjX9paZrR=+ABJGnJAU=w@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: rtcweb@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Cc: rtcweb-chairs@tools.ietf.org
Subject: [rtcweb] Checkpointing decisions in RTCWEB
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, 07 Mar 2013 22:48:51 -0000
Howdy, For any working group to be able to make consistent progress, it must be able to rely on decisions that have already been taken to remain stable in the absence of new technical issues. Re-raising old issues without new information does not help move the work forward, and, as tempting as it may be for those who raised it the initial times, nor does a chorus of "I thought that all along". For the specific question in the thread entitled "Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP", I believe every point in the thread has been raised before. SDP has been unlovely and arcane for many years, so this is not new news. Despite that old news, we have run consensus calls on this topic in both the IETF and the W3C and agreed to use both it and offer/answer. May I politely suggest we finish that work *before* we examine the need and feasibility of an addtional, potentially lower-layer approach to this? Finishing the work before us does not close off all related work for all time, but failure to produce something viable soon likely will. I'm not sure what hat to wear for this message, so assume a "grumpy old timer" porkpie, size 7 and 3/8ths. regards, Ted Hardie
- [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