On 05.06.2015 13:26, Matthew Wild wrote: > On 5 June 2015 at 12:07, Daniel Gultsch <[email protected]> wrote: >> 2015-06-05 13:01 GMT+02:00 Daniel Gultsch <[email protected]>: >>> >>> And I'm currently not really seeing the point of a client adding an id >>> since the client can already set the stanza id. With an the by attribute we >>> don't have to decide on whether or not there is a use case for the >>> client-id. >> >> fwiw I just thought of a use case for a client setting the message-id. A >> client can use that to identify it's own message in a MUC when the muc >> server changes the stanza id. > > Right, this is basically the only case I have seen. And I would *much* > rather see the MUC XEP and the single implementation that I know with > this behaviour, fixed, instead of writing off the 'id' attribute as > useless for what it's designed for - a means of tracking messages.
A few weeks ago, I was all for changing xep45 so that the ID of reflected messages SHOULD be preserved (like it was suggested by Georg on standards@ a few months ago). Now, I'm unsure if this is really possible: How do you handle duplicate IDs? How do you handle error stanzas send back to the MUC service, caused by a stanza with a duplicate ID? That's why I think the only way to possible solve this is <message-id/> with 'client-id', as described in http://geekplace.eu/xeps/xep-muc-extensions/xep-muc-extensions.html#mid - Florian
signature.asc
Description: OpenPGP digital signature
