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

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Nov 2019 13:30:51 +0000

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 “[email-masked]” to “[email-masked]”, 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

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 5 Nov 2019 22:38:05 +0000

Hi Christer, Bo and all,

Please see my answers and comments inline,

Den 2019-11-05 kl. 14:30, skrev Christer Holmberg:

Hi Bo,

[GH] I agree, the note is not important, but just a good link between the general presentation level of ITU-T T.140 with its expressed need for a transport method, and the transport method provided by the new specified T.140 data channel.

---

Gunnar?

[GH] I don't know why this deviation was chosen. But I have not commented it. You are right that it may introduce an increased risk for interoperability problems. But RFC 4103 has a precaution. In chapter 6, where the cps is introduced, it is said:
"

   receivers of text/t140 MUST be designed so they can handle temporary
   reception of characters at a higher rate than this parameter
   specifies.  As a result malfunction due to buffer overflow is avoided
   for text conversation with human input."

(the reason for this note is for backward compatibility with RFC 2793, the obsoleted predecessor of RFC 4103, so it is not exactly our case, but still valid.)

We have discussed the risk that implementations may not implement setting or reading the dcsa attributes because of the complexity to do so alongside with the WebRTC API. That situation may cause a situation where a sent cps parameter is not obeyed. So the case is quite similar to the case in RFC 4103, and applications would be required to prepare for handling temporary reception at high rates.

The intention of T.140 is to handle real-time text conversation between humans. Huge cut and paste chunks of text cannot be required to be handled rapidly. The highest speed human interaction would be with speech-to-text applications. A very rapid speaker may produce 200 words per minute. That is 17 characters per second. The speech-to-text applications often makes corrections by long backspaces and resendings. That may add 10 characters per second in the total. That results in a practical need of up to 27 characters per second for one stream.

This calculation shows that for two-party calls, it would not hurt to use the same convention regarding cps default as RFC 4103 (30).

For centralized conference solutions with just one data channel from the conference server discussed in section 5.5, the need would be a multiple of that rate (27) corresponding to the number of simultaneous text senders. In well managed conferences this multiple is very close to one.

The figures above are extremes. Currently most use of RTT is typing at maximum speeds of about 7 characters per second.

Leaving the default to unrestricted might attract some misuse by implementations or users trying to use the T.140 data channel for data transmission of data totally different from the intended real-time text.

Conclusion after all this discussion:

Neither leaving the default to unlimited, nor changing to a default of 30 cps as in RFC 4103 seems very critical. Any solution will do.

---

[GH] I agree. Also, since 4.2.3.2 Modify Text Direction is short, referencing back to 4.2.3.1.1 and 4.2.3.1.2, I think 4.2.3.1.1 should contain 'inactive'.

---

[GH] I think we can offer a bit more text at the end of the note to clarify. How about this:

"T.140 shows two examples of presentation layout for real-time text, one being column oriented, with one column per participant, another being arranged in one column with labels identifying the beginning of text from each participant and text from a number of participants received and placed in places corresponding to these different participants. With a conference mixer using one text stream and not applying any presentation protocol extension would only be able to produce a string for presentation in one column, including a source label in the beginning of text from one participant and only show text in real time from one participant at a time, shifting real-time presented participant at suitable points in the text stream. (end of phrase, end of sentence, line separator, long delay etc.). This presentation style may not be preferred by the user and it may cause delay before presentation of text from other than the currently presenting participant."

Pew, maybe too long and detailed....

---

Gunnar?

[GH]The intention was that it would mean "after using possibly received redundant data".   You could interpret "loss of data" to mean that (instead of "loss of packets"), but let me try an improvement: "If the gateway detects or suspects loss of data on the RTP stream, after use of possibly received redundant data, …"

---

Gunnar?

[GH] Good point, but that case may be thought of as included in point 6 above. It is much more important to have the points about the failure of the T.140 data channel clearly pointed out, because I am afraid that there is a common misconception that reliable WebRTC channels are reliable and always deliver data.

---

Yes.

---

---

---

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

Will fix as suggested.

---

The intended title is:

I will fix it.

[GH] I chased a number of such occurrences earlier. I think it was because your editor inserted an unusual slanting quotation mark. Note that there is also a double quotation mark on the third line of the same reference.

---

Regards,

Christer

Regards

Gunnar

--

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

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

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 5 Nov 2019 23:44:44 +0100

Hi Christer, Bo and all,

> I suggest to remove the note, because I think it could cause confusion.
[GH] I agree, the note is not important, but just a good link between 
the general presentation level of ITU-T T.140 with its expressed need 
for a transport method, and the transport method provided by the new 
specified T.140 data channel.
>> 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 ap…
[GH] I don't know why this deviation was chosen. But I have not 
commented it. You are right that it may introduce an increased risk for 
interoperability problems. But RFC 4103 has a precaution. In chapter 6, 
where the cps is introduced, it is said:
"

(the reason for this note is for backward compatibility with RFC 2793, 
the obsoleted predecessor of RFC 4103, so it is not exactly our case, 
but still valid.)

We have discussed the risk that implementations may not implement 
setting or reading the dcsa attributes because of the complexity to do 
so alongside with the WebRTC API. That situation may cause a situation 
where a sent cps parameter is not obeyed. So the case is quite similar 
to the case in RFC 4103, and applications would be required to prepare 
for handling temporary reception at high rates.

The intention of T.140 is to handle real-time text conversation between 
humans. Huge cut and paste chunks of text cannot be required to be 
handled rapidly. The highest speed human interaction would be with 
speech-to-text applications. A very rapid speaker may produce 200 words 
per minute. That is 17 characters per second. The speech-to-text 
applications often makes corrections by long backspaces and resendings. 
That may add 10 characters per second in the total. That results in a 
practical need of up to 27 characters per second for one stream.

This calculation shows that for two-party calls, it would not hurt to 
use the same convention regarding cps default as RFC 4103 (30).

For centralized conference solutions with just one data channel from the 
conference server discussed in section 5.5, the need would be a multiple 
of that rate (27) corresponding to the number of simultaneous text 
senders. In well managed conferences this multiple is very close to one.

The figures above are extremes. Currently most use of RTT is typing at 
maximum speeds of about 7 characters per second.

Leaving the default to unrestricted might attract some misuse by 
implementations or users trying to use the T.140 data channel for data 
transmission of data totally different from the intended real-time text.

Neither leaving the default to unlimited, nor changing to a default of 
30 cps as in RFC 4103 seems very critical. Any solution will do.

> I don't think we normally clarify usage of 'inactive' in for other media types either.
[GH] I agree. Also, since 4.2.3.2 Modify Text Direction is short, 
referencing back to 4.2.3.1.1 and 4.2.3.1.2, I think 4.2.3.1.1 should 
contain 'inactive'.
> 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.

[GH] I think we can offer a bit more text at the end of the note to 
clarify. How about this:

"T.140 shows two examples of presentation layout for real-time text, one 
being column oriented, with one column per participant, another being 
arranged in one column with labels identifying the beginning of text 
from each participant and text from a number of participants received 
and placed in places corresponding to these different participants. With 
a conference mixer using one text stream and not applying any 
presentation protocol extension would only be able to produce a string 
for presentation in one column, including a source label in the 
beginning of text from one participant and only show text in real time 
from one participant at a time, shifting real-time presented participant 
at suitable points in the text stream. (end of phrase, end of sentence, 
line separator, long delay etc.). This presentation style may not be 
preferred by the user and it may cause delay before presentation of text 
from other than the currently presenting participant."

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

[GH]The intention was that it would mean "after using possibly received 
redundant data".   You could interpret "loss of data" to mean that 
(instead of "loss of packets"), but let me try an improvement: "If the 
gateway detects or suspects loss of data on the RTP stream, after use of 
possibly received redundant data, …"

>> 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 >…
[GH] Good point, but that case may be thought of as included in point 6 
above. It is much more important to have the points about the failure of 
the T.140 data channel clearly pointed out, because I am afraid that 
there is a common misconception that reliable WebRTC channels are 
reliable and always deliver data.
> 	Recommendation ITU-T.140 – Addendum 1  (02/2000), "Protocol for multimedia application text conversation"

[GH] I chased a number of such occurrences earlier. I think it was 
because your editor inserted an unusual slanting quotation mark. Note 
that there is also a double quotation mark on the third line of the same 
reference.

Regards

Gunnar

-- 

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Nov 2019 08:58:30 +0000

Hi,

---

Gunnar?

[Christer] I am pretty sure IESG would ask about this too, I suggest that we change the default to 30 cps.

---

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

[Christer] Or, could we simply remove the last sentence ("Conference mixers that...")? The 1st paragraph already says why separate channels are needed, and the note says that future extensions may allow usage of a single channel, so I think it is pretty clear that using a single channel without any such extensions would come with limitations.

---

Gunnar?

[Christer] What about?

"If the gateway detects or suspects loss of data on the RTP stream, and the lost data has not been retrieved using a redundancy mechanism, the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel."

---

The intended title is:

I will fix it.

[Christer] I will double check.

---

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 6 Nov 2019 15:16:19 +0000

Christer,
I agree with your proposals.

Regards
Gunnar

----------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 20 42 88
________________________________
Från: Christer Holmberg <[email-masked]>
Skickat: den 6 november 2019 09:58:30
Till: Gunnar Hellström <[email-masked]>; Bo Burman <bo.burman=[email-masked]>; mmusic ([email-masked]) <[email-masked]>
Kopia: [email-masked]' <[email-masked]>
Ämne: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Hi,

---

Gunnar?

---

---

Gunnar?

[Christer] What about?

---

The intended title is:

I will fix it.

---

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Nov 2019 16:29:33 +0000

Bo, are you ok with the proposals?

Regards,

Christer

________________________________
From: Gunnar Hellström <[email-masked]>
Sent: Wednesday, November 6, 2019 5:16 PM
To: Christer Holmberg <[email-masked]>; Bo Burman <bo.burman=[email-masked]>; mmusic ([email-masked]) <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: SV: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Christer,

Regards
Gunnar

Hi,

---

Gunnar?

---

---

Gunnar?

[Christer] What about?

---

The intended title is:

I will fix it.

---

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 6 Nov 2019 19:44:34 +0000

Hi,

Even if I accepted to delete the last sentence in section 5 on multi-party, I want to propose a solution that might better address the original issue 5.

So, this is a proposal for new wording of the last sentence in 5, as a solution on issue 5:

"Conference mixers that use a single T.140 data channel
   to transmit real-time text towards clients might however without any protocol extensions produce a limited functionality multi-party RTT presentation in one display area. Only one source at a time can be presented in real-time, but switch of source of text to display in real-time can be made automatically by the mixer and at suitable points in the text streams. Sources could be identified by inline text labels in IRC style. This presentation style does not meet all RTT requirements and if used, should be a temporary fallback method for conference-unaware clients."

This wording is a self sustained description on what is possible and would also match better the recently revived work on multi-party rtt.

Regards

Gunnar

Den 2019-11-06 kl. 17:29, skrev Christer Holmberg:
Bo, are you ok with the proposals?

Regards,

Christer

________________________________
From: Gunnar Hellström <[email-masked]><mailto:[email-masked]>
Sent: Wednesday, November 6, 2019 5:16 PM
To: Christer Holmberg <[email-masked]><mailto:[email-masked]>; Bo Burman <bo.burman=[email-masked]><mailto:bo.burman=[email-masked]>; mmusic ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>
Subject: SV: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Christer,

Regards
Gunnar

----------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 20 42 88
________________________________
Från: Christer Holmberg <[email-masked]><mailto:[email-masked]>
Skickat: den 6 november 2019 09:58:30
Till: Gunnar Hellström <[email-masked]><mailto:[email-masked]>; Bo Burman <bo.burman=[email-masked]><mailto:bo.burman=[email-masked]>; mmusic ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>
Ämne: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Hi,

---

Gunnar?

---

---

Gunnar?

[Christer] What about?

---

The intended title is:

I will fix it.

---

Regards,

Christer

--

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Nov 2019 20:38:06 +0000

Would'n these inline IRC style labels be considered protocol extensions?

Regards,

Christer

________________________________
From: Gunnar Hellström <[email-masked]>
Sent: Wednesday, November 6, 2019 9:44 PM
To: Christer Holmberg <[email-masked]>; Bo Burman <bo.burman=[email-masked]>; mmusic ([email-masked]) <[email-masked]>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Hi,

Regards

Gunnar

Regards,

Christer

Christer,

Regards
Gunnar

Hi,

---

Gunnar?

---

---

Gunnar?

[Christer] What about?

---

The intended title is:

I will fix it.

---

Regards,

Christer

--

Gunnar Hellström
Omnitor

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 6 Nov 2019 21:04:25 +0000

Den 2019-11-06 kl. 21:38, skrev Christer Holmberg:
Would'n these inline IRC style labels be considered protocol extensions?

No, in my view this would be done by mixer actions on the media stream, by inserting a line separator and an IRC style participant label in text format.

The receiver just presents it according to current T.140 text presentation rules.

It is similar to what a video conference mixer does when it composes a combined picture of a number of participants and code it as just one picture.

Regards,

Christer

Hi,

Regards

Gunnar

Regards,

Christer

Christer,

Regards
Gunnar

Hi,

---

Gunnar?

---

---

Gunnar?

[Christer] What about?

---

The intended title is:

I will fix it.

---

Regards,

Christer

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Nov 2019 10:00:00 +0000

Hi,

In the first paragraph we say that one needs to use separate data channels, so it sounds strange to then have a note saying that is not true. Also, the way you suggest the text makes it look like you are defining a mechanism for using a single channel.

Maybe something like this:

"The usage of a single T.140 data channel, without any protocol extensions, would require the conference server to only forward real-time text from one source at any given time, and e.g., include IRC style text labels in the real-time text in order for the receiver to separate real-time text from different sources. The procedures of such mechanism is outside the scope of this document."

Regards,

Christer

Hi,

Regards

Gunnar

Regards,

Christer

Christer,

Regards
Gunnar

Hi,

---

Gunnar?

---

---

Gunnar?

[Christer] What about?

---

The intended title is:

I will fix it.

---

Regards,

Christer

--

Gunnar Hellström
Omnitor

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 7 Nov 2019 10:27:59 +0000

Hi,

Den 2019-11-07 kl. 11:00, skrev Christer Holmberg:
Hi,

Yes, I realized the conflict and tried to avoid it by the words "limited functionality multi-party RTT presentation in one display area", and "This presentation style does not meet all RTT requirements".

But maybe that was not obvious. So, I accept your proposal below with some modifications

"The usage of a single T.140 data channel, without any protocol extensions, would require the conference server to only forward real-time text from one source at any given time, and e.g., include IRC style text labels in the real-time text in order for the receiver to separate real-time text from different sources. The procedures of such mechanism is outside the scope of this document."
Yes, quite good, I suggest a few modifications to:

"The usage of a single T.140 data channel, without any protocol extensions, would require the conference server to only forward real-time text from one source at any given time, and e.g., include IRC style text labels in the real-time text in order for the receiver to present real-time text from different sources separated. The procedures of such mechanisms cause functional limitations and are outside the scope of this document."

The changes are because 1) the receiver cannot make a true separation and e.g. present text from different sources in separated areas, therefore the change to "present" .... "separated". 2) A reminder that it causes functional limitations is needed and inserted in the last sentence. Or do we then fall back into Bo's original issue 5 asking for a better description of the functional limitations? I think it is obvious now that at least one limitation is that only one source at a time can be presented in real-time.

Regards

Gunnar

Regards,

Christer

Hi,

Regards

Gunnar

Regards,

Christer

Christer,

Regards
Gunnar

Hi,

---

Gunnar?

---

---

Gunnar?

[Christer] What about?

---

The intended title is:

I will fix it.

---

Regards,

Christer

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Nov 2019 13:06:26 +0000

Hi,

>> In the first paragraph we say that one needs to use separate data channels, so it sounds strange to then have a note saying that
>> is not true. Also, the way you suggest the text makes it look like you are defining a mechanism for using a single channel.
>
> Yes, I realized the conflict and tried to avoid it by the words "limited functionality multi-party RTT presentation in one display
> area", and "This presentation style does not meet all RTT requirements".  
>
>> "The usage of a single T.140 data channel, without any protocol extensions, would require the conference server to only forward
>>  real-time text from one source at any given time, and e.g., include IRC style text labels in the real-time text in order for the receiver
>>  to separate real-time text from different sources. The procedures of such mechanism is outside the scope of this document."
>
> "The usage of a single T.140 data channel, without any protocol extensions, would require the conference server to only forward
> real-time text from one source at any given time, and e.g., include IRC style text labels in the real-time text in order for the receiver
> to present real-time text from different sources separated. The procedures of such mechanisms cause functional limitations and are
> outside the scope of this document."

I am ok to replace 'separate' with 'present', but with the modification to the last sentence you would still have the question what those 'functional limitations' are,  and we would need to include additional text...

So, I suggest that we remove the text about functional limitations.

Regards,

Christer

From: Gunnar Hellström mailto:[email-masked]
Sent: Wednesday, November 6, 2019 9:44 PM
To: Christer Holmberg mailto:[email-masked]; Bo Burman mailto:bo.burman=[email-masked]; mmusic (mailto:[email-masked]) mailto:[email-masked]
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments 
 
Hi,

Regards

Gunnar

Regards,

Christer

From: Gunnar Hellström mailto:[email-masked]
Sent: Wednesday, November 6, 2019 5:16 PM
To: Christer Holmberg mailto:[email-masked]; Bo Burman mailto:bo.burman=[email-masked]; mmusic (mailto:[email-masked]) mailto:[email-masked]
Cc: 'mailto:[email-masked]' mailto:[email-masked]
Subject: SV: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments 
 
Christer,

Regards
Gunnar

----------------------------------------------------------------------
Gunnar Hellström
Omnitor
mailto:[email-masked]
+46 708 20 42 88

Från: Christer Holmberg mailto:[email-masked]
Skickat: den 6 november 2019 09:58:30
Till: Gunnar Hellström mailto:[email-masked]; Bo Burman mailto:bo.burman=[email-masked]; mmusic (mailto:[email-masked]) mailto:[email-masked]
Kopia: 'mailto:[email-masked]' mailto:[email-masked]
Ämne: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments 
 
Hi,

--- 

---

---

[Christer] What about?

The intended title is: 

I will fix it.

---

Regards,

Christer

-- 

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

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

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 7 Nov 2019 13:12:38 +0000

Hi,

Christer, I accept your proposal below. With the remaining text it 
should be apparent for all that the solution has limitations.

I hope also Bo thinks that the issues are solved now.

Regards

Gunnar

-- 

Gunnar Hellström
Omnitor

---

From: Bo Burman <[email-masked]>
Date: Thu, 7 Nov 2019 13:29:43 +0000

Yes

From: Christer Holmberg <christer.holmberg=[email-masked]> 
Sent: den 6 november 2019 17:30
To: Gunnar Hellström <[email-masked]>; Bo Burman <[email-masked]>; mmusic ([email-masked]) <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Regards,

Christer

  _____  

From: Gunnar Hellström <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, November 6, 2019 5:16 PM
To: Christer Holmberg <[email-masked] <mailto:[email-masked]> >; Bo Burman <bo.burman=[email-masked] <mailto:bo.burman=[email-masked]> >; mmusic ([email-masked] <mailto:[email-masked]> ) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked]' <[email-masked] <mailto:[email-masked]> >
Subject: SV: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments 

Christer,

Regards
Gunnar

----------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked] <mailto:[email-masked]> 
+46 708 20 42 88

  _____  

Från: Christer Holmberg <[email-masked] <mailto:[email-masked]> >
Skickat: den 6 november 2019 09:58:30
Till: Gunnar Hellström <[email-masked] <mailto:[email-masked]> >; Bo Burman <bo.burman=[email-masked] <mailto:bo.burman=[email-masked]> >; mmusic ([email-masked] <mailto:[email-masked]> ) <[email-masked] <mailto:[email-masked]> >
Kopia: [email-masked]' <[email-masked] <mailto:[email-masked]> >
Ämne: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments 

Hi,

--- 

Gunnar?

---

---

Gunnar?

[Christer] What about?

---

 
The intended title is: 

I will fix it.

---

Regards,

Christer

---

From: Bo Burman <[email-masked]>
Date: Thu, 7 Nov 2019 13:34:13 +0000

Yes, I agree that should resolve the  issue I had with the text.
Thanks,
/Bo

> -----Original Message-----
> Sent: den 7 november 2019 14:13
> To: Christer Holmberg <[email-masked]>; Bo Burman
> <[email-masked]>; mmusic ([email-masked])
> <[email-masked]>
> Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-
> usage-data-channel-07 - Bo's technical comments
>
> Hi,
>
> Christer, I accept your proposal below. With the remaining text it should be
> apparent for all that the solution has limitations.
>
> >>> In the first paragraph we say that one needs to use separate data
> >>> channels, so it sounds strange to then have a note saying that is not true.
> Also, the way you suggest the text makes it look like you are defining a
> mechanism for using a single channel.
> >> Yes, I realized the conflict and tried to avoid it by the words
> >> "limited functionality multi-party RTT presentation in one display area",
> and "This presentation style does not meet all RTT requirements".
> >>
> >>> "The usage of a single T.140 data channel, without any protocol
> extensions, would require the conference server to only forward
> >>>   real-time text from one source at any given time, and e.g., include IRC
> style text labels in the real-time text in order for the receiver
> >>>   to separate real-time text from different sources. The procedures of
> such mechanism is outside the scope of this document."
> >> "The usage of a single T.140 data channel, without any protocol
> >> extensions, would require the conference server to only forward
> >> real-time text from one source at any given time, and e.g., include
> >> IRC style text labels in the real-time text in order for the receiver to
> present real-time text from different sources separated. The procedures of
> such mechanisms cause functional limitations and are outside the scope of
> this document."
> > I am ok to replace 'separate' with 'present', but with the modification to the
> last sentence you would still have the question what those 'functional
> limitations' are,  and we would need to include additional text...
> >
> > To: Christer Holmberg mailto:[email-masked]; Bo Burman
> > mailto:bo.burman=[email-masked]; mmusic
> > (mailto:[email-masked]) mailto:[email-masked]
> > Subject: Re: [MMUSIC] Starting shepherd's review of
> > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
> >
> > Hi,
> > Even if I accepted to delete the last sentence in section 5 on multi-party, I
> want to propose a solution that might better address the original issue 5.
> >
> >     to transmit real-time text towards clients might however without any
> protocol extensions produce a limited functionality multi-party RTT
> presentation in one display area. Only one source at a time can be presented
> in real-time, but switch of source of text to display in real-time can be made
> automatically by the mixer and at suitable points in the text streams. Sources
> could be identified by inline text labels in IRC style. This presentation style
> does not meet all RTT requirements and if used, should be a temporary
> fallback method for conference-unaware clients."
> >
> > This wording is a self sustained description on what is possible and would
> also match better the recently revived work on multi-party rtt.
> >
> > Regards
> >
> > Gunnar
> >
> >
> >
> > To: Christer Holmberg mailto:[email-masked]; Bo Burman
> > mailto:bo.burman=[email-masked]; mmusic
> > (mailto:[email-masked]) mailto:[email-masked]
> > Subject: SV: [MMUSIC] Starting shepherd's review of
> > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
> >
> > Christer,
> > Till: Gunnar Hellström mailto:[email-masked]; Bo Burman
> > mailto:bo.burman=[email-masked]; mmusic
> > (mailto:[email-masked]) mailto:[email-masked]
> > Ämne: Re: [MMUSIC] Starting shepherd's review of
> > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
> >
> > Hi,
> >
> > ---
> > 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?
> interoperability problems. But RFC 4103 has a precaution. In chapter 6, where
> the cps is introduced, it is said:
> > "
> > the obsoleted predecessor of RFC 4103, so it is not exactly our case, but still
> valid.) We have discussed the risk that implementations may not implement
> setting or reading the dcsa attributes because of the complexity to do so
> alongside with the WebRTC API. That situation may cause a situation where a
> sent cps parameter is not obeyed. So the case is quite similar to the case in
> RFC 4103, and applications would be required to prepare for handling
> temporary reception at high rates.
> handled rapidly. The highest speed human interaction would be with speech-
> to-text applications. A very rapid speaker may produce 200 words per
> minute. That is 17 characters per second. The speech-to-text applications
> often makes corrections by long backspaces and resendings. That may add 10
> characters per second in the total. That results in a practical need of up to 27
> characters per second for one stream.
> > This calculation shows that for two-party calls, it would not hurt to use the
> same convention regarding cps default as RFC 4103 (30).
> conference server discussed in section 5.5, the need would be a multiple of
> that rate (27) corresponding to the number of simultaneous text senders. In
> well managed conferences this multiple is very close to one.
> > Neither leaving the default to unlimited, nor changing to a default of 30 cps
> as in RFC 4103 seems very critical. Any solution will do.
> >
> > ​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.
> arranged in one column with labels identifying the beginning of text from
> each participant and text from a number of participants received and placed
> in places corresponding to these different participants. With a conference
> mixer using one text stream and not applying any presentation protocol
> extension would only be able to produce a string for presentation in one
> column, including a source label in the beginning of text from one participant
> and only show text in real time from one participant at a time, shifting real-
> time presented participant at suitable points in the text stream. (end of
> phrase, end of sentence, line separator, long delay etc.). This presentation
> style may not be preferred by the user and it may cause delay before
> presentation of text from other than the currently presenting participant."
> > [Christer] Or, could we simply remove the last sentence ("Conference
> mixers that...")? The 1st paragraph already says why separate channels are
> needed, and the note says that future extensions may allow usage of a single
> channel, so I think it is pretty clear that using a single channel without any
> such extensions would come with limitations.
> >
> > ---
> >
> > 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?
> redundant data".   You could interpret "loss of data" to mean that (instead of
> "loss of packets"), but let me try an improvement: "If the gateway detects or
> suspects loss of data on the RTP stream, after use of possibly received
> redundant data, …"
> >
> > [Christer] What about?
> >
> >
> > "If the gateway detects or suspects loss of data on the RTP stream, and the
> lost data has not been retrieved using a redundancy mechanism, the
> gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data
> sent on the outgoing T.140 data channel."
> > ---
> >
> > 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”.
> >     Recommendation ITU-T.140 – Addendum 1  (02/2000), "Protocol for
> multimedia application text conversation"
> >
> > I will fix it.
> > [GH] I chased a number of such occurrences earlier. I think it was because
> your editor inserted an unusual slanting quotation mark. Note that there is
> also a double quotation mark on the third line of the same reference.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Nov 2019 15:01:58 +0000

Hi,

I have updated the pull request based on Bo's technical comments. Please take a look.

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

Gunnar, which RFC should I add as reference for the IRC labels?

Regards,

Christer

On 07/11/2019, 15.34, "Bo Burman" <[email-masked]> wrote:

---

From: Bo Burman <[email-masked]>
Date: Thu, 7 Nov 2019 15:29:19 +0000

This looks good to me and I have no further comments at this time.
Thanks,
/Bo

> From: Christer Holmberg <[email-masked]>
> Sent: den 7 november 2019 16:02
> To: Bo Burman <[email-masked]>; Gunnar Hellström
> <[email-masked]>; mmusic ([email-masked])
> <[email-masked]>
>     > >> But maybe that was not obvious. So, I accept your proposal below
> with
>     > >> some modifications
>     > >>
> IRC
>     > > So, this is a proposal for new wording of the last sentence in 5, as a
> solution
>     > on issue 5:
> speech-
> of
>     > > [Christer] I am pretty sure IESG would ask about this too, I suggest that
> we
>     > change the default to 30 cps.
>     > >
>     > > ---
> clarify.
>     > How about this:
> (instead of
> because

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 7 Nov 2019 16:51:19 +0000

Hi,

I am sorry, I have not yet found a reference for the common look of 
messages with a leading source label that I called "IRC style".

Anyone knows?

Regards

Gunnar

-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Nov 2019 18:04:04 +0000

Hi,

I guess we can reference RFC 1459 - how often does that happen nowadays? :)

Regards,

Christer
________________________________
From: Gunnar Hellström <[email-masked]>
Sent: Thursday, November 7, 2019 6:51:19 PM
To: Christer Holmberg <[email-masked]>; Bo Burman <[email-masked]>; mmusic ([email-masked]) <[email-masked]>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Hi,

Anyone knows?

Regards

Gunnar

Den 2019-11-07 kl. 16:01, skrev Christer Holmberg:
> https://protect2.fireeye.com/v1/url?k=e0987931-bc4c728f-e09839aa-86742d02e7e2-df3d38683e05ec32&q=1&e=9c7cc8f6-262c-4fc4-a624-42d361ef532b&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F52
>
--

Gunnar Hellström
Omnitor

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 7 Nov 2019 20:35:20 +0000

Den 2019-11-07 kl. 19:04, skrev Christer Holmberg:
Hi,

It is not easy to find specification of the label in RFC 1459. And IRC is not important. Let us change wording

from:

"and e.g., include IRC style text labels in the real-time text in order for the receiver to
  present real-time text from different sources separated. "

to

"and e.g., include human readable text labels in the real-time text stream indicating the source when shift of source occurs. This would be done in order to enable the receiver to  present real-time text from different sources separated. "

Regards

Gunnar

Regards,

Christer
To: Christer Holmberg <[email-masked]><mailto:[email-masked]>; Bo Burman <[email-masked]><mailto:[email-masked]>; mmusic ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>

Hi,

Anyone knows?

Regards

Gunnar

Den 2019-11-07 kl. 16:01, skrev Christer Holmberg:
> On 07/11/2019, 15.34, "Bo Burman" <[email-masked]><mailto:[email-masked]> wrote:
>
>      > To: Christer Holmberg <[email-masked]><mailto:[email-masked]>; Bo Burman
>      > <[email-masked]><mailto:[email-masked]>; mmusic ([email-masked]<mailto:[email-masked]>)
>      > <[email-masked]><mailto:[email-masked]>
--

Gunnar Hellström
Omnitor

--

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 8 Nov 2019 03:59:31 +0000

Hi,

I will modify as suggested.

Regards,

Christer

Sent: Thursday, November 7, 2019 10:35 PM

from:

to

Regards

Gunnar

Regards,

Christer

Hi,

Anyone knows?

Regards

Gunnar

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 8 Nov 2019 07:51:24 +0000

Hi,

I have done the changes and merged the changes in the pull request to the master branch:

https://github.com/cdh4u/draft-datachannel-t140/blob/master/draft-ietf-mmusic-t140-usage-data-channel.xml

I will submit a new version of the draft once the submission window opens.

Regards.

Christer

From: mmusic <[email-masked]> on behalf of Christer Holmberg <christer.holmberg=[email-masked]>
Date: Friday, 8 November 2019 at 5.59
To: Gunnar Hellstrom <[email-masked]>, Bo Burman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

Hi,

Regards,

Christer

from:

to

Regards

Gunnar

Regards,

Christer

Hi,

Anyone knows?

Regards

Gunnar

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström

Omnitor

+46 708 204 288