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

[Paul Kyzivat <[e-mail]>]

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