Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 16 October 2015 22:22 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437AF1B345E for <mmusic@ietfa.amsl.com>; Fri, 16 Oct 2015 15:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 D5Z2FLr4y3CF for <mmusic@ietfa.amsl.com>; Fri, 16 Oct 2015 15:21:55 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710AD1B345C for <mmusic@ietf.org>; Fri, 16 Oct 2015 15:21:54 -0700 (PDT)
X-Halon-ID: 4857175d-7454-11e5-b25c-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 17 Oct 2015 00:21:44 +0200 (CEST)
To: Ted Hardie <ted.ietf@gmail.com>
References: <786615F3A85DF44AA2A76164A71FE1ACDF796695@FR711WXCHMBA01.zeu.alcatel-lucent.com> <56202783.3010300@cisco.com> <7594FB04B1934943A5C02806D1A2204B37B45C83@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACDF79D867@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37B45FDB@ESESSMB209.ericsson.se> <56213DD9.8080308@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B46EA0@ESESSMB209.ericsson.se> <5621596C.3070706@alum.mit.edu> <56215EA6.2010503@omnitor.se> <CA+9kkMApRrks_aMbKTzZideXM=Y-W+tqEhWCSmJXzT+TrsE8Sw@mail.gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <56217878.4000009@omnitor.se>
Date: Sat, 17 Oct 2015 00:21:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CA+9kkMApRrks_aMbKTzZideXM=Y-W+tqEhWCSmJXzT+TrsE8Sw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030300060308020905050407"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/wsk21_QbSaHQCj9cD7yjG1MR8-E>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 22:22:00 -0000

Den 2015-10-16 kl. 22:48, skrev Ted Hardie:
> On Fri, Oct 16, 2015 at 1:31 PM, Gunnar Hellström 
> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>
>     In my view:
>
>     The subprotocol specifications are equally needed as the
>     traditional RTP payload specifications.
>
>     There is a need to register subprotocol identifiers with IANA, and
>     that is usually done through an RFC.
>
>
> ​ Just so we're clear, you mean the sctp payload protocol 
> identifiers?  If that's the case the registry is here:
>
> http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-25
>
> and registration is listed as first come, first served. While it is 
> possible that a specific item be registered, RFC 4960 says:
>
>     The upper layer, i.e., the SCTP user, SHOULD standardize any specific
>     protocol identifier with IANA if it is so desired.  The use of any
>     specific payload protocol identifier is out of the scope of SCTP.
> ​So there will no doubt be cases where it is not registered.
Yes, but it is useful to use sdpneg to tell the other party what 
protocol you want to use.

It seems to me that the subprotocol is not the same as the STCP payload 
protocol identifier.
This is the logic I have traced:

In draft-schwarz-mmusic-t140-usage-data-channel,   a subprotocol = 
"t140"  parameter of dcmap is specified to be declared in
draft-ietf-mmusic-data-channel-sdpneg

The IANA considerations are as yet empty.

In draft-ietf-mmusic-data-channel-sdpneg  5.1.1.5, it is said about the 
subprotocol parameter of dcmap

This parameter maps to the
    'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol].
    Section 8.1 specifies how new subprotocol parameter values are
    registered.

Section 8.1 of sdpneg says:

  Registration of new subprotocol identifiers is performed using the
    existing IANA table "WebSocket Subprotocol Name Registry".

    The following text should be added following the title of the table.
    "This table also includes subprotocol identifiers specified for usage
    within a WebRTC data channel."



In ietf-rtcweb-data-protocol, it is said:

Protocol: Variable Length (sequence of characters)
       If this is an empty string the protocol is unspecified.  If it is
       a non-empty string, it specifies a protocol registered in the

       'WebSocket Subprotocol Name Registry' created in [RFC6455 <https://tools.ietf.org/html/rfc6455>].


So, that matches the information in sdpneg.

But I can not really see that it also would map to the SCTP Payload 
Protocol Identifier.

rtcweb-data-protocol mentions its own use of a SCTP Payload Protocol 
Identifier "WebRTC DCEP" for opening the channel, but not that it would 
then be the same as the subprotocol when data is transferred.

And ietf-data-channel    says in 6.6 that when data is transferred, then 
the 4 defined STCP Payload Protocol Identifiers ( named WebRTC string 
etc. ) MUST be used.

Conclusion, subprotocol is not the same as STCP Payload Protocol 
Identifier.

/Gunnar

>
> regards,
>
> Ted
>
>
>     SDP parameters, SCTP channel characteristics, error handling, and
>     even mapping to RTP transport for use in traditional SIP, all
>     these are natural parts of a data channel subprotocol spec. I
>     cannot see any more natural place to do this than in IETF as a
>     RFC.  Then we have it in a recognized international place that can
>     be referenced from IETF and other organizations such as 3GPP, W3C etc.
>
>     This is valid for the T.140 in data channel and at least its
>     mapping to RFC 4103. It is probably valid for most other
>     subchannel specifications that will follow.
>
>     /Gunnar
>
>
>     Den 2015-10-16 kl. 22:09, skrev Paul Kyzivat:
>
>         On 10/16/15 3:10 PM, Christer Holmberg wrote:
>
>             Hi Paul,
>
>             I do agree that the data channel could be used for t.140,
>             and I support
>             the work to be done.
>
>             My point was the the work doesn't necessarily have to be
>             done in IETF,
>             does it?
>
>
>         I suppose not, if there is another place. But IIUC T.140 over
>         RTP is defined in the IETF, and the protocol work for WebRTC
>         is done in the ietf, so it seems logical to me that T.140 over
>         data channel also be done in ietf.
>
>             Or, is an RFC required for data channel usages?
>
>
>         I don't know. Probably not.
>
>             Thanks,
>             Paul
>
>             Regards,
>
>             Christer
>
>             Sent from my Windows Phone
>             ------------------------------------------------------------------------
>             From: Paul Kyzivat <mailto:pkyzivat@alum.mit.edu
>             <mailto:pkyzivat@alum.mit.edu>>
>             Sent: ‎16/‎10/‎2015 21:11
>             To: mmusic@ietf.org <mailto:mmusic@ietf.org>
>             <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
>             Subject: Re: [MMUSIC] WG adoption of other WebRTC data
>             channel usage
>             drafts?; Re: New Version Notification for
>             draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
>             On 10/16/15 5:50 AM, Christer Holmberg wrote:
>
>                 Sorry - my mistake. But, my comment applies to BFCP too.
>
>                 I see no reason why IETF should work on a T.140 draft
>                 however - unless
>                 there are lots of people who want to do it (which I
>                 doubt).
>
>
>             IIUC, WebRTC doesn't support T.140 (because it is not
>             audio or video).
>             But it could support T.140 over data channel. So that is a
>             motivation
>             for doing the work.
>
>                      Thanks,
>                      Paul
>
>                 Regards,
>
>                 Christer
>
>                 Sent from my Windows Phone
>                 ------------------------------------------------------------------------
>
>                 From: Schwarz, Albrecht (Albrecht)
>                 <mailto:albrecht.schwarz@alcatel-lucent.com
>                 <mailto:albrecht.schwarz@alcatel-lucent.com>>
>                 Sent: ‎16/‎10/‎2015 12:43
>                 To: Christer Holmberg
>                 <mailto:christer.holmberg@ericsson.com
>                 <mailto:christer.holmberg@ericsson.com>>; Flemming
>                 Andreasen <mailto:fandreas@cisco.com
>                 <mailto:fandreas@cisco.com>>; mmusic@ietf.org
>                 <mailto:mmusic@ietf.org>
>                 <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
>                 Subject: RE: [MMUSIC] WG adoption of other WebRTC data
>                 channel usage
>                 drafts?; Re: New Version Notification for
>                 draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
>                      Now, in THIS specific case we are talking about
>                     MSRP, so maybe it
>
>                 makes sense to publish an RFC.
>
>                 This email thread is about T.140 and BFCP, not MSRP!
>                 The MSRP draft is
>                 already adopted by the WG.
>
>                 *From:*Christer Holmberg
>                 [mailto:christer.holmberg@ericsson.com
>                 <mailto:christer.holmberg@ericsson.com>]
>                 *Sent:* Freitag, 16. Oktober 2015 09:26
>                 *To:* Flemming Andreasen; Schwarz, Albrecht
>                 (Albrecht); mmusic@ietf.org <mailto:mmusic@ietf.org>
>                 *Subject:* RE: [MMUSIC] WG adoption of other WebRTC
>                 data channel usage
>                 drafts?; Re: New Version Notification for
>                 draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
>                 Hi,
>
>                 Does a new data channel usage require an RFC???
>
>                 If someone wants to specify a data channel protocol X,
>                 they should be
>                 able to do so without having to gather interest in IETF.
>
>                 Now, in THIS specific case we are talking about MSRP,
>                 so maybe it makes
>                 sense to publish an RFC.
>
>                 Regards,
>
>                 Christer
>
>                 Sent from my Windows Phone
>
>                 ------------------------------------------------------------------------
>
>
>                 *From: *Flemming Andreasen <mailto:fandreas@cisco.com
>                 <mailto:fandreas@cisco.com>>
>                 *Sent: *‎16/‎10/‎2015 01:23
>                 *To: *Schwarz, Albrecht (Albrecht)
>                 <mailto:albrecht.schwarz@alcatel-lucent.com
>                 <mailto:albrecht.schwarz@alcatel-lucent.com>>;
>                 mmusic@ietf.org <mailto:mmusic@ietf.org>
>                 <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
>                 *Subject: *Re: [MMUSIC] WG adoption of other WebRTC
>                 data channel usage
>                 drafts?; Re: New Version Notification for
>                 draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
>                 Hi Albrecht
>
>                 In order for the WG to take on additional work and
>                 specific drafts, we
>                 generally require an expressed interest and support
>                 from the WG. We
>                 haven't seen a lot of that so far on these two drafts,
>                 so you may want
>                 to try and garner some additional interest and
>                 demonstrate that on the
>                 list and/or in the upcoming meeting (let us know if
>                 you would like
>                 agenda time to discuss these).
>
>                 Thanks
>
>                 -- Flemming (as MMUSIC chair)
>
>
>                 On 10/6/15 3:47 AM, Schwarz, Albrecht (Albrecht) wrote:
>
>                     Dear All,
>
>                     like too remind that there are three first WebRTC
>                     data channel applications,
>                     1) MSRP based instant messaging,
>                     2) T.140 based text conversation and
>                     3) BFCP based floor control within a WebRTC
>                     conference service.
>
>                     draft-ietf-mmusic-msrp-usage-data-channel was/is
>                     the precedent for getting a common understanding
>                     about application protocol specific SDP usage (on
>                     top of the generic control of a DC).
>                     The discussion and protocol design are fairly
>                     mature in the meanwhile, hence it is time to start
>                     the work on the two other applications.
>                     We've prepared initial drafts, derived from the
>                     "MSRP draft", see:
>
>                     T.140 Text Conversation over Data Channels
>                     draft-schwarz-mmusic-t140-usage-data-channel-02.txt
>
>                     BFCP floor control signalling over Data Channels
>                     draft-schwarz-mmusic-bfcp-usage-data-channel-01.txt
>
>                     We'd like to request MMUSIC for adoption of these
>                     drafts.
>
>                     Regards,
>                     Albrecht
>
>
>
>                     Re: [MMUSIC] New Version Notification for
>                     draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
>                     Juergen Stoetzer-Bradler
>                     <Juergen.Stoetzer-Bradler@alcatel-lucent.com
>                     <mailto:Juergen.Stoetzer-Bradler@alcatel-lucent.com>
>
>                 <mailto:Juergen.Stoetzer-Bradler@alcatel-lucent.com
>                 <mailto:Juergen.Stoetzer-Bradler@alcatel-lucent.com>>>
>                 Wed, 09 September
>                 2015 14:45 UTCShow header
>
>
>                     Hello,
>
>                     Version 02 of
>                     draft-ietf-mmusic-msrp-usage-data-channel
>                     addresses Christian's comments to version 01,
>                     http://www.ietf.org/mail-archive/web/mmusic/current/msg14537.html,
>                     except for the "setup" attribute related one.
>
>                     We'll come back regarding the SDP setup attribute,
>                     which can be part of an MSRP over data channel
>                     related SDP media description as media level
>                     "a=setup" attribute and/or as MSRP sub-protocol
>                     specific
>                     attribute "a=dcsa:x setup".
>
>                     Thanks,
>                     Juergen
>
>                     On 09.09.2015 16:33,internet-drafts@ietf.org
>                     <mailto:internet-drafts@ietf.org>
>                     <mailto:internet-drafts@ietf.org
>                     <mailto:internet-drafts@ietf.org>> wrote:
>
>                         A new version of I-D,
>                         draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>                         has been successfully submitted by Juergen
>                         Stoetzer-Bradler and posted to the
>                         IETF repository.
>
>                         Name: draft-ietf-mmusic-msrp-usage-data-channel
>                         Revision:    02
>                         Title:               MSRP over Data Channels
>                         Document date:       2015-09-09
>                         Group:               mmusic
>                         Pages:               15
>                         URL:https://www.ietf.org/internet-drafts/draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
>                         Status:https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/
>
>                         Htmlized:https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-02
>
>                         Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-02
>
>
>                         Abstract:
>                              This document specifies how the Message
>                         Session Relay Protocol (MSRP)
>                              can be instantiated as a data channel
>                         sub-protocol, using the SDP
>                              offer/answer exchange-based generic data
>                         channel negotiation
>                              framework.  Two network configurations
>                         are documented: a WebRTC end-
>                              to-end configuration (connecting two MSRP
>                         over data channel
>                              endpoints), and a gateway configuration
>                         (connecting an MSRP over data
>                              channel endpoint with an MSRP over TCP
>                         endpoint).
>
>
>
>
>                         Please note that it may take a couple of
>                         minutes from the time of submission
>                         until the htmlized version and diff are
>                         available at tools.ietf.org
>                         <http://tools.ietf.org>.
>
>                         The IETF Secretariat
>
>                     _______________________________________________
>                     mmusic mailing list
>                     mmusic@ietf.org <mailto:mmusic@ietf.org>
>                     <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
>                     https://www.ietf.org/mailman/listinfo/mmusic
>                     .
>
>
>                 _______________________________________________
>                 mmusic mailing list
>                 mmusic@ietf.org <mailto:mmusic@ietf.org>
>                 <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
>                 https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>                 _______________________________________________
>                 mmusic mailing list
>                 mmusic@ietf.org <mailto:mmusic@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/mmusic
>
>
>             _______________________________________________
>             mmusic mailing list
>             mmusic@ietf.org <mailto:mmusic@ietf.org>
>             https://www.ietf.org/mailman/listinfo/mmusic
>
>
>         _______________________________________________
>         mmusic mailing list
>         mmusic@ietf.org <mailto:mmusic@ietf.org>
>         https://www.ietf.org/mailman/listinfo/mmusic
>
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>