[Standards] LAST CALL: XEP-0308 (Last Message Correction)

Kurt Zeilenga Kurt.Zeilenga at Isode.COM
Mon Aug 13 16:20:02 UTC 2012


It may be that I'm reading a restriction into the spec that wasn't intended by the authors.  If so, then maybe a simple clarification is needed (like drop the "Last" from the title).


On Aug 13, 2012, at 9:15 AM, Kurt Zeilenga <Kurt.Zeilenga at Isode.com> wrote:

> Why is this restriction restricted to editing the "last" stanza sent?
> 
> Is this due to presentation issues?
> 
> If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders...  because a sender cannot control other senders.  In short, receiving clients have to appropriately deal with replacements for non-last stanzas.  And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general.
> 
> Anyways, if there's no particularly strong reason to have the "last" message restriction, I think it should be removed.
> 
> -- Kurt
> 
> 
> On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor <editor at xmpp.org> wrote:
> 
>> This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction).
>> 
>> Abstract: This specification defines a method for marking a message as a correction of the last sent message.
>> 
>> URL: http://xmpp.org/extensions/xep-0308.html
>> 
>> This Last Call begins today and shall end at the close of business on 2012-08-17.
>> 
>> Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:
>> 
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
>> 2. Does the specification solve the problem stated in the introduction and requirements?
>> 3. Do you plan to implement this specification in your code? If not, why not?
>> 4. Do you have any security concerns related to this specification?
>> 5. Is the specification accurate and clearly written?
>> 
>> Your feedback is appreciated!
> 




More information about the Standards mailing list