Hi,

two more XEP-0410 issues that were brought up in the MUCs:

It might make sense to create a *new* additional error condition in the
not-in-MUC error response, so that a client not wanting to implement the
different "ping error that is not an error" matches, and that relies on
the new self-ping-optimization feature, can match more easily on the new
error condition.

I'm not sure I like that general idea, but if it finds more proponents,
I'd rather make it in a way that allows to bring it into XEP-0045 later.

https://xmpp.org/extensions/xep-0045.html#enter-errorcodes goes to great
lengths to not introduce new conditions, but it might actually make sense
to have something like

        <not-an-occupant xmlns="http://jabber.org/protocol/muc"/>

in addition to the already generated condition.

The second point is the current 0410 not-in-MUC response. I've chosen
<not-acceptable> because it is what I get from the most widely used XMPP
server implementations, and because it is the corrent response for
attempting to send a message or a *PM*:

https://xmpp.org/extensions/xep-0045.html#privatemessage
> If the sender is not an occupant of the room in which the intended
> recipient is visiting, the service MUST return a <not-acceptable/>
> error to the sender.

However, after I was poked w.r.t. the correct condition, I found this
gem in the context of *disco* queries from a non-occupant:

https://xmpp.org/extensions/xep-0045.html#disco-occupant
> If a non-occupant attempts to send a disco request to an address of
> the form <room@service/nick>, a MUC service MUST return a
> <bad-request/> error.

Of course, there is no section on generic IQ requests from a
non-occupant, so we are free to design this in any way we want! \o/

It can be consistent with disco requests, or it can be consistent with
messages! Maybe we can even put all three contitions into the <error/>!


Georg

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to