Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com> Fri, 26 February 2016 14:18 UTC

Return-Path: <juergen.stoetzer-bradler@nokia.com>
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 61ABA1B2C71 for <mmusic@ietfa.amsl.com>; Fri, 26 Feb 2016 06:18:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.501
X-Spam-Level:
X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 ULcoGVS1FjSy for <mmusic@ietfa.amsl.com>; Fri, 26 Feb 2016 06:17:58 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 E06D41B2C61 for <mmusic@ietf.org>; Fri, 26 Feb 2016 06:17:57 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7F6F2314DF04B for <mmusic@ietf.org>; Fri, 26 Feb 2016 14:17:53 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1QEHt4C018354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mmusic@ietf.org>; Fri, 26 Feb 2016 14:17:55 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1QEHaRp032134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Fri, 26 Feb 2016 15:17:55 +0100
Received: from [149.204.68.190] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Feb 2016 15:17:49 +0100
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <5668F9C1.4040606@nteczone.com> <566903E3.8020108@alum.mit.edu> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu>
From: Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Message-ID: <56D05E8D.5080306@alcatel-lucent.com>
Date: Fri, 26 Feb 2016 15:17:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56CF7470.10706@alum.mit.edu>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [135.239.27.41]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/3DWHk91P4Zi5zwf4IQSAycI628w>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
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, 26 Feb 2016 14:18:02 -0000

Hello Paul, Christian,

Would propose to add following definition of term "subprotocol" to the terminology section 3 of the 
sdpneg draft:

       Data channel subprotocol: The application protocol which is
       transported over a single data channel.  Data channel subprotocol
       messages are sent as data channel payload over an established data
       channel.  If an SDP offer/answer exchange is used as specified in
       this document to negotiate the establishment of data channels,
       corresponding data channel properties, associated data channel
       subprotocols and data channel subprotocol properties, then the data
       channel subprotocols may be identified by the values of the
       "subprotocol" parameters of the SDP "a=dcmap" attributes as
       described in Section 5.1.1.5.  Within this document the term "data
       channel subprotocol" is often abbreviated as just "subprotocol".

This text could explicitly narrow down the notion of "subprotocol" within the data channel SDP 
offer/answer context and might especially be helpful distinguishing it from the usages of 
"subprotocol" in the Websocket RFC 6455 (where the term "subprotocol" was taken from, but where it 
does not seem to be formally defined). This text may certainly not be helpful in more general 
non-data channel contexts. But it might help to clarify that every occurrence of of the term 
"subprotocol" in the sdpneg draft refers to the application protocol which (typically but not 
necessarily) is identified via the a=dcmap's "subprotocol" parameter.

Would such an explicit definition be helpful from your point of view?

Thanks,
Juergen


On 25.02.2016 22:38, EXT Paul Kyzivat wrote:
> On 2/24/16 7:24 PM, Christian Groves wrote:
>> Hello Juergen and Paul,
>>
>> Please see at end.
>>
>> Regards, Christian
>>
>> On 24/02/2016 8:26 AM, Paul Kyzivat wrote:
>>> ..snip..
>>>>
>>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote:
>>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote:
>>>>>> Hi Paul, Christian, Flemming, Bo,
>>>>>>
>>>>>> Have just submitted version 08 of
>>>>>> draft-ietf-mmusic-data-channel-sdpneg.
>>>>>> The changes compared to version 07 are essentially as follows.
>>>>>>
>>>>>> *   Two new paragraphs in section 5.1.2.1 (dcsa Attribute)
>>>>>> regarding the
>>>>>> relationship of subprotocols and their attributes.
>>>>>> *   Two new SDP offer/answer considerations in section 5.2.5 (Various
>>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown
>>>>>> subprotocol attributes or known subprotocol attributes, whose data
>>>>>> channel transport specific semantic is not known.
>>>>>> *   A new paragraph in section 8.1 (IANA Considerations / Subprotocol
>>>>>> Identifiers) related to cases, where a subprotocol is defined for data
>>>>>> channel and Websocket transport.
>>>>>>
>>>>>> These changes should address the points discussed in this email
>>>>>> thread.
>>>>>
>>>>> This is an improvement. But I think things could still be made clearer.
>>>>>
>>>>> Consider the following addition to 5.1.2.1:
>>>>>
>>>>>    It is assumed that in general the usages of subprotocol related
>>>>> media
>>>>>    level attributes are independent from the subprotocol's transport
>>>>>    protocol.  Such transport protocol independent subprotocol related
>>>>>    attributes are used in the same way as defined in the original
>>>>>    subprotocol specification, also if the subprotocol is transported
>>>>>    over a data channel and if the attribute is correspondingly embedded
>>>>>    in a "a=dcsa" attribute.
>>>>>
>>>>>    There may be cases, where the usage of a subprotocol related media
>>>>>    level attribute depends on the subprotocol's transport protocol.  In
>>>>>    such cases the subprotocol related usage of the attribute is
>>>>> expected
>>>>>    to be described for the data channel transport.  A data channel
>>>>>    specific usage of a subprotocol attribute is expected to be
>>>>> specified
>>>>>    in the same document, which registers the subprotocol's identifier
>>>>>    for data channel usage as described in Section 8.1.
>>>>>
>>>>> This text makes sense when there is a clear distinction between
>>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved there
>>>>> is no such clear distinction in many cases, such as RTP over UDP or
>>>>> TCP, etc. Those are combined into a single protocol value. While that
>>>>> can usually be parsed apart at slashes, there isn't good terminology
>>>>> for it.
>>>>>
>>>>> My point is that when I read the above, I don't know how it applies
>>>>> to, say, RTP attributes. Or does it only apply for attributes that are
>>>>> clearly defined for a *sub*protocol?
>>>>>
>>>>> I think this is primarily that we lack well defined vocabulary for all
>>>>> of this. But I think it would be too much to expect this draft to
>>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it would be
>>>>> sufficient to give some concrete examples, even if they have to be
>>>>> hypothetical ones.
>>>>
>>>> [Juergen] Agree that it would be helpful to have more precise
>>>> definitions of the differences of the terms protocol and subprotocol,
>>>> especially when those terms are used outside the scope of data channels
>>>> (or Websockets). When only focusing on data channels the notion of a
>>>> "subprotocol" seems to be clearer - at least
>>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket
>>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" parameter.
>>>> (But draft-ietf-rtcweb-data-channel does not define what a data
>>>> channel's "subprotocol" is.) So far the sdpneg draft relatively
>>>> informally starts using the term "subprotocol" in the introduction and
>>>> there refers to Websocket "subprotocols". Perhaps we should add the term
>>>> "subprotocol" to the list of used terminology in section 3.
>>>>
>>>> The sdpneg document, together with the data channel subprotocol specific
>>>> document (which defines the value of the a=dcmap attribute's
>>>> "subprotocol" parameter), should certainly give clear guidance on how to
>>>> interpret SDP offers or answers like e.g.:
>>>>
>>>>       m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
>>>>       c=IN IP4 10.10.10.1
>>>>       a=max-message-size:100000
>>>>       a=sctp-port:5000
>>>>       ...
>>>>       a=dcmap:0 subprotocol="MSRP"
>>>>       a=dcsa:0 accept-types:message/cpim text/plain
>>>>       a=dcsa:0 framerate:...
>>>>       a=dcsa:0 lang:...
>>>>
>>>> An implementation receiving such an offer would need to decide what to
>>>> do with the dcsa embedded framerate and lang attributes. Or, someone
>>>> implementing MSRP over data channel based services may need to decide
>>>> whether or not to use these attributes, and if yes, how.
>>>> (I am using these two attributes just as hypothetical examples - don't
>>>> want to suggest that those may indeed be used for MSRP over data channel
>>>> transport).
>>>>
>>>> The msrp-usage-data-channel document doesn't mention these two
>>>> attributes. When looking at the IANA SDP attribute registry tables, I
>>>> would find both attributes specified in RFC 4566. There, "framerate" is
>>>> explicitly said to be defined only "for video media". Just to be sure I
>>>> could additionally have a look at the MSRP specifying documents, RFC
>>>> 4975 and RFC 4976, but there would not find any text at all related to
>>>> "framerate". So this case seems pretty clear and I would therefore
>>>> conclude that the "framerate" attribute should not be used for MSRP, and
>>>> that a receiver of such an offer or answer should ignore it.
>>>>
>>>> When looking at the definition of the "lang" attribute in RFC 4566 I
>>>> would not see any explicit hint of what protocols this attribute might
>>>> be used with, especially if "lang" could be used when negotiating an
>>>> MSRP session. When then looking at RFC 4975 I would indeed find "lang" -
>>>> but not as SDP attribute, rather as XML tag parameter within an example
>>>> MSRP message payload. Thus, the case of the "lang" attribute might not
>>>> be as unambiguous as the one with the "framerate" attribute, but here
>>>> too I think the typical choice would be to ignore that attribute when
>>>> receiving such an offer or answer.
>>>> It seems to me that the two new "ignore" rules in section 5.2.5 of
>>>> sdpneg-08 may also be applied in these cases.
>>>>
>>>> Admittedly, these examples may seem a bit far-fetched, but would those
>>>> go into the direction you had in mind?
>>>
>>> Yes. Note that using examples is just me grasping at straws, since a
>>> real solution looks like to big a problem for this draft to tackle by
>>> itself. I am entirely open to other ideas for how to deal with this.
>> [CNG] I don't see what the example buys? I don't see that the behaviour
>> is any different between using additional attributes in the datachannel
>> vs. the non data channel case. E.g. for
>>
>>      c=IN IP4 10.10.10.1
>>      m=message 7394 TCP/MSRP *
>>      a=accept-types:message/cpim text/plain text/html
>>      a=lang:....
>>      a=framerate:...
>> The ignore behaviour would be the same.
>> In the above example the attributes are scoped by the m= line. In the
>> data channel case the attributes are scoped by the relevant a=dcmap: line.
>
> My concern is that SDP has no notion of subprotocol, even though in practice it shows up lots of 
> places. It only has a notion of the protocol field in the m-line. Beyond that a *convention* has 
> developed to denote a layering within the protocol through use of "/". AFAIK this isn't formally 
> written down anywhere.
>
> So, in principle we could define an RTP sub-protocol for use over a data channel. And then we 
> could talk about using the attributes that apply to RTP in dcsa for a channel using RTP. But note 
> there is no formal definition of the *protocol*s where RTP attributes are relevant.
>
> A lot of the very old stuff was just sloppy. To be fair, it was probably good enough for the cases 
> in front of them at the time, and they weren't yet in a position to foresee how things would 
> evolve. It is just another example of how old stuff rots and has to be refreshed from time to time.
>
> But I don't think *this* draft is the place to fix it. So, in lieu of doing that I'm just looking 
> for some way to clarify things.
>
>     Thanks,
>     Paul
>