Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Dzonatas Sol <> Sun, 16 October 2011 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D54221F8A4E for <>; Sun, 16 Oct 2011 08:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rlFLuI0uHs11 for <>; Sun, 16 Oct 2011 08:19:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4FA6D21F8A71 for <>; Sun, 16 Oct 2011 08:19:35 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so2427574vcb.31 for <>; Sun, 16 Oct 2011 08:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RAv/YoHhoYJoVeOZmi213aQAk5mrLUsq+tGG/wIdH1w=; b=ubSVdjQaZrL9tvGEW8HVN/sRpAxV2riDCbJ9PLURM2aZEF5rjYx9nYgrAqXDvQ4/xn M3xHFf8LUT7iy8qzZT5aol4MI2gQANyH1oA/V9k+l4c+7BRb38TdOMbCuv81y/L38Dk2 PXR56KtzJfpTOKdlUSxCzTIrw+CU9LIkeBzjM=
MIME-Version: 1.0
Received: by with SMTP id t13mr16467104vdj.45.1318778374633; Sun, 16 Oct 2011 08:19:34 -0700 (PDT)
Received: by with HTTP; Sun, 16 Oct 2011 08:19:34 -0700 (PDT)
In-Reply-To: <>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <> <> <> <>
Date: Sun, 16 Oct 2011 08:19:34 -0700
Message-ID: <>
From: Dzonatas Sol <>
Content-Type: multipart/alternative; boundary="20cf30780d008eb80404af6c04b3"
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Sun, 16 Oct 2011 15:19:36 -0000

On Sun, Oct 16, 2011 at 12:36 AM, Wolfgang

> On Sun, Oct 16, 2011 at 12:46 AM, Dzonatas Sol <> wrote:
> > There are always "border crossing" issues, which often exploits
> encryption
> > as useless even if it works.
> > Main thing is that assets should not be cached server-to-server unless
> those
> > servers tether those assets, yet imagine the
> > transient optimizations possible.
> I'm not sure what you are trying to explain..
> I'm aware that 3d party authentication has its own set of problems,
> but it might be a way to get forward with RTCWEB's signaling problem
> without re-inventing SIP or XMPP.

In SL, the main tether is simulated gravity. It's harder for the client to
just make-up gravity that would agree with the server. With that known logic
and ray-casts there are many other security options besides encryption.

It's seems hard for devs to justify that level of security without such case
being used for games or only seen as games when it is real-time ubiquity in

In your case to "avoid RTCWEB server from having to speak to each other at
all" that would mean absolute no tether and no simulated gravity. If that
was the case then, how do we deal with needs at the Olympics? I would not
expect everyone's mobile to work in unison perfectly as one web to meet all
needs. Safety net? Yes.

On a recent news: I like CSS regions suggestion which limits javascript just
to those regions. I think that helps model this WGs overall case with the
trapezoid layout as CSS.