Re: [MMUSIC] Draft new version: T140-data-channel -02 - Use direction attributes on dcsa level

[Christer Holmberg <[e-mail]>]

Hi,

...

>> Section 9.2 of raft-ietf-mmusic-sctp-sdp (that defines the generic O/A procedures for negotiating SCTP associations) says:
>>
>> "9.2.  SDP sendrecv/sendonly/recvonly/inactive Attribute
>>
>>   This specification does not define semantics for the SDP direction
>>   attributes [RFC4566].  Unless semantics of these attributes for an
>>   SCTP association usage have been defined, SDP direction attributes
>>   MUST be ignored if present."
>
> That contradicts sdpneg 5.2, saying:
>"
>5.2.  SDP DCSA Attribute
>
>   In the SDP media description, each data channel declaration MAY also
>   be followed by other media level SDP attributes, which are either
>   specifically defined for or applied to the subprotocol in use.
>"
>
> We are discussing a general media level attribute, which we also have specified the use of.  So it is good for both cases mentioned in the last line. 

As far as I understand, the text talks about including attributes in the dcsa attribute, and such attribute could be a generic attribute applies to the data channel, or an attribute defined for the data channel. But, in both cases they are included in the dcsa attribute.

>> draft-ietf-rtcweb-data-channel defines such SCTP usage (the RTCWEB data channel), and draft-ietf-mmusic-data-channel-sdpneg 
>> defines the O/A procedures for negotiating such data channels.
>>
>> *Neither* of those drafts defines semantics for the SDP direction attributes (please correct me if I'm wrong).
>>
>> Therefore, I don't think we can then in the T.140 data channel draft can define such semantics for session/media level direction attributes.
>
>   The ambition when specifying sdpneg would naturally 
>   be to make life as simple as possible for authors of new data channel 
>   specifications so that already existing general sdp attributes can be 
>   reused without registration. The idea seems to be that a dcmap and its 
>   dcsa declarations together shall be treated similar to earlier media 
>   declarations for single media.
>>  
>> The purpose of dcsa is to apply attributes to a specific data channel.
>>  
>>>   If you do not like the idea of a session level attribute influencing the 
>>>   data channel, I think you need to write an explanation that limits this 
>>>   interpretation of sdpneg and RFC4566bis.
>>  
>> I think the text I copy/pasted above provide such explanation: the SCTP association usage needs to define the semantics 
>> of the direction attributes, and the draft defining the RTCWEB data channel association usage do not define such semantics.
>>
>> So, it is not only about what I like and don't like - I don't think it's permitted :)
>
> If it is not permitted, we should discuss with the authors of draft-ietf-mmusic-msrp-usage-data-channel-13
>
> In https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-13#section-5.1.1.2.  Use of the 
> dcsa Attribute, it is said:
> ...
> An offerer and answerer MAY include a dcsa attribute for the
> following MSRP-specific SDP attributes, following the procedures
>  defined for each attributes:
>
>   o  defined in [https://tools.ietf.org/html/rfc4975]: "accept-types", "accept-wrapped-types" and
>      "max-size"
>
>   o  defined in [https://tools.ietf.org/html/rfc4566]: "sendonly", "recvonly", "inactive" and
>      "sendrecv"
>
>-----------------------------------------
> If it is not permitted, the last bullet point would not be allowed. 

Why not? That text is also about including attributes in a dcsa attribute.

Regards,

Christer