On Dienstag, 29. Januar 2019 17:33:56 CET Georg Lukas wrote:
> 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.

+1.

> 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/>!

I don’t have a strong opinion either way. I suggest to use the path of least 
resistance and go with a condition already used by existing services. In any 
case, I think this is '45 material.

kind regards,
Jonas

Attachment: signature.asc
Description: This is a digitally signed message part.

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

Reply via email to