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

[Gunnar Hellström <[e-mail]>]

Hi,

You made interesting findings.

Please see inline

Den 2019-09-05 kl. 17:43, skrev Christer Holmberg:
> Hi,
>
>>>> The issue here was my view:
>>>>
>>>> I think that session level direction attributes should work on T.140 data channels where
>>>> no direction attribute is set on the dcsa(t140) level.
>>> My view is still that session level attributes do not impact data channels.
>>>
>>> Also, IF we would session level attributes to impact data channels, I think it should be specified
>>> on a more generic level. I don't think it is a good idea to define rules for specific attributes
>>> (the direction attributes) for a specific data channel (the T.140 data channels). People could then
>>> define other rules for other session level attributes and/or data channels, and it could become very messy.
>>     
>>     Right,
>>     
>>     The logic I explain below is for the general case, deducted from wording
>>     in sdpneg and RFC4566bis and would be valid for any attribute that has
>>     both session and media level use and for any data channel that is an
>>     implementation of a subprotocol already specified for traditional SDP
>>     negotiated streams.
> 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.

>
> 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


          5.1.1.2
          <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 [RFC4975  <https://tools.ietf.org/html/rfc4975>]: "accept-types", "accept-wrapped-types" and
       "max-size"

    o  defined in [RFC4566  <https://tools.ietf.org/html/rfc4566>]: "sendonly", "recvonly", "inactive" and
       "sendrecv"

-----------------------------------------
If it is not permitted, the last bullet point would not be allowed.
We should try to start a joint discussion about what is intended.

Regards

Gunnar


>
>
>>     Please see the logic below.
>>     
>>     I am not especially eager for the T.140 data channel to be possible to
>>     influence by session level attributes, but I see a risk that it gets
>>     messy for implementers when they find that for some media (audio, video
>>     ?), the session level attributes work, but not for others (T.140 data
>>     channel). Brian also asked for having equal influence for audio, video
>>     and real-time text.
>      
> I don't object to the fact that there could be use-cases where it could be useful.
>
> Regards,
>
> Christer
>
>
>
>
>      > Den 2019-09-05 kl. 03:20, skrev Christer Holmberg:
>      > Hi,
>      >
>      > What part sdpneg-23 do you think is trying to say that?
>      > It is in sdpneg-28 and RFC4566bis
>      > It requires some steps of logic that you may find weak:
>      > 1. sdpneg talks a lot about a "subprotocol" concept as if it exists also outside of the data channels. I assume that we can see "t140" as the subprotocol in our case, and that it was defined in RFC 4103 that is RTP transport of the t140 subprotocol and MIME media declared as text/t140.
>      > 2. In section 5.2 and 5.2.1, there is a lot of wording trying to describe how already specified general attributes that are used for the subprotocol on media level are automatically accepted with the same semantics when used on dsca(subprotocol) level. No IANA registration would be needed.
>      > It is for example section 5.2.1 "DCSA Syntax" in draft-ietf-mmusic-data-channel-sdpneg
>      > saying:
>      > "
>      > 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.
>      >
>      > "
>      > 3. RFC 4566bis, section 6.7 moves the direction attributes from session level to be applied to the media description if no direction attribute was declared on media level.
>      > 6.7.  Media Direction Attributes
>      >
>      >     At most one occurrence of recvonly, sendrecv, sendonly, or inactive
>      >     MAY appear at session level, and at most one MAY appear in each media
>      >     description.
>      >
>      >     If any one of these appears in a media description then it applies
>      >     for that media description.  If none appear in a media description
>      >     then the one from session level, if any, applies to that media
>      >     description.
>      > 4. Combining 2. and 3. results in the session level attributes are applied automatically on the dsca(subprotocol) level, e.g. the direction attributes on the t140 subprotocol.
>      >
>      > 5. This deduction also has the side effect that we do not need to IANA specify all usage of general SDP attributes which already were possible on the RTP/TEXT/t140 subprotocol, as long as it is used without change in semantics.
>      >
>      > Regards
>      > Gunnar
>      >
>      > Regards,
>      >
>      > Christer
>      >
>      > Lähettäjä: Gunnar Hellström mailto:[e-mail]
>      > Lähetetty: torstai 5. syyskuuta 2019 0.23
>      > Vastaanottaja: Christer Holmberg mailto:[e-mail]; mailto:[e-mail]
>      > Aihe: Re: [MMUSIC] Draft new version: T140-data-channel -02 - Use direction attributes on dcsa level
>      >
>      > (sorry, I forgot to change topic)
>      > Den 2019-09-04 kl. 23:20, skrev Gunnar Hellström:
>      > Hi,
>      > This is another topic for discussion:
>      > I think that session level direction attributes should work on T.140 data channels where no direction attribute is set on the dcsa(t140) level.
>      > RFC 4566bis seems to expect that. It is written as if it was defining that session level attributes if specified should govern in the whole session.
>      > And I think that the sdpneg-23 draft tries to say that attributes defined for general session and media level use should be allowed to work on DCSA level for any subprotocol without further specification or registration.
>      > Regards
>      >
>      > Gunnar
>      >
>      >
>      >
>      > It should be discussed what happens if there is a direction attribute on media level in the media declaration for the SCTP declaration.. Probably a similar statement as for session level is needed.
>      > Den 2019-09-04 kl. 23:03, skrev Gunnar Hellström:
>      > Hi,
>      > I have created a number of pull requests to the GitHub repository for  draft-holmberg-mmusic-t140-usage-data-channel-02
>      > Many are editorial. A few require discussion in the list.
>      >
>      > Regards
>      > Gunnar
>      >
>      > Den 2019-09-03 kl. 14:10, skrev Christer Holmberg:
>      > Hi,
>      >
>      > I have mereged the following PR:
>      >
>      > https://protect2.fireeye.com/url?k=bb2745e9-e7b548b5-bb270572-0cc47ad93d46-f9e326b54116c066&q=1&u=https://github.com/cdh4u/draft-datachannel-t140/pull/6
>      >
>      > …and submitted a new version (-02) of draft-holmberg-mmusic-t140-usage-data-channel.
>      >
>      > The main changes are:
>      >
>      > - IANA registry update for SDP attributes that can be included in dcsa attributes
>      > - Detailed procedures on usage of the direction attributes inside dcsa attributes
>      >
>      > Regards,
>      >
>      > Christer
>      >
>      >
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      > mailto:[e-mail]
>      > https://www.ietf.org/mailman/listinfo/mmusic
>      
>      --
>      -----------------------------------------
>      Gunnar Hellström
>      Omnitor
>      [e-mail]
>      [phone]
>      
>      
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]