[Standards] XEP-0301 0.5 comments [Sections 1 through 5]

Kevin Smith kevin at kismith.co.uk
Sat Jul 28 08:07:16 UTC 2012

On Sat, Jul 28, 2012 at 8:30 AM, Mark Rejhon <markybox at gmail.com> wrote:
> On Sat, Jul 28, 2012 at 1:22 AM, Gunnar Hellström
> <gunnar.hellstrom at 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

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


More information about the Standards mailing list