It makes sense to me, given that XEP-0085's rules are overriding the general guidelines in XEP-0201.
I think the confusing part between the two XEPs is that they use the same example action in two different contexts. In XEP-0201, closing a chat window exemplifies merely disengaging from the chat session. In XEP-0085, closing a chat window exemplifies terminating a chat session. Similar but different semantics. Unfortunately, most clients treat closing a chat window as terminating the chat session, but that doesn't have to always be the case. Consider an app that works like Apple Messages does, which lists all of your recent conversations in a side bar alongside the main chat window, but can also pop open individual chats inside their own windows. Closing an individual chat session window in this case would be disengaging from a chat session, but the session is still alive (and listed in the conversations sidebar). Triggering a gone event would not be appropriate here. However, clicking the X to remove a conversation from the sidebar would be terminating the chat session, and trigger a gone event. Starting a new conversation with the same person (or the other person sending messages) should start a new thread. Of course, the recipient might never have received the gone, because they were offline at the time and the message was dropped. So if they wanted to continue sending a message in the same conversation, it would have the old thread id because it doesn't know otherwise. I would say there is an implicit business rule that maybe should be made explicit, which is that a client should handle receiving a message from a thread that it has tried to terminate; the chat session isn't truly "terminated" until the other side starts using a new thread id or the client starts using a new thread id itself. — Lance
smime.p7s
Description: S/MIME cryptographic signature
