* Florian Schmaus <[email protected]> [2017-09-23 11:22]: > I think I don't understand the benefits from Georg's suggestion, so > currently one reason against is that it adds more complexity without any > gain from my PoV.
I would argue that it reduces complexity by decreasing the number of
"unique" message IDs attached to a given message from three to two.
As a client developer, I want to have as few places as possible to look
for a message ID, so stanza-id >> origin-id >> stanza id (*).
(*) stanza-id = XEP-0359 <stanza-id/> element
stanza id = 'id' attribute of the message stanza
> Plus what you said: The scheme will break as soon as the MUC service, or
> any other service doing some sort of reflection, rewrites the 'id'
> attribute of the stanza (which MUC services are allowed to, and are the
> reason for xep359 existence in the first place).
There are also MUC implementations (read: transports) that strip away
non-body elements from reflected messages. The pathological case is
an IRC transport which removes all non-body elements, splits a
multi-line body into multiple separate messages and changes the message
IDs.
Other XEPs, like LMC and References, use the stanza id as a reference. I
assume that MUCs will not rewrite the stanza id in the payload, thus
breaking those XEPs. By enforcing origin-id = stanza id we can at least
fix this particular problem on clients that support both LMC/Reactions
and 0359.
Georg
--
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
