jdev - 2020-11-03

my stance is that one can only reasonably attach to stanza-id using both the ID value and the value of 'by'

note that there could be multiple <stanza-id/> extensions

but at most one <stanza-id/> with the same 'by' value ✏

I also guess that you usually want to use the <stanza-id/> that was added by the service arbitrating the messages of the particular conversation. that is, use the MUC by if it's a MUC, and not the 'by' of your user account (archive)

Regarding Message Fastenings https://xmpp.org/extensions/xep-0422.html what if the message one wants to apply-to has only origin-id and not stanza-id? Does one use origin-id? https://xmpp.org/extensions/xep-0359.html What if it has both? Which id one should use to attach-to? stanza-id? ✏

SouL: Doesn't it already say "origin-id" (first sentence of #3.1)?

Though I thought origin-id was supposed to die!

Holger: there is no consensus on that :(

I don't think missing consensus wrt the death or life or origin-id is the problem here. But Holger is right, xep422 § 3.1 specifies origin-id as anchor

I think we have a number of XEPs that use some sort of id to reference other stanzas, and that have different and conflicting rules on which id to use with which priority

Even though I think it is dangerous, as it allows malicious entities to add duplicate, with respect to origin-id, messages into an archive, which makes fastening/attaching harder (select oldest message in case of duplicate origin-id?) ✏

like 0184, which we are probably not going to get "fixed" anyway.

Ge0rG, could you name one?

does xep184 mention xep359 at all?

flow: https://xmpp.org/extensions/xep-0333.html#rules-muc

I think 0333 uses the RFC 6120 ID except when it uses the 0359 stanza ID.

Heh, that.

ahh ok, yes xep333, but is there another one besides that?

but a search for "0359" in xep184 does not yield any results, so I am not sure about any different/conflicting rules there ✏

Because it uses the 6120 ID, no?

flow: a XEP that references messages without using 0359 by definition has conflicting rules to a XEP that does

Holger, exactly, at the time xep184 was written, xep359 did not exist

Right.

Ge0rG, not sure where the conflict origins from?

https://xmpp.org/extensions/xep-0424.html#rules

https://xmpp.org/extensions/xep-0444.html#sending-reactions

there are sure different rules about "referencing IDs"

but hopefully there are no conflicting rules

different _is_ conflicting

yeah ok, if you think so. I would use the term "conflicting" if it where not possible to implement and use both approaches at the same time

I just think it would make sense to have a separate "The Art Of Message Referencing" XEP, that would be Standards Track and that all the others can reference for stanza referencing rules

that I could very well agree with

but I guess we don't have such a thing because nobody wrote a draft for discussion

I am mostly concered that <origin-id/> is the wrong ID to use as anchor for referencing, amongst other things because of the reason mentioned above ✏

I am concerned that <origin-id/> shouldn't have existed in the first place

I honestly wonder why? While others also seem to like it that much that they use it for referencing

because I'm on a quest to fix message @id

ok, but even if you (successfully) worked on a better fix for the MUC reflection issue, that does not automatically mean that you have to condem everything else more-or-less related?

I mean sure, origin-id originated more-or-less from the same issue, but that does not mean that it has no value in other areas too ✏

flow: I know that we disagree on that, and I still fail to see that value.

Ge0rG, ok, but you also see no active harm either, right? You may see passive harm in something being specified that has no value, akin to dead code in your codebase, that you typically want to get rid of. But I don't hink that dead code is our main issue within the XMPP specificiation zoo

flow: it's not only dead specification and dead code but also dead XML on the wire

and it's adding ambiguity because you now have at least three different IDs for a single message

flow: which is also why I still insist on "The origin-id value MUST be equal to the stanza's @id attribute"

As I said before, I don't see any value in signalling "I'm really generating unique stanza IDs", as the receiving entity must be able to do a graceful degradation anyway.

flow: you could simply omit the origin-id then.

I don't see how specifying that "origin-id == stanza @id" is sensible, you could simply omit the origin-id then ✏

exactly

(see my correction)

Well, then why is it even specified? ;)

arguing that dead XML on the wire is bad, while also arguing that origin-id should have the same value as something else within the same stanza is inconclusive

flow: well, stream compression will allow to reduce the length then :P

</s>

flow: just remove <origin-id/> altogether and we are fine again :P

My order of preference is: 1. No <origin-id/> ... ... ... 2. origin-id = @id 3. As it is now

In terms of Council decisions that would probably be something like +1 / 0 / -1.

(now would be a good time to vote me out!)

Ge0rG, you think 3 IDs are bad? I noted a week ago or something a message that had FIVE IDs, not counting @id

Zash: that's quite a feat

Altho two were timestamps. (the same timestamp in different formats)

timestamps are not ids