On 25/02/2023 12.38, Marvin W wrote:
On Sat, 2023-02-25 at 11:35 +0100, Florian Schmaus wrote:
What I tried to express is that changing the semantics of the RFC
'id'
attribute in a new RFC is not a viable solution. Simply because you
still need to operate with older implementations that do not follow
the
newer RFC. Hence I believe adding this via origin-id is better.
You seem to be under the assumption that messages created by clients
following the rule that the id-attribute must be unique are
indistinguishable from messages of clients that don't and thus suggest
to use <origin-id id=unique-id /> as a distinguishing functionality
(although an element <unique-id/> that just signifies that the id in
the id-attribute is unique would suffice as well).
I would expect that there will be other means to distinguish those. If
we do a new XMPP RFC, we might look into revisiting things like having
two namespaces (for s2s and c2s) and similar other things. Basically
really looking into what other issues we have on the RFC layer of XMPP
and also which features we currently have in XEPs should become part of
the RFC. And once it's possible to detect an XMPP 2.0 client, you also
know that it followed the unique id principle.
Detecting that a client followed a new principle is easy. The question
is what to do with the clients where you did not detect that they follow
the new principle. This problem exists for origin-id and a new RFC.
That is true. However, this discussion made me realize that origin-id
may be a necessity to reference stanzas in 1:1 chats.
Doing so would effectively mean that referencing stanzas from clients
without origin-id would not be possible. However, I don't think current
popular clients sends origin-id in direct chats and also all current
references don't rely on origin-id (they often optionally support using
origin-id when present though). Migrating to requiring origin-id would
thus not only cause issues with very old legacy clients with non-unique
id-attribute behaviors, but rather cause issues with all the clients we
use today.
It is impossible to robustly reference messages from clients that
neither use origin-id nor a potentially new RFC thingy.
So origin-id and requiring different id semantics in a new RFC are
equivalent so far. The only, but major, difference is that we have
origin-id right now and that it is deployable without depending on a new
RFC version being written.. :)
- Flow
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
