[Standards] Proposed XMPP Extension: Unique and stable message IDs

Florian Schmaus flo at geekplace.eu
Sun Jun 7 18:21:36 UTC 2015


On 05.06.2015 13:26, Matthew Wild wrote:
> On 5 June 2015 at 12:07, Daniel Gultsch <daniel at gultsch.de> wrote:
>> 2015-06-05 13:01 GMT+02:00 Daniel Gultsch <daniel at gultsch.de>:
>>>
>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150607/4f8131ce/attachment.sig>


More information about the Standards mailing list