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

[Christer Holmberg <[e-mail]>]

The pull request:

https://github.com/cdh4u/draft-datachannel-t140/pull/27

Regards,

Christer

On 09/09/2019, 0.38, "Gunnar Hellström" <[e-mail]> wrote:

    Hi,
    
    I am fine with all your answers, and I am sure you can propose some good 
    wording about the lack of support in the current W3C API.
    
    Regards
    
    Gunnar
    
    Den 2019-09-08 kl. 17:13, skrev Christer Holmberg:
    > Hi,
    >
    > (I am currently in US on a business trip, which is the reason it may take a while for me to reply)
    >
    >> 1. I can accept to not use the direction attributes on session level since you think it is messy, and I
    >> think it is right to specify that it is not used, as now last in section 3.2.3.
    >>
    >> 2. I can accept to mention that the o/a procedures are based on RFC 3264 , but I think the first
    >> mentioning of RFC 3264 in section 3.2.3 first paragraph is too strong and should be deleted. The
    >> mentioning of RFC 3264 in the third paragraph can be kept and would be sufficient.
    > Ok. I can remove the mentioning in the 1st paragraph, as you suggest below.
    >
    >> 3. I think the second note in section 3.2.3 is not needed. Readers surely understand that the dcsa attribute
    >> only apply to the data channel it is included in.
    > Ok. I can remove it.
    >
    > If someone things it needs to be mentioned, perhaps a generic note can be added to section 3.2 instead.
    >
    >> 4. Since there seems not to be any way to convey the specified dcsa attributes fmtp, hlang-send, hlang-recv and
    >> the directions through the currently specified W3C API, I suggest that a warning about this condition is inserted
    >> in section 3.2 in a way so that we do not get a strict dependency on the W3C document. An initial proposal can
    >> be: "NOTE: In order for the dcsa attributes to be useful in an application, the application needs to have means
    >> for setting and interrogating them."
    > I think readers surely understand that :)
    >
    > Instead, I'd suggest to add a note specifically mentioning that the current version of the W3C API does not support it.
    >
    >> 5. In 3.2.1, first paragraph, about fmtp, it is said that 'fmtp' can be used to set 'cps'. By the end it says "The 'format'
    >> attribute parameter is not used with T.140 data channels, and MUST be set to "-".  Do you think it is clear enough that
    >> this MUST is only valid when an 'fmtp' attribute is used. If you don't, then that should be explicitly stated.
    > I will clarify it.
    >
    > Regards,
    >
    > Christer
    >
    >
    >
    > If you accept 1,2,3 above, section 3.2.3 could be modified to:
    > "
    > 3.2.3.  Real-time Text Direction
    >
    >     'dcsa' attributes can contain the SDP 'sendonly', 'recvonly',
    >     'sendrecv' and 'inactive' attributes [RFC4566] to negotite the
    >     direction in which text can be transmitted in a real-time text
    >     conversation.
    >
    >     NOTE: A WebRTC data channel is always bi-directional.  The usage of
    >     the 'dcsa' attribute only affects the direction in which
    >     implementations are allowed to transmit text on a T.140 data channel.
    >
    >     The offer/answer rules for the direction attributes are based on the
    >     rules for unicast streams defined in [RFC3264], as described below.
    >     Note that the rules only apply to the direction attributes.
    >
    >     Session level direction attributes [RFC4566] have no impact on a
    >     T.140 data channel.  An offerer and answerer MUST mark the direction
    >     of the text by sending a direction attribute inside aEUR~dcsa-
    >     attribute.
    > "
    > Regards
    > Gunnar
    > Den 2019-09-07 kl. 07:24, skrev Christer Holmberg:
    > 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
    >
    >
    > _______________________________________________
    > mmusic mailing list
    > mailto:[e-mail]
    > https://www.ietf.org/mailman/listinfo/mmusic
    >
    > _______________________________________________
    > mmusic mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/mmusic
    
    -- 
    -----------------------------------------
    Gunnar Hellström
    Omnitor
    [e-mail]
    [phone]