It's just ticked over into Christmas Day, so before anything else, Merry Christmas!
Sounds nothing that can be answered without a specific context (e.g. in context of a specific XEP and use case)
I'm not so sure.
What we could do is list the different IDs and its attributes and a recommendation for the use case in which they are good and bad and why.
For Example
Message ID:
- Not Unique
Always at least unique to the stream. RFC 6120 allows this; I think it'd be useful to ensure these are globally unique instead - not only for the benefit of other entities, but (I suspect) the originating entity itself.
All ids are chosen, and origin-id is also chosen by the sender.
What attacks are there if an attacker deliberately reuses an id? (For retraction, possibly that an attacker can make some clients retract the first message, and others retract a subsequent message).
Should not be used:
- Whenever its critical to identify a specific message
Like, say, type="error" bounces? Or receipts? Or chat markers? We're doing all these *all* the time.
We don't - ever - identify a message by just the id (or if anyone's doing that, then please stop). We identify using an id and a jid - and the interesting cases (see other thread) start when we want to scope other than a full jid of an online client.
Can be used:
- Whenever it does not hurt to identify a wrong message, or if there is another attribute that in combination allows to identify the correct message (e.g. LMC Attribute "It must be the last message sent/received")
Recommendation:
Do not use for new XEPs, if for a use case a XEP needs to depend on client generated IDs (Non-MUC), use origin-id.
I'm more interesting in documenting the problems rather than looking for solutions at this stage.
Should solutions be obvious - and one such is that we should just mandate that the attribute id is always present, and always globally unique - then let's do the sensible choices instead of workarounds like origin-id.
Dave.