Re: [rtcweb] Agenda requests for Atlanta meeting

Eric Rescorla <> Mon, 08 October 2012 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 641FF21F84C8 for <>; Mon, 8 Oct 2012 16:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.765
X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Aft1PqmDju2p for <>; Mon, 8 Oct 2012 16:01:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7D78421F84C5 for <>; Mon, 8 Oct 2012 16:01:39 -0700 (PDT)
Received: by with SMTP id k13so249806eaa.31 for <>; Mon, 08 Oct 2012 16:01:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=OBMx519hJ1+LZqNQBO9yBG75ZvA4F55c/YWn1vWhX5U=; b=a+nodJdMlWZ2T8cpZCh4jMgx0k2jMnVBubm9dULAjfLIan4qExgNNncFPCi+0gbJM/ LtNOd7zHTlp9hrSafVltWMf/leLaQj8Gw/7LIBDKfYhPXRac9EqRc9lCYDqEyjFAqoTw gmRB5uzd0s1hefi/b9YsbcV8+4bbjaMEhAZMIKB2dKuK3lB66ZR34eSs/Wfpl6E7wGI2 rtJPMiLhtP9mcyT75DZ7pSiMdd4xqUqEH0GeZFYui0+zOSxC99AWQEz0zxEh+mIWNqb8 HJMrnRMRIlKHSC7eN1LkmMhO2Dcav2UIi8vrERrxo5S3go9jGE3XatfWVn28YLQZIB/e i62g==
Received: by with SMTP id m5mr25223436eeo.22.1349737298630; Mon, 08 Oct 2012 16:01:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 8 Oct 2012 16:00:58 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 08 Oct 2012 16:00:58 -0700
Message-ID: <>
To: "Cullen Jennings (fluffy)" <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk61b+4S/No9vsqQFoZR+UH4SQmPORlPq7U8YntppfuzbAyorAsIGo4teJbqgtzpu2dPwDJ
Cc: "" <>
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Oct 2012 23:01:40 -0000

I would attend such a phone call if it were held.

My immediate reaction is that from an implementor's perspective. PRANSWER
is a lot easier to address than cloning. I feel like cloning pulls in a lot of
difficult lifetime and ownership semantics. By contrast, supporting PRANSWER
is very easy. Before deciding that cloning is the answer I'd like to see two

1. A clear set of use cases that shows what cloning does well that PRANSWER
does not.
2. A fairly complete defn of the clone semantics.

Otherwise I worry that we'll detour to cloning and then only after 6 months
discover it doesn't work.


On Mon, Oct 8, 2012 at 3:52 PM, Cullen Jennings (fluffy)
<> wrote:
> On Oct 8, 2012, at 2:47 , Christer Holmberg <> wrote:
>> Hi,
>> I would like to discuss the different alternatives in order to support forking, e.g. whether we use cloning, whether we simply set additional local descriptor, and whether we can get rid of PRANSWER.
> Seriously? we have discussed this so many times and always come to the same conclusion. I have not seen anything on the list that suggests why we need to remove this or how mapping to SIP 180 with sequential forking is going to work without it. It also has other important uses. There are a bunch of changes that are needed to the JSEP draft to remove some of the inconsistencies in this and clarify some parts but I'd rather wait till we had that updated before we got into a whole discussion about exploding it yet again.
> Why don't we have a phone call to try and outline what the problems you are trying to solve that the current solution does not work for then figure out how much we want to explode this.
> I'll note that current clone text has lots of "miracles happen here, insert supper fluffy hand wave" in it and plenty of weasel room on failure to allocate required resources on the clone. It's more or less a sketch of an idea at this point. I'm perfectly happy to see people try and sort out the details on clone but using it explode the consensus we have come to around PRANSWER seems like a really bad idea at this point.
> Cullen
> _______________________________________________
> rtcweb mailing list