Re: [AVTCORE] WG Last Call: "RTP-mixer formatting of multi-party Real-time text"

I have reviewed https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-11

Although there are quite a few comments below, only the last one is possibly a normative change.  I would be fine with having these comments addressed in whatever the next revision to the document is, rather than hold up IETF last call. I support advancing this document to Proposed Standard.

1. I don’t think it’s necessary to say "Regional regulatory requirements specify provision of real-time text
   in multi-party calls” in the abstract.  It’s true, but the IETF usually doesn’t do things because governments make them a requirement.  Instead, I might say something like “Use of RTT is increasing, and specifically, use in emergency calls is increasing.  Emergency call use requires multiparty mixing”.  I’d just delete the reference to regulatory requirements in the Introduction section.

2. This is a run-on sentence:
   ...The presentation can
   then be arranged so that text from different sources can be presented
   in real-time and easily read while it is possible for a reading user
   to also perceive approximately when the text was created in real time
   by the different parties.
Perhaps “The presentation can then be arranged so that text from different sources can be presented
   in real-time and easily read.  It is also possible for the presentation to indicate approximately when the text was created in real time
   by the different parties.”

3. In 1.1. this text appears: "and in most applications also more than three parties in a call is rare”.  As anyone experiencing this past year can attest, that is not true :). The first part of the sentence is true, and I think this can just be deleted.

4. The heading "The presentation planned by the mixer for multi-party unaware endpoints” is not great English.  Could be “Mixer provides presentation of multiple parties”

5. In section 1.2 could we not say “as defined in” rather than “are explained in” for RFC3550?

6. <not a request to change> I had to look up the definition of “utterance” to see that in linguistics, it means “an uninterrupted chain of spoken or written language”, so it’s correctly used here.

7. In this subsection (Intended use), would it be good to mention the issue of backspace when dealing with multiple parties?  I always found that the best example of why it’s hard to to this centrally.

8. In 2.2 it says “does not itself implement any solution for multi-party handling of real-time text.”  It’s actually that it doesn’t meet this document's “multiparty-aware” specification: if you don’t negotiate the use of the mechanism specified here, then you use this multiparty unaware mechanism.  It could implement some other mechanism but if the mixer didn’t support it, it wouldn’t work.

9. 3.6 missing “the” in "It is RECOMMENDED to send next packet to..”  So “.. send the next packet”

10. In 3.7 it says “New and redundant text from one source SHALL be transmitted in the same packet”.  Is that explained in 4103?  It’s old redundant text and new text.  Not new text and a redundant copy of the new text.  Maybe could use a bit of explaining.

11. Minor English issues in 3.8.  Say “Text received by a mixer from a participant..”

12. Minor English in 3.12.  Say “the participant whose text is included”

13.  Think about expanding WHY you must consider integrity for RTCP (3.18).  Also ".. considerations SHALL be considered" isn’t great construction.

14. 3.19.1, if the receiver is a mixer, then CC=0 doesn’t mean point to point in the sense you intend here.  It’s text from a participant, as opposed to text from a mixer, in a multiparty call.

15. Are 13.19.2 and 13.19.3 just restating what 4103 says?  If they are, then consider deleting

16. Minor English, say “SHALL be regarded as lost”

17. In 3.19.4, you have a normative “a t140 block SHALL be created”, but then later you say “Implementations MAY apply more refined methods”.  Doesn’t that make that SHALL a SHOULD?  Also, minor English, say something like “SHOULD prefer marking possible loss rather than not marking when it is uncertain if there is loss”

18. In 3.21, you have two cross references to the same RFC in the same sentence.  One can be deleted.

19. 3.23, minor English: say “Packet 103 is assumed to be lost due to network problems”.

20. In 3.24 it says 'A value for "CPS" of 90 is the default for the "text/t140" stream in the  "text/red" format when multi-party real-time text is negotiated.’   Is that a restatement of what 4103 says, or a normative statement this document makes?  Please make it more clear.

21. In 4.1 normative MUST/MAY/SHOULD is used to describe user interface.  Is that appropriate? Same for 4.2

22.  On the other hand, in 4.2.1, there is a lower case “.. BOM characters … shall be deleted”.  That might want to be SHALL.

23. In the beginning of 4.2.2, is the “SHOULD be applied for each recipient of multi-part text” actually “...non multi-party aware recipient”?

24. (The only possibly normative change) 4.2.5 says the mixer should send primary data from one source per packet.  Why is that?  The mixer is creating a single stream that contains all the display for the mixed participants.  ISTM there is nothing gained by this restriction, and it means lots of extra packets.  

Brian

> On Nov 25, 2020, at 5:16 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> This is an announcement of WG last call on "RTP-mixer formatting of multi-party Real-time text"
> 
> The document is available for inspection here: 
> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix <https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix>
> 
> WG Last Call will end on December 9, 2020. 
> 
> In response, please state one of the following: 
> 
> * I support advancing the document to Proposed Standard
> * I object to advancement to Proposed Standard, due to Issues described below <Issue description or link>. 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt