[Standards] XEP-0301 0.5 comments [Sections 1 through 5]
markybox at gmail.com
Sat Jul 28 07:30:11 UTC 2012
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
>> 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
>>> 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?
>> 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
> 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
> 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
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.
More information about the Standards