Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

[Christer Holmberg <[e-mail]>]

Hi Bo,

Thank You for the review! I will reply inline. In some cases I will refer the question to Gunnar.
 
>1) In section 1, note 1, with “WebRTC term”, do you mean that “T.140 data channel” is introduced in WebRTC specifications? Or should it be “This T.140 data channel term in WebRTC context…”? >If not, in what way is it a “WebRTC term”, which I interpret as something belonging to or being originated from WebRTC?
>
>2) In the same note 1, suggest to change “actually synonym to” to “technically equivalent to” or “technically similar to”. If you think 
>that would not be appropriate, please elaborate on in what way it is synonym.

ITU-T T.140 talks about a "data channel", but my understanding is that it also covers e.g., RTP transport of T.140.

I suggest to remove the note, because I think it could cause confusion.

---

>3) In section 4.2.1, it says that “If the 'fmtp' attribute is not included, it indicates that no maximum character transmission rate is indicated.  It does not mean that the default value of 30 applies”; >why is this deviation from RFC 4103 chosen? Does it introduce a risk for interoperability problems with systems that also doesn’t use fmtp but interprets it as maximum 30 cps?

Gunnar?

---

>4) In section 4.2.3.1.1, for the ‘inactive’ case, it is unclear to me in which cases a t140 data channel would be opened but not used. Why open the channel in the first place when a new SDP O/A is >anyway needed to change ‘inactive’ to something else? I’m however OK to keep it for completeness and it shouldn’t do any harm if kept, but a clarification would be helpful.

One may want to create a data channel for later use, and/or perhaps some pre-condition mechanism is used where bearers etc need to be established before text can be sent.

I don't think we normally clarify usage of 'inactive' in for other media types either.

---

>5) In section 5.5, in the note, it says ‘…with limitations in real-time performance and presentation style’; I think it would be helpful to briefly elaborate on what type of limitations would be >expected and why.

I think it is explained in the other text of the section. For example, using a single data channel without any protocol extensions would not allow to separate the sources etc.

---

>6) In section 6, bullet “If the gateway detects or suspects loss of data on the RTP stream…”; shouldn’t it await possible redundancy first and missing text marker is inserted only when the used >redundancy is not capable to repair the loss?

Gunnar?

---

>7) In section 6, bullet “If the gateway detects that the T.140 data channel has failed”; what about if the RTP stream has failed and was reestablished? Shouldn’t missing text markers be inserted >by the gateway then too?

Gunnar?

---

>8) In section 7, you mention “subprotocol”; do you mean the “dcmap” line subprotocol parameter?

Yes. 

If you want, I could add the following sentence:

"The subprotocol is indicated using the SDP 'dcmap' attribute."

---

>9) In section 7, the “…MUST specify the modality for that subprotocol…” seems like a general update to 8374 that is not specific or exclusive to T.140? I’m not convinced making such statement is >within the scope of this document.

The Section defines a general update to RFC 8373. It is not exclusive to T.140.

Yes, it's done within the t140-data-channel draft, but I don't think we would need a separate draft just for that update.

---

>10) In section 8, you reference draft-ietf-rtcweb-data-channel and draft-ietf-mmusic-data-channel-sdpneg; are there any additional T.140-specific considerations, e.g. related to T.140 use of ->sdpneg? If not, it could be helpful to say so.

Regarding data channels (1st paragraph), there is a sentence saying: "As data channels are always encrypted by design, the T.140 data channels will also be encrypted.".

Regarding sdpneg (2nd paragraph), I could add: "There are no additional T.140 data channel specific security considerations."

---

>11) In section 9.2, 9.3, and 9.4, please change all occurrences of “MMUSIC Chairs” to “IESG” and “[e-mail]” to “[e-mail]”, since IESG is expected to persist longer than any >individual WG.

Will fix as suggested.

---

>12) In section 11.1, in the [T140ad1] reference, is “aEUR” really part of the name? The name I find listed on the ITU-T web is “ITU-T T.140 (1998) Add. 1 (02/2000)”, and the title in the document >itself seems to be “Protocol for multimedia application text conversation; Addendum 1”.

Interesting. There is no "aEUR" in the XML file, so this seems to be something created by XML2RFC.

The intended title is: 

	Recommendation ITU-T.140 – Addendum 1  (02/2000), "Protocol for multimedia application text conversation"

I will fix it.

---

I will address the editorial comments/nits in a seprate reply.

Regards,

Christer