18 Oct
2024
18 Oct
'24
8:45 a.m.
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
18 Oct
18 Oct
10:07 a.m.
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
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
2:43 p.m.
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(a)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(a)hoerist.com>
wrote:
Hi,
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
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
30
days inactive
30
days old
3 comments
3 participants
participants (3)
-
Dave Cridland -
Guus der Kinderen -
Philipp Hörist