24 Dec
2024
24 Dec
'24
9:32 a.m.
Why mentioning origin-id at all, and not simply write
Clients SHOULD use a message-id that conforms to Unique and Stable Stanza IDs (XEP-0359)
<https://xmpp.org/extensions/xep-0359.html> [4
<https://xmpp.org/extensions/xep-0424.html#nt-idm45702685434944>] on sent one-on-one
"chat" messages to make them suitable for message retraction.
Meaning *not* adding origin-id, rather putting an id that conforms to whatever origin-id
should be into the message id attribute.
Then we don't have to deal with yet another id, and if we receive a retraction
request, we know the client implements 0424 and therefor knows to use unique ids.
Regards
Philipp
On Tue, Dec 24, 2024, at 16:26, Dave Cridland wrote:
On Tue, 24 Dec 2024 at 15:09, Marvin W <xmpp(a)larma.de> wrote:
Hi,
On Tue, 2024-12-24 at 10:52 +0000, Dave Cridland wrote:
Ah, I see this in 5.1, but the third para in section 3 says origin-id. So maybe fix that
para?
I'm curious about the use of origin-id here.
I thought from previous discussions we'd decided that origin-id only had value within
certain MUC cases; whereas the origin-id is explicitly only for 1:1 messaging here. Does
this mean any message to be retracted has to use an origin-id, and (therefore) a client
must send all 1:1 messages with an origin-id?
Do we want to make it use the stanza id attribute instead? If not, why not? It seems that
XEP-0308 handles this fine without the use of origin-id.
What do existing clients do? Do they all really inject an origin-id for this one case
(are there any others?
I think what you wrote does not reflect what is written in the XEP:
- if a message is of type 'groupchat' -> Use "the ID assigned to the
stanza by the group chat itself"
- for MUCs, that means to use the XEP-0359 <stanza-id> from the MUC
- if a message is of any other type -> Use "<origin-id> if present, or the
value of the 'id' attribute on the <message> otherwise"
So there is absolutely no requirement for <origin-id>, there is only a requirement
for MUCs to assign a <stanza-id>.
Also 5 says that clients SHOULD put in an origin-id "to make them suitable",
and that's certainly a requirement (albeit not an absolute one).
Regarding XEP-0308 "handles this fine without the use of origin-id", what I
wrote in an earlier mail applies: The id in XEP-0308 serves a different goal. It's not
meant to be used to identify the message in the history, it's meant to ensure that
both entities have the same understanding of which the last message is, so that if for
whatever reason the message ends up out of order or at a different client than expected
(e.g. recipient client goes offline and message is routed to another resource instead), it
won't be misunderstood to edit an unrelated message. The risk of collision is
significantly less in that case.
Gotcha, though in either case, it's the same client that {retracts|edits} the message
as has sent it (and presumably chosen the id), so if it cannot figure out a sensible
strategy for generating ids, it presumably can't generate origin-id's any easier.
Or is there some other reason why origin-id is less prone to collision?
Overall, then, I'd rather strip origin-id from the spec.
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org