On Sat, Jul 28, 2012 at 8:30 AM, Mark Rejhon <marky...@gmail.com> wrote: > On Sat, Jul 28, 2012 at 1:22 AM, Gunnar Hellström > <gunnar.hellst...@omnitor.se> wrote: >>> >>> <GH>No, please make a MUST for id= in edit previous. I can imagine >>> presentation cases when it is absolutely necessary to know what message >>> the >>> edits belong to. Why do you want to introduce so many options? Strict >>> requirements are usually much more fruitful. >>>> >>>> But I do not understand why you want to introduce the risk of confusing >>>> presentation by telling that it is possible to do last message edit >>>> without >>>> id= , when you have specified that feature for exactly that function. >>>> At the moment we have no backwards compatibility to bother about. Why not >>>> get it right from the beginning? >>>> >>>> Gunnar >>> >>> Again, Kevin now needs to explain why a third disco case was needed >>> (he suggested one in addition to the existing 0301 and 0308 disco). >>> Kevin originally said it was for allowing 0308 to be used without 0301 >>> retroactive editing. This was a solution to succeed on this feature >>> without requiring a third disco to be added. >>> >>> Also, the change will still be be permitted under XEP-0001 draft rules >>> -- making it stricter is a fully backwards-compatible change. Kevin >>> -- are you fine with always requiring 0301 to use 'id' attribute -- >>> for a client that implements both 0308 and 0301? >>> >>> Mark Rejhon >> >> <GH> A MUST for supporting reception of id= when you have negotiated both >> 0301 and 0308 is the logical conclusion. >> And if you transmit rtt during the correction then that MUST be marked with >> id= . >> And you at least SHOULD support transmission of rtt during the correction. >> I do not see a need for an extra negotiation of the combination of 0301 and >> 0308. I think the idea behind it would be that it can be complex to present >> the edit last in rtt mode when you have already transmitted the beginning of >> next message. But that must be manageable. >> >> Allowing rtt without id= during correction could end up in confusing >> presentation. >> >> Example: A and B are negotiating a payment. >> >> This is the way it will be displayed if there was not id= support during rtt >> A: I will give you 100 EUR >> B: Not enough >> A: I add 50 EUX >> (A discovers the mistake. With edit last support without id= support, the >> corrected sentence would be displayed as new until it is completed) >> A: I add 50 EUR and this is my last bid, take it or leave it, I want to get >> this done, tomorrow is my daughter's birthday and I do not have time........ >> B: ( while A is typing ) Great 200 agreed >> >> When finally A completes the sentence, the corrected message should replace >> the one with EUX, but that may be too late. The confusion has already caused >> harm. >> >> With id= support in rtt, you will instead see the EUX changed to EUR, no >> duplication of text, and the correct deal achieved without confusion. >> I recommend that we avoid this risk for confusion by requiring support of >> id= if both 0301 and 0308 are negotiated >> >> Gunnar > > Good use case -- but -- > This still makes the current version of 0301+0308 (even without 'id'') > superior to older suggestions of 0301+0308 (without any real time text > at all, for retroactive) > > Since this is for the next version after 0.6, the two obvious choices are: > -- Change to require retroactive <rtt/> whenever 0301+0308 is both active > -- Keep my existing method (which I feel is still superior, for > Gunnar's use case, to Kevin's original method that suggested a third > disco be used) > > Comments from Kevin? He's the author of 0308, so I'd like agreement from him.
I think that if you're sending an RTT correction, your client needs to know that you support it, because otherwise you end up with goofy (and harmful) situations as Gunaar suggests. I see two ways of ensuring this: 1) Mandate that if you advertise support for both RTT and Correct that you understand RTT Corrections. 2) Have a third disco feature for RTT Corrections. I'm reasonably opposed to the situation where a sender's client is sending RTT Corrections without any way of knowing if the recipient supports them - which can lead to the recipient /user/ thinking they're reading a new message, but aren't. You've previously said that people tend to use RTT without pressing Enter and sending a message, using the structure of the text for message boundaries. This doesn't seem to mesh well with users not knowing if what they're reading is a new message or an update to an existing message. I don't think the argument of "Well, the recipient will be able to render /something/ it just won't by able to render the right thing (or, rather won't be in the right context)" is terribly satisfying here. /K
