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]
