> > Retransmission seems entirely appropriate when an entity that >> previously didn't support RTT (e.g. because it was offline) starts to >> support RTT - but frequent retransmission because some entity along >> the path has failed seems wrong to me. >> > > Again, I now think it's a terminology issue. > The word "retransmission" may be wrong. >
For a MUC room with lots of flux (people leaving/joining): Regular message-reset (retransmission) every 10 seconds is more efficient than sending a message-reset (retransmission) everytime someone signed on, from a congestion perspective. There are a few situations where we need MUC *and* automatic resumption of RTT are both simultaneous and concurrent requirements. This Including from NG911 perspective -- MUC being used as method of letting multiple people an incoming text-to-911 caller, even if mostly with lurker-only privelage in the MUC room, and automatic message-reset being useful to quickly recover from mobile reception transient events. To improve congestion concerns in certain contexts -- A specific client can make RTT could also be a grantable privelage (i.e. RTT only available for moderators) -- so that only the lecturer in a MUC gets RTT while visitors (listeners/students) can only respond line-by-line. As you observe, many parts of 4.6.4 is only a "SHOULD" and will no doubt probably be clarified as software vendors start to get more real-world MUC experience with XEP-0301 over the next many years -- to cover the various complex congestion dynamics of a MUC. I need to do some thinking. It is reasonable to keep 4.6.4 as simple as possible -- and may need to be handled differently for MUC vs non-MUC, by mentioning a required different behaviour in section 6.4.3 that covers MUC. Mark Rejhon
