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

Dzonatas Sol <dzonatas@gmail.com> Sat, 15 October 2011 22:46 UTC

Return-Path: <dzonatas@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 E93E521F8558 for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 15:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h34nWdyJVPcI for <rtcweb@ietfa.amsl.com>; Sat, 15 Oct 2011 15:46:14 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51C5921F8551 for <rtcweb@ietf.org>; Sat, 15 Oct 2011 15:46:14 -0700 (PDT)
Received: by vws5 with SMTP id 5so2180521vws.31 for <rtcweb@ietf.org>; Sat, 15 Oct 2011 15:46:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6XCk656T+T2IcutWUxsoa2mOoXDOoGY8UtCG+e+dRLs=; b=iJn+2taODshL9iZkb+iYWSJFudCT8GHXkror3qdPn+R+ZrKjnTpR5pBDgmRd+DbJhE xAfquRNp8DeVvjbS7AsXmi2YpJRYB5Ix5sz4M2ri/QcIt1L6evK02b7JGmyG+EYsnKLo NVpXGOxUN9g0uAuLb4YfFhQA65z1aexAq322A=
MIME-Version: 1.0
Received: by 10.52.34.100 with SMTP id y4mr14266640vdi.66.1318718772312; Sat, 15 Oct 2011 15:46:12 -0700 (PDT)
Received: by 10.52.107.202 with HTTP; Sat, 15 Oct 2011 15:46:12 -0700 (PDT)
In-Reply-To: <CAAPAK-4xJ0ePz5NntKW0qV65yugh3ZSVCPPtDQ-pn+fbZUZoKw@mail.gmail.com>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CAAPAK-4xJ0ePz5NntKW0qV65yugh3ZSVCPPtDQ-pn+fbZUZoKw@mail.gmail.com>
Date: Sat, 15 Oct 2011 15:46:12 -0700
Message-ID: <CAAPAK-4y0S0cPjE9GLoP1xV4+ipNcgz3A0EL6UuCzoc6HKAVog@mail.gmail.com>
From: Dzonatas Sol <dzonatas@gmail.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=20cf3079bb06fb7c4104af5e237d
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Sat, 15 Oct 2011 22:46:15 -0000

On Fri, Oct 14, 2011 at 8:24 AM, <BeckW@telekom.de>; wrote:

> The interconnection trapezoid we inherited from SIP has become a sort of
> Gordian knot. If we could avoid RTCWEB server from having to speak to each
> other at all, we could avoid re-inventing SDP syntax and/or semantics, at
> least to some degree.
>
> https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/ investigates
> how we could get rid of server-to-server communication and the associated
> problems by using 3rd party authentication/authorization. The VWRAP WG
> discussed something similar with regard virtual world systems
> interconnection.
>


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.