>That sounds awfully like a MAY. SHOULD is "MUST unless you know what you're
>doing, and you probably don't".
Sure. I'd rather it be non-normative, or even omitted, but that's not a
change we can make at this stage I think.
>I'm also unconvinced that specifying whether clients leave chatrooms or not
>when things happen is "UX" - it's client behaviour, and that seems entirely
>within the remit of a XEP.
I disagree. Client behaviour, especially user-visible behaviour, is exactly
UX and is up to the developers of the app based on their use case, etc.
I think there's many shades of grey between the extremes of "this should be presented to the user in a purple dialog box" and "the client SHALL leave the chatroom".
There's lots of things that affect the user experience in all manner of ways. We shouldn't prescribe how these are presented, certainly, but the fact they happen is important.
Or at least might be - the key to my mind is if you have two clients, one of which expects that setting autojoin to false (in this case) will cause all clients to leave, and the other does not, is this going to create a horrible UX due to the interoperability gap?
I would personally expect that removing a bookmark entirely would (reasonably) cause clients to leave the chatroom - but merely removing autojoin would simply cause the clients not to join automatically in future. Some clients might choose to leave, others might not, depending on whether they consider the room to have been "only autojoined". Otherwise, setting autojoin to false is the same as a retraction, which seems to me like the autojoin flag is entirely redundant, and should simply be removed.
(It reminds me of an IMAP client issue from about 25 years ago, where some clients would immediately EXPUNGE messages with the \Deleted flag set, whereas others treated the \Deleted flag as temporary "trash can", from which messages could later be recovered if needed, and EXPUNGE as the "empty trash can" UX. The latter was actually the intent of the spec, and if you used multiple clients, the immediate-EXPUNGE type would constantly "empty the trash can" of the other.)
>experience, too, but that's OK, as many things we do have an effect on UX.
>We assume, for example, that if you send a message to a client it'll be
>visible to the user sitting in front of it
We perhaps commonly assume this, but we don't require it in the spec and
indeed there are clients which ignore various messages based on various
criteria and I think that is a valid thing for them to do.
As Kev notes, we actually do require it in various places.
But whether a client leaves a chatroom and when is absolutely a protocol behaviour, and we should stipulate it firmly (ie, with normative language) if there's an interoperability concern - as, indeed, XEP-0402 has done since JC and I wrote it.
Dave.