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

[Bo Burman <[e-mail]>]

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]