Hey Guus,

I'm not entirely sure it matters if additional stanzas are sent, as long as they're not confusable with the other stanzas that are sent as part of the join.

By way of example, the self-presence essentially signals the end of the occupant presence, and the room subject signals the end of the history.

If a message were transmitted before the room subject, it might be treated as part of the history. Similarly, if presence is sent prior to the self-presence, it's going to be treated as an occupant presence (or might be).

Non-XEP-0045 presence - like your other contacts - might be interleaved anywhere, but can't be confused with room occupant presence. Bare jid from the room itself prior to the self-presence might confuse some clients, though in principle it ought to be safe since it's not a full-jid presence. I'd be curious how clients react, though.

Dave.

On Fri, 18 Oct 2024 at 18:50, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:
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@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@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org


_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org