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 <[email protected]> wrote: >> Hi, >> >> On Tue, 2024-12-24 at 10:52 +0000, Dave Cridland wrote: >>> 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" >> > > Ah, I see this in 5.1, but the third para in section 3 says origin-id. So > maybe fix that para? > >> >> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
