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

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

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]