Subject: [MMUSIC] Murray Kucherawy's Yes on draft-ietf-mmusic-t140-usage-data-channel-12: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Fri, 27 Mar 2020 22:55:13 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-mmusic-t140-usage-data-channel-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.2.3.3:

Why might an implementer choose to deviate from the RECOMMENDED?

Section 5.5:

“This would allow the receiver to present real-time text from different sources separated.”

Did you mean “separately”?

“The procedures of such mechanism is outside the scope of this document.”

s/is/are/

Sections 9.2, 9.3, 9.4:

Please give the name of the registry being updated.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Mar 2020 17:01:38 +0000

Hi Murray,

Thank You for the comments! Please see inline.

Perhaps the implementation has indicated that it is only able to send text, because it is not able to process received text. In that case it may not want the remote peer to assume that it can send text.

However, in most use-cases the text will be bi-directional, hence the recommendation.

---

>    Did you mean “separately”?

Yes. I will fix that.

>    “The procedures of such mechanism is outside the scope of this document.”
  
Will fix.

---

>    Please give the name of the registry being updated.

I could add "att-field" subregistry.

E.g.,

"The usage level "dcsa(t140)" is added to the IANA registration ("att-field" subregistry) of the SDP 'fmtp' attribute as follows:"

Regards,

Christer

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 28 Mar 2020 15:10:14 -0700

On Sat, Mar 28, 2020 at 10:01 AM Christer Holmberg <
[email-masked]> wrote:

> Perhaps the implementation has indicated that it is only able to send
> text, because it is not able to process received text. In that case it may
> not want the remote peer to assume that it can send text.
>

Not a blocker for me, but a sentence or two to that effect might head off
questions from others.

> "The usage level "dcsa(t140)" is added to the IANA registration
> ("att-field" subregistry) of the SDP 'fmtp' attribute as follows:"
>

I suggest:

The usage level "dcsa(t140)" is added to the registration of the "fmtp"
attribute in the Session Description Protocol (SDP) Parameters registry.

-MSK

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Mar 2020 23:10:15 +0000

Hi Murray,

>>>    Section https://protect2.fireeye.com/v1/url?k=38c17220-644b50c9-38c132bb-0cc47ad93e2e-7fdb3f85245ba518&q=1&e=cf19a90a-ceba-40d9-b9ea-917e606b67b1&u=http://4.2.3.3/:
>>>    
> Not a blocker for me, but a sentence or two to that effect might head off questions from others.

I could add ", as the traffic is expected to be bi-directional in most use-cases".

---

> The usage level "dcsa(t140)" is added to the registration of the "fmtp" attribute in the Session Description Protocol (SDP) Parameters registry.

I will fix as suggested.

Regards,

Christer

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 28 Mar 2020 16:17:53 -0700

> [...]

Outstanding!  Please hold off posting a new version until it's done the
April 9th telechat as I don't know what other changes my colleagues might
seek in the interim.

-MSK

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 29 Mar 2020 07:12:05 +0200

Hi

>>> However, in most use-cases the text will be bi-directional, hence the recommendation.

The question was related to this paragraph in 4.2.3.3

"If the answerer has not marked the direction of a T.140 data channel
    in accordance with the procedures above, it is RECOMMENDED that the
    offerer does not process that as an error situation, but rather
    assume that the answerer might both send and receive T.140 data on
    the data channel."

The offerer included a directional attribute and the answerer did not.

That answer is against the offer/answer procedure for the directional 
attribute described in 4.2.3.2.

There was a discussion indicating that it may be complicated or 
impossible to send a DSCA attribute with current WebRTC APIs and browsers.

The offerer does not know if the answerer has such limitations. The 
DCMAP attribute has corresponding primitives in the WebRTC, so the 
answerer might be able to handle the basic interaction to accept the 
session, but not the details in the DCSA attributes.

The statement   "it is RECOMMENDED that the offerer does not process 
that as an error situation" is a precaution against such interop problems.

Regards

Gunnar

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 

+ + + + + + + + + + + + + +

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 31 Mar 2020 15:32:45 +0000

Hi Murray,

>>    Why might an implementer choose to deviate from the RECOMMENDED?

...

> That answer is against the offer/answer procedure for the directional attribute described in 4.2.3.2.
> There was a discussion indicating that it may be complicated or impossible to send a DSCA attribute with current WebRTC APIs and browsers. 
> The offerer does not know if the answerer has such limitations. The DCMAP attribute has corresponding primitives in the WebRTC, so the answerer
> might be able to handle the basic interaction to accept the session, but not the details in the DCSA attributes. 
>
>The statement   "it is RECOMMENDED that the offerer does not process that as an error situation" is a precaution against such interop problems.

Are you ok with the explanation?

Hopefullly future versions of the WebRTC API will allow the setting of the attributes, which means the issue will eventually go away.

Regards,

Christer

---

    Sections 9.2, 9.3, 9.4:

E.g.,

Regards,

Christer

mailto:[email-masked]

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 31 Mar 2020 10:05:05 -0700

On Tue, Mar 31, 2020 at 8:32 AM Christer Holmberg <
[email-masked]> wrote:

> >[...]
> >The statement   "it is RECOMMENDED that the offerer does not process that
> as an error situation" is a precaution against such interop problems.
>
> Hopefullly future versions of the WebRTC API will allow the setting of the
> attributes, which means the issue will eventually go away.
>

I am, and thanks for checking back with me.  I leave it to you to decide
whether any of those details should make their way into the document.

-MSK