18 Oct
2024
18 Oct
'24
11:49 a.m.
Apologies for the confusion. Let me illustrate what I'm asking.
The existing XEP defines in section 7.1 that after the client sends the
initial join, the MUC service MUST send it events in the following order:
1. In-room presence from other occupants
2. In-room presence from the joining entity itself (so-called
"self-presence")
3. Room history (if any)
4. The room subject
5. Live messages, presence updates, new user joins, etc.
What I am asking is: does the XEP permit the MUC service to send an event
_after_ it receives the initial join from the client, but _before_ it sends
"1. In-room presence from other occupants"?
I am not arguing for or against doing so. I am observing that some services
already do this (I don't think that for the purpose of this discussion it
matters much what data is sent, but it's a presence stanza with CAPS from
the bare JID of the room itself).
Given the existing wording of the XEP, I would argue that sending 'extra'
events is at least confusing, and at worst not permissible. A strict
reading of the text does seem to leave some wiggle room: I think the
specification only states that the 5 events that are listed should arrive
in this order, but it does not explicitly forbid any other events before
these events (or maybe even interlaced with them).
Whether or not this is deemed allowed, I feel that the XEP text should be
adjusted to be more clear.
Kind regards,
Guus
On Fri, Oct 18, 2024 at 6:19 PM Philipp Hörist <philipp(a)hoerist.com> wrote:
Hi,
Is it allowable that a server sends _more_ events
(that are not in the
list specified in XEP-0045)?
Yes as Point 5 of the event list clearly means "everything else" as
denoted by the "etc.", accounting for the extensible nature of XMPP.
Not sure what there is to discuss. What do you think would be excluded
under Point 5?
Or are you asking if you can inject new undefined Events *before* Point 5?
To that question i would definitely have the opinion, No you should not do
that, and its not allowed and unexpected.
You gave no example what could be that important that it needs to be
inserted earlier than point 5 in the event order.
If you are talking about Prosodys room self presence which communicates an
avatar then its clearly not necessary to send this presence before the
subject.
Not sure if Prosody sends the avatar presence before the subject, but it
was never and will never be necessary to satisfy the use case of
communicating the avatar. So if you are asking if you should do the same, i
would say No, please send after subject as allowed by the XEP.
Or is there any other concrete example you are asking for?
Regards
Philipp
On Fri, Oct 18, 2024, at 16:45, Guus der Kinderen wrote:
Hello XMPP aficionados!
For a client joining a MUC, XEP-0045 defines a very strict order of events
(section 7.1). Is it allowable that a server sends _more_ events (that are
not in the list specified in XEP-0045)?
I've observed that in the wild, at least one implementation sends a
presence stanza 'from the room itself' (with CAPS), preceding the events
defined in section 7.1.
There is an argument to be made that the XEP defines the order of the
events, but leaves room for there to be 'more' events. One could argue that
this is in line with the extensible nature of XMPP.
On the other hand, I think that it's fair to say that this is stretching
things to an extent where it is not unreasonable for implementations to not
account for this (thus introducing potential interop issues).
I would like for the XEP to be more explicit, and either explicitly allow
or disallow this behavior. I have not quite made my mind up which way I
lean, to be honest. I'm interested in learning about the views on this from
the community.
For context, this has been previously discussed in the XSF Discussion MUC.
This is a link to the public message archive of that discussion.
https://logs.xmpp.org/xsf/2024-09-07#2024-09-07-78b71f7983a88d14
Kind regards,
Guus
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org