Re: [rtcweb] Checkpointing decisions in RTCWEB

Peter Thatcher <pthatcher@google.com> Fri, 08 March 2013 15:34 UTC

Return-Path: <pthatcher@google.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 3090E21F854D for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 07:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.928
X-Spam-Level:
X-Spam-Status: No, score=-101.928 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 o2ujLqu+eUkY for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 07:34:02 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 44AE521F84CA for <rtcweb@ietf.org>; Fri, 8 Mar 2013 07:34:02 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id ek20so1808700lab.16 for <rtcweb@ietf.org>; Fri, 08 Mar 2013 07:34:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=dAnhPx4aakytpZy56skowRk9jJAZQTQmy/U8zXF+qRw=; b=PzvdMsV9/1WuCr1n20KxfPXnI0Z5BeyLlW0kk/kYmplldG1j85qoyqFJbDc23LENRh 4m6jl0/J2RrjYRd+ZqqU5lglguq+O3EooCmF8Ek3b7n5VmxUfILGTtKpMnHT/84wH2AH ezUcNYcTcwzTc5SU4EHGt+D3D7gb9gJxyI1dKMkgKH7Q5Z5FXY0bfQVbNEU1uzhe2hGd vRwfiFFSJ9WWdGbLUi1qD7USC/huBVXa7fEoW89y/jNwMXk8KAZ2/Rc4i6EvFeUm2HhA xvNx9oBahjPZ+1H6i4OD61fRv5dKPwWg41Od9EUDIkwtkdtNJWuilxzqdcpN2OTFAkwH 8E1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=dAnhPx4aakytpZy56skowRk9jJAZQTQmy/U8zXF+qRw=; b=bee/ChXQYD4pqA+sty94zXr9hsk8OhHhZ+EOTNo8nTrk51JeFoB8c05GYxYvcUZQ8A QpSLWQHe+i73bX1NASL8I5o/1RFSw1Wd+4e3YeOYADtHzQ5/WGLPH3mZeL1clzxXsyWH dM9HnLQN1JJWJiAyipwO+IE2kZ0C4jkXRIlYRN36rK+8kWVNXHJ5wWpEtdMiU+T0BEn0 FD0H5qdRC2OeSpbggm1L1R0TWwMg4z0QY7+jN6iObKY5JjbMxCxHW6JthXQPXLQSjI/P RNVMJ0TbH0IzrtfhldWrsAsIaw54+gTf7Vty1ZxZ61IQv/DZX0p1uHJlg/VEXFcTbKBb At9w==
X-Received: by 10.152.46.131 with SMTP id v3mr2334141lam.57.1362756841214; Fri, 08 Mar 2013 07:34:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.6.5 with HTTP; Fri, 8 Mar 2013 07:33:21 -0800 (PST)
In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
References: <CA+9kkMAtTOAw4hy5yRhdgW5=Ca9a9LjX9paZrR=+ABJGnJAU=w@mail.gmail.com> <CAHBDyN75PncyA1euiZ-9rr=parAGnM43oAL0JQHykxnJ+3YWww@mail.gmail.com> <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 08 Mar 2013 07:33:21 -0800
Message-ID: <CAJrXDUGme_fXDk2sWFZFYKZJktuJ3t_w=-0KGDndLGe9BJ+jcg@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnH8R+mgqs30AAK6TiNIzyn7W4HytBRp1151cfgmQ5XnRiyQzef8gylCVDxZwv/tWZOyFj4gQ8OKBMD8Em7AQcVx6Sx3vTNwVafISka0YKkD3MGc3InBaceVaozxa8SkUjl8V89TRK2z1k0CmoKj64nIGUu7YyAECZkOw46xo91EVrhoH8cd3hE88VSLeM9ME5z0c5W
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: Re: [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: Fri, 08 Mar 2013 15:34:07 -0000

Sorry for answering a question addressed to Mary, but it's important
to me to remind everyone that SDP isn't the only signalling protocol
in use, and that there isn't a 1:1 mapping between SDP and what
browsers support.


On Fri, Mar 8, 2013 at 6:57 AM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> Mary,
>   How can there be interoperability issues if no one is required to use SDP over the wire?

Not everything uses SDP over the wire.  Jingle devices and
applications don't use SDP over the wire.  If I'd like to interop with
Jingle applications and devices, I would not use SDP over the wire.

> Are you saying that there are things that we need that SDP cannot express (or cannot be extended to express)?

Of course there are things SDP cannot currently express.  For example,
the browser API has explicit methods to support trickle ICE because
SDP doesn't express it well.  It looks like we're going down the same
path with SCTP data channels: since SDP doesn't support SCTP data
channels currently, it's easier for the browser to express data
channels mostly outside of SDP rather than extend SDP.

Of course we can keep extending SDP to include more and more, but even
extending SDP isn't enough.  Just because there's an SDP extension
doesn't mean the browser supports it.  RFC5576, for example.  It's a
standardized extension to SDP, but is it supported by the browser?
There's enormous debate over whether it should be or not.

So, we already have the case that the browser does things that aren't
expressed in SDP, and SDP expresses things the browser can't do.
Extending SDP isn't always the right answer.

>
> - Jim
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mary Barnes
> Sent: Friday, March 08, 2013 9:50 AM
> To: Ted Hardie
> Cc: rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
> Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
>
> As an individual that's also a chair, I truly do understand your pain.
>  I realize that a change this late in the game is not at all a good thing.  I also realize the impact this might have on folks whose products are very entrenched in SDP (including my own employer).  But, this seems very much to be a pay now or pay later situation.  I have 100% confidence that this energetic and intelligent group of folks can come up with a protocol spec that relies on SDP - we have shown over and over that we can eventually make decisions when there are strong proponents with different approaches.  I don't debate that at all, but I am concerned about interoperability issues and the fragility of SDP.
>  This is not at all a new sort of problem - it's a pattern that exists very often in product development.  In my experience, doing something that seems a little more novel and disruptive can be done more quickly than trying to work with existing code/architectures that are being pushed well beyond their limits (based upon original design intent).
> I've seen this time and again in developing products.
>
> We also have a number of situations in IETF where we have been determined to complete something based upon a decision that was made and we have successfully completed protocol documents in these cases.
> However, we have a number of these cases where those documents just get put on a shelf.
>
> Best Regards,
> Mary
>
>
>
> On Thu, Mar 7, 2013 at 4:48 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> 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 mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb