On Tue, Jul 2, 2013 at 6:46 PM, Mark Rejhon <[email protected]> wrote: > On Tue, Jul 2, 2013 at 12:23 PM, Kevin Smith <[email protected]> wrote: >> 4.2.2 - I'm aware than we've had debates in the past about how much >> needs to be MTI. As things currently stand, the XEP is fairly clear >> and straightforward, and I wonder if making all of these MTI would be > MTI?
Mandatory To Implement. >> 4.7 "For implementation simplicity, recipient clients MAY track >> incoming <rtt/> elements per bare JID <[email protected]> to keep >> only one real-time message per sender" >> Would this really help implementors? Trying to do bare-JID only seems >> like it's going to involve more complexity and headache than doing >> full-JID. > > > To the contrary; OK. I think this is conflating single-window and bare-JID, but it's not a big issue. >> 4.7 "Alternatively, recipient clients MAY keep track of separate >> real-time messages per full JID <[email protected]/resource> and/or >> per <thread/> (Best Practices for Message Threads [9])." >> >> I think that some of the earlier instructions will be incompatible >> with having multiple RTT messages per full-JID. It would be worth >> someone else checking. > > > To the contrary. It's rather simple: Test the use-case. > In a client that supports multiple RTT messages per window, both B1 and B2 > would be displayed simultaneously on A in the above use-case example. The > only difference to the UI would be B1 replacing B2, and vice-versa (4.7 > processing), versus B1 and B2 being displayed at the same time. There is > thusly, no incompatibility. > > Also, it's already been checked several times. > Please try the implementations before discussing this matter This isn't really the way it works - the spec stands on its own, independent of implementations. > you are slightly confused in this matter Very possible, I'm easily confused. I'll re-read when I have a chance. >> 4.7.3 "The message refresh SHOULD be transmitted regularly at an >> average interval of 10 seconds during active typing or composing. This >> interval is frequent enough to minimize user waiting time, while being >> infrequent enough to not cause a significant bandwidth overhead. This >> interval MAY vary, or be set to a longer time period, in order to >> reduce average bandwidth (e.g. long messages, infrequent or minor >> message changes)." >> >> It feels to me like this is really saying "It is suggested that a >> message refresh be transmitted regularly at an..." - otherwise the >> SHOULD and the MAY seem contradictory. > > > The "SHOULD" refers to an exact 10 second interval. > The "MAY" refers to a varying time interval (not exactly 10 seconds). > I can remove the second "MAY" into a "suggested", but the first "SHOULD" is > far more important as we've found it greatly improved reliability during the > emergency-use/911 tests/work with InDigital's demo. I was considering > changing it to a "MUST" (I had pressure for that). If you have s/SHOULD/MUST/, it's not possible for any compliant client to do anything other than regular 10 second intervals. I think I understand what you're trying to say now, though. I'm not sure what the best way of expressing it is. >> 6.2.1 "it is inappropriate to send any further <rtt/> elements, until >> support is confirmed either by incoming <rtt/> elements or via >> discovery." >> >> This needs to be normative somewhere, I think, that clients MUST NOT >> start transmitting RTT edits until support has been confirmed. I don't >> think the non-normative information note here is going to be sufficient. > > > Section 5.1 of XEP-0085 allows transmitting of XEP-0085 without determining > support. I am merely simply being consistent with that, by permitting only > a single <rtt event='init'/> to be transmitted so that I'm fully compatible > with combining XEP-0301 with XEP-0085 in every single situation that > XEP-0085 can be used. There has also been long discussions in the past to > this aspects, and this was an acceptable decision that was reached by > majority (albiet, not by everyone) -- consistency with XEP-0085 use cases. I think you're addressing a different point to the one I'm making. I'm saying that the rule you've got needs to be normative - *not* that the rule allowing you to send an init is wrong (I know you have strong feelings on the latter). <Sorry, had to go out here for a couple of hours, finishing the mail now> >> Discovery for MUCs isn't covered - I think it needs to be; blithely >> sending RTT to an unsuspecting MUC would not be good. >> >> 6.4.4 - the seqs here aren't sequential - is that deliberate? > > > Correct. event='new' and event='reset' are allowed to restart the 'seq' > numbering at any number, as mentioned in 4.3 Processing Rules. > If this was unclear, let me know how to tweak this. One line pointing to 4.3 would probably help - I missed this even though I was reading the whole thing through. /K
