Re: [rtcweb] *MUST* DCEP?

Ted Hardie <ted.ietf@gmail.com> Tue, 04 March 2014 11:17 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD401A02CE for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 03:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, 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 8RIt11i0ncOn for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 03:17:15 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2981A0056 for <rtcweb@ietf.org>; Tue, 4 Mar 2014 03:17:15 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id as1so6984813iec.3 for <rtcweb@ietf.org>; Tue, 04 Mar 2014 03:17:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u/JtYGCVbUkyn3CDKXofDZ6HQy3sgjKscHjFOHwvNZ0=; b=LibW7dWwjIJQwL/PbgnhI1xf7fYCRCtfGxn2CtHQ1H35e1r7AHE5pcwvUh48l4q6Eg nr/c83WvdHEWFnDnfpn8xIHHWqIO4+mMdIjOwUEARCOUlSKNZ3nY3HSSxxsq2C2dvZw4 Ng33sb4f2maK02dmvWM35UDm6qZ9TkVgZ5Av/r+Do8/PS8/S0KSrKC122+r1GSXhMO1C hTa6174uJKySUJnKVAuEqoEk4zf3h+mpyd5++Ng16rQnKpjx7D5jlCmu9wZfHqL97Wex nnys4iJ9aAaT0EfreE7cnyrRL104qvrazXEL/r9Dz/nC48jp0QnSjKqCNDeuzGLlDcqw lm5w==
MIME-Version: 1.0
X-Received: by 10.50.137.71 with SMTP id qg7mr28005990igb.30.1393931832409; Tue, 04 Mar 2014 03:17:12 -0800 (PST)
Received: by 10.42.237.206 with HTTP; Tue, 4 Mar 2014 03:17:12 -0800 (PST)
In-Reply-To: <5315B2E8.7010703@alum.mit.edu>
References: <5315B2E8.7010703@alum.mit.edu>
Date: Tue, 4 Mar 2014 11:17:12 +0000
Message-ID: <CA+9kkMAstUJHgMNRHE1EokqnNhyX0W+YPKvq7_=Miq4+Tbi5aw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=001a11c3c196b643ec04f3c60b4c
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kGI1Wut3rItj_0eoxJqBdFCy6cw
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] *MUST* DCEP?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 04 Mar 2014 11:17:17 -0000

On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Ted,
>
> (I think this was open issue #8)
>
> You closed discussion on this, saying that this should be specified in
> some rtcweb "system" document. IIUC, then I disagree.
>
> This is important to others besides rtcweb. We want to use this mechanism,
> both with and without components that are implementing rtcweb. Certainly
> for non-browsers.
>
>
Help me understand why it wouldn't then be in their systems documents?

Ted




> This ultimately comes down to what I can expect after having negotiated
> (in SDP) the establishment of an SCTP association. When doing so, I use
> a=sctpmap to negotiate the how the association will be used. If I intend to
> use data channels and DCEP then I want an assurance that the other end does
> too. (That is the purpose of the SDP negotiation.)
>
> AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or
> 'a=sctp-datachannel' depending on where I look), that means the other side
> supports data channels *and* guarantees support for DCEP. There is no means
> to indicate support for data channels *without* DCEP.
>
> I don't see any urgent need to have data channels without DCEP, as long as
> *use* of DCEP is optional.
>
> IMO things would be less confusing if the two documents were merged into
> one, that defines the *Data Channel Protocol* (that runs over SCTP). This
> protocol runs over pairs of SCTP streams, has a small number of messages
> (open, ack, string-payload, binary-payload, close), and encodes them in
> SCTP using SCTP messages with particular payloads and SCTP stream reset.
> The open and ack messages would be optional.
>
>         Thanks,
>         Paul
>