Subject: [MMUSIC] Draft new version: T140-data-channel

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Sep 2019 12:10:19 +0000

Hi,

I have mereged the following PR:

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

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 4 Sep 2019 23:03:16 +0200

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.

This is one that requires discussion:

I suggest that RFC 3264 is deleted as reference for how the direction 
attributes 'sendonly' etc. RFC 4566 is already also used as reference 
for how to handle the direction attributes. This is in section 3.2.3

I think that RFC 3264 just adds confusion and a lot of detail for RTP 
use of the direction attributes that is irrelevant for the T.140 data 
channel case.

Regards

Gunnar

Den 2019-09-03 kl. 14:10, skrev Christer Holmberg:
> …and submitted a new version (-02) of 
> draft-holmberg-mmusic-t140-usage-data-channel.
>
> The main changes are:
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 4 Sep 2019 23:20:42 +0200

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.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 4 Sep 2019 23:23:11 +0200

(sorry, I forgot to change topic)

Den 2019-09-04 kl. 23:20, skrev Gunnar Hellström:
> 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.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Sep 2019 01:20:21 +0000

Hi,

What part sdpneg-23 do you think is trying to say that?

Regards,

Christer

Lähettäjä: Gunnar Hellström <[email-masked]>
Lähetetty: torstai 5. syyskuuta 2019 0.23
Vastaanottaja: Christer Holmberg <[email-masked]>; [email-masked]
Aihe: Re: [MMUSIC] Draft new version: T140-data-channel -02 - Use direction attributes on dcsa level

Hi,

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

Regards

Gunnar

https://github.com/cdh4u/draft-datachannel-t140/pull/6<https://protect2.fireeye.com/url?k=bb2745e9-e7b548b5-bb270572-0cc47ad93d46-f9e326b54116c066&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F6>

The main changes are:

Regards,

Christer

mmusic mailing list

[email-masked]<mailto:[email-masked]>

--

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288

mmusic mailing list

[email-masked]<mailto:[email-masked]>

mmusic mailing list

[email-masked]<mailto:[email-masked]>

--

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Sep 2019 05:04:50 +0000

Hi,

> I suggest that RFC 3264 is deleted as reference for how the direction attributes 'sendonly' etc. RFC 4566 is already also used as reference
> I think that RFC 3264 just adds confusion and a lot of detail for RTP use of the direction attributes that is irrelevant for the T.140 data channel case.

This can be split into two parts:

First, since we do mention "offer/answer" (as we define the o/a T.140 data channel procedures for the direction attributes), we DO at least need a reference to 3264 for terminology purpose.

Second, the draft DOES define the offer/answer procedures for the T.140 direction attributes, so from that perspective we do not need a reference the procedures in 3264. However, I DO think it is a good idea to indicate that the procedures are based on the procedures in 3264. It makes it more clear for implementers etc.

Regards,

Christer

 
https://protect2.fireeye.com/url?k=b96a065f-e5e3dc4f-b96a46c4-0cc47ad93e2a-665164b51729ecbf&q=1&u=https://github.com/cdh4u/draft-datachannel-t140/pull/6

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:[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
mailto:[email-masked]
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 5 Sep 2019 09:31:13 +0200

Hi,

The issue here was my view:

> 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 <[email-masked]>
> *Lähetetty:* torstai 5. syyskuuta 2019 0.23
> *Vastaanottaja:* Christer Holmberg <[email-masked]>; 
> [email-masked]
> *Aihe:* Re: [MMUSIC] Draft new version: T140-data-channel -02 - Use 
> direction attributes on dcsa level
>
>     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.
>
>     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.
>
>         I have created a number of pull requests to the GitHub
>         repository for draft-holmberg-mmusic-t140-usage-data-channel-02
>
>             <https://protect2.fireeye.com/url?k=bb2745e9-e7b548b5-bb270572-0cc47ad93d46-f9e326b54116c066&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F6>
>
>             [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>         +46 708 204 288
>
>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
> [email-masked]  <mailto:[email-masked]>
> +46 708 204 288
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Sep 2019 08:55:57 +0000

Hi,

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

But, I'd also like to hear what others think :)

Regards.

Christer

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

   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:[email-masked] 
Lähetetty: torstai 5. syyskuuta 2019 0.23
Vastaanottaja: Christer Holmberg mailto:[email-masked]; mailto:[email-masked]
Aihe: Re: [MMUSIC] Draft new version: T140-data-channel -02 - Use direction attributes on dcsa level

Gunnar

 
Regards
Gunnar

 
https://protect2.fireeye.com/url?k=bb2745e9-e7b548b5-bb270572-0cc47ad93d46-f9e326b54116c066&q=1&u=https://github.com/cdh4u/draft-datachannel-t140/pull/6

The main changes are:

Regards,
 
Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 5 Sep 2019 14:28:32 +0200

Hi,

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

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

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.

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.

> But, I'd also like to hear what others think :)
Yes.

Regards

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 5 Sep 2019 17:22:50 +0200

Hi,

> Second, the draft DOES define the offer/answer procedures for the T.140 direction attributes, so from that perspective we do not need a reference the procedures in 3264. However, I DO think it is a…

Yes, "the procedures are based on the procedures in 3264" sounds 
suitable. The wording about the direction attributes in RFC 3264 is full 
of wording about ports and payload types etc. In many cases, but not 
all, it mentions what is only valid for RTP transport, so it would not 
be right to say that it is the RFC 3264 procedures that are used. But OK 
for referencing RFC 3264 in a mild way. I hope you can propose wording.

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Sep 2019 15:43:41 +0000

Hi,

>> 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,
>    
>    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."

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 
  
The purpose of dcsa is to apply attributes to a specific data channel.
  
>    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 :)

>    channel). Brian also asked for having equal influence for audio, video 
    
I don't object to the fact that there could be use-cases where it could be useful.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 5 Sep 2019 22:57:34 +0200

Hi,

You made interesting findings.

Please see inline

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

> 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

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 6 Sep 2019 23:12:03 +0200

Hi,

I realized that most use cases of the T.140 data channel would likely be 
through the w3c RTCPeerConnection API, where I cannot find any way to 
set or interrogate such details as the direction, and the human language.

With this finding, I see less value of specifying support for the 
direction attribute, even if sdpneg seems to support it. The language 
attributes are a tougher sacrifice.

Please check my conclusion.

Gunnar

Den 2019-09-05 kl. 22:57, skrev Gunnar Hellström:
>>      > Lähettäjä: Gunnar Hellströmmailto:[email-masked]
>>      > Vastaanottaja: Christer Holmbergmailto:[email-masked];mailto:[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 7 Sep 2019 05:16:53 +0000

Hi,
>I realized that most use cases of the T.140 data channel would likely be through the w3c RTCPeerConnection API, where I cannot find any way to >set or interrogate such details as the direction, and the human language.
>
>With this finding, I see less value of specifying support for the direction attribute, even if sdpneg seems to support it. 
>The language attributes are a tougher sacrifice.

If we think something in general could be useful I don't think we should remove it just because the current W3C API doesn't support it.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 7 Sep 2019 05:24:52 +0000

Hi,

...

> 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.
>>
>> 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.
>>
> 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:
> ...
>   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"
>

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

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 8 Sep 2019 08:57:19 +0200

Hi,

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.

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.

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

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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 8 Sep 2019 15:13:25 +0000

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

...

 

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 9 Sep 2019 09:38:06 +0200

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Sep 2019 12:19:43 +0000

The pull request:

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

Regards,

Christer

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

    Hi,

    Regards
    
    Gunnar