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

[Christer Holmberg <[e-mail]>]

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" <[e-mail]> wrote:

    Yes, I agree that should resolve the  issue I had with the text.
    Thanks,
    /Bo
    
    > -----Original Message-----
    > From: Gunnar Hellström <[e-mail]>
    > Sent: den 7 november 2019 14:13
    > To: Christer Holmberg <[e-mail]>; Bo Burman
    > <[e-mail]>; mmusic ([e-mail])
    > <[e-mail]>
    > 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.
    >
    > I hope also Bo thinks that the issues are solved now.
    >
    > Regards
    >
    > Gunnar
    >
    >
    > Den 2019-11-07 kl. 14:06, skrev Christer Holmberg:
    > > 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".
    > >>
    > >> But maybe that was not obvious. So, I accept your proposal below with
    > >> some modifications
    > >>
    > >>> 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."
    > >> 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."
    > > 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:[e-mail]
    > > Sent: Wednesday, November 6, 2019 9:44 PM
    > > To: Christer Holmberg mailto:[e-mail]; Bo Burman
    > > mailto:bo.burman=[e-mail]; mmusic
    > > (mailto:[e-mail]) mailto:[e-mail]
    > > 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.
    > >
    > > 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 mailto:[e-mail]
    > > Sent: Wednesday, November 6, 2019 5:16 PM
    > > To: Christer Holmberg mailto:[e-mail]; Bo Burman
    > > mailto:bo.burman=[e-mail]; mmusic
    > > (mailto:[e-mail]) mailto:[e-mail]
    > > Cc: 'mailto:[e-mail]'
    > > mailto:[e-mail]
    > > Subject: SV: [MMUSIC] Starting shepherd's review of
    > > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
    > >
    > > Christer,
    > > I agree with your proposals.
    > >
    > > Regards
    > > Gunnar
    > >
    > > ----------------------------------------------------------------------
    > > Gunnar Hellström
    > > Omnitor
    > > mailto:[e-mail]
    > > [phone]
    > >
    > > Från: Christer Holmberg mailto:[e-mail]
    > > Skickat: den 6 november 2019 09:58:30
    > > Till: Gunnar Hellström mailto:[e-mail]; Bo Burman
    > > mailto:bo.burman=[e-mail]; mmusic
    > > (mailto:[e-mail]) mailto:[e-mail]
    > > Kopia: 'mailto:[e-mail]'
    > > mailto:[e-mail]
    > > Ä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?
    > > [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.
    > >
    > > [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.
    > > 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."
    > > Pew, maybe too long and detailed....
    > >
    > > [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?
    > > [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, …"
    > >
    > > [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”.
    > > 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.
    > > [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.
    > >
    > > [Christer] I will double check.
    > >
    > > ---
    > >
    > > Regards,
    > >
    > > Christer
    > >
    > >
    > --
    >
    > + + + + + + + + + + + + + +
    >
    > Gunnar Hellström
    > Omnitor
    > [e-mail]
    > [phone]