Re: [dispatch] X over websockets

Peter Dunkley <peter.dunkley@crocodilertc.net> Thu, 13 February 2014 21:01 UTC

Return-Path: <peter.dunkley@crocodilertc.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1511D1A0470 for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 13:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVphIXUz3B5M for <dispatch@ietfa.amsl.com>; Thu, 13 Feb 2014 13:01:38 -0800 (PST)
Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E56671A047F for <dispatch@ietf.org>; Thu, 13 Feb 2014 13:01:37 -0800 (PST)
Received: by mail-ve0-f175.google.com with SMTP id c14so8867803vea.20 for <dispatch@ietf.org>; Thu, 13 Feb 2014 13:01:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LhUPM5xSCtKbX7wACLlrIlkB9/2FdfIhToMHOwq+nE8=; b=sJd7qiVCq5ucsMsW4805742+oMyjkCEA+3YIYxiq+dl6tFm07x7AUekSpoaTQ4Ck+v J3KIHUZRUGm30/Nn7OE6VL9rXtnuJ4XCXduYE+LehK5Ty8XNJoT9VIFzHoMa0HUNYT8o SjQ9onC0fynP2ajIHDidrQS9gB6756bC5CFX4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=LhUPM5xSCtKbX7wACLlrIlkB9/2FdfIhToMHOwq+nE8=; b=QMkK3P7D2LZacJIzg6n82ag962aXls7urlry+Vy3YpIfDV/1Tvqrxo/KT8XAeLvw0L mT8ovOm9+jKQATMEJgeI+mMKITmfc4YQP7sG631Km7x80+U3tbdzCfdj+LYcSBuGRBtI UZwwhwAgOOZE8rbdGqsJ8UVYl7DeJKakaiC8vb4Xk+VLYtjlPJXOhLxZcb6/Sr8OlSFF xN92V/Uo6d9/jOMuaH5RLz+ErUATz4y/a377yGBE+4pK/QnZRkvBCq4X/iV1KOc4cdnQ c7sxCXddSovRtoN/pQ6qKJJ6mWLI2lmZrLJVrA3nuy6qLnOTDLHvDwyzgUKL4T0YpoxL Ly3A==
X-Gm-Message-State: ALoCoQnrixJJhNdGwYdZ5kvHzu+PElomVXDXD/R4MFG+ZLfc+AXl0kB9emH9iDXda42R180o5pwU
MIME-Version: 1.0
X-Received: by 10.52.168.39 with SMTP id zt7mr1149650vdb.42.1392325296292; Thu, 13 Feb 2014 13:01:36 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 13:01:36 -0800 (PST)
In-Reply-To: <52FD2AE0.7060600@gmail.com>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <CAHBDyN4tSRO_nYy7_-V4xfmDbF0ZeLJ24_fEOQ1p9Z2BvJyinQ@mail.gmail.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <CAHBDyN7hySvbiJYnvRXDQ2ZS_FYFDMaODXBDRarE6DhRwC=fHQ@mail.gmail.com> <CA+ag07bPBHzODTWGKFrKE00nO_wiMgRv2GEwUpGCiH25-Xf2Cw@mail.gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com>
Date: Thu, 13 Feb 2014 21:01:36 +0000
Message-ID: <CAEqTk6TzODAWjpqJPRp_zfGcYm_MLHAvU57sq9h7njpifWiufg@mail.gmail.com>
From: Peter Dunkley <peter.dunkley@crocodilertc.net>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="089e01633c18b2c3d004f24ffe72"
Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/0HybmzDWWbY5O2T7wE6Zzh089OA
Subject: Re: [dispatch] X over websockets
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 21:01:40 -0000

Hello,

Wasn't Sergio's point about what the terminology (for example, within SDP)
should be rather than whether WebSockets is appropriate as a transport or
not?  And isn't this a totally separate issue from the WebSockets vs.
WebRTC question?

I honestly don't see what the problem is with having some protocols over
WebSockets, some protocols over DataChannel, and some over both.  I am sure
it is technically possible to have all of these protocols over one, or the
other, or both, but what is important is which makes sense from a use-case
point-of-view.  Surely the fact that someone is prepared to spend the time
putting together (possibly multiple) versions of a draft is a good
indication that there is interest in using a particular protocol over a
particular transport?

In the MSRP example, when talking about an MSRP client communicating with
an MSRP relay (not two MSRP peers communicating directly), MSRP over
WebSockets makes a lot of sense.  The WebSocket server is much less effort
to implement than the WebRTC DataChannel server.  Further, to generate the
SDP for an INVITE when using MSRP you have to AUTH to the relay, doing this
with WebRTC DataChannel would require:

   - Setting up a session to establish the DataChannel (INVITE, SDP, etc)
   - Sending an AUTH on the DataChannel
   - Setting up a second session for the MSRP connection

or, you could totally redesigning the MSRP relay protocol - which would
miss the point.

Regards,

Peter



On 13 February 2014 20:28, Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> El 13/02/2014 19:38, Paul Kyzivat escribió:
>
>  On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote:
>>
>>> What I mean is that I expect quite a lot of "over websocekts" drafts and
>>> we should try to use the same solution for advertising it in the SDP,
>>> and not have each one have their own way of handling it.
>>>
>>
>> Sigh. Yes, once we had the first of these, it was only a matter of time
>> before the flood began.
>>
>> What concerns me is that for every "X over websockets" there is probably
>> also a good argument for "X over WebRTC Data Channel".
>>
>> Are we going to let that happen?
>>
>> Or for each X are we going to have a beauty contest between websockets
>> and data channel?
>>
>> Or what?
>>
>
> Completely agree, we should try to "close" that discussion once and for
> all and not have the same arguments and discussions in each draft. I am not
> really aware of the IETF process, but could be possible to create a draft
> to address it?
>
> Best regards
> Sergio
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>



-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd