Old thread alert! I finally made time to read XEP-0296 more closely. In general, I agree that it would be helpful to describe the rationale for the various recommendations.
For example, we could expand on the core recommendations as follows (some text tweaks to existing text included)... ### 2. General Rules 2.1 Initial Conversation State Recommendation: A client MUST start a one-to-one chat session in the unlocked state, i.e., send <message/> stanzas to a chat partner's bare JID. Rationale: The partner's server has the most knowledge about how to appropriately deliver the message (e.g., to the partner's "most available" resource or perhaps to all of the partner's resources, a.k.a. "forking"). If the client tries to guess which resource is most appropriate for a one-to-one chat session, the initial message might be delivered to the wrong resource (i.e., a device that the chat partner is not actively using). 2.2 Locking a Conversation Recommendation: Once a client receives a chat <message/> from the chat partner, whether or not this client initiated the conversation, it MUST lock the chat session, i.e., remember the full JID from which the partner replied and send further chat messages to that full JID until one of the unlocking conditions occurs. Rationale: By replying from a given full JID, the chat partner has effectively indicated their preferred resource for one-to-one chat sessions at this time. 2.3 Unlocking a Conversation A client MUST unlock a chat session from a resource when one of the following conditions is met. 2.3.1 Message Receipt Recommendation: A client MUST unlock when it receives a <message/> stanza from a different resource associated with the chat partner's bare JID. When it unlocks the old resource, the client SHOULD lock onto the resource of the full JID from which it received the new message. Rationale: By sending a message from a different full JID, the chat partner has effectively indicated that the resource of that full JID is now preferred for one-to-one chat sessions. 2.3.2 Presence Receipt Recommendation: A client MUST unlock when it receives any <presence/> notification from any resource associated with the partner's bare JID, including <presence type='unavailable'/>. When it unlocks the old resource, the client SHOULD revert to the initial state by sending any further messages to the chat partner's bare JID (until and unless it locks onto a new resource). Rationale: Presence is availability for communication. By changing presence, the chat partner has indicated that there has been a change in its availability for communication. If the client tries to guess that the presence change is not "material" (i.e., that this presence change does not indicate a real change in availability for communication, for instance because the <show/> value has not changed), then subsequent messages might be delivered to the wrong resource. ### Naturally, you might disagree with the rationale statements I've provided, but I think they move us closer to understanding why folks disagree about the recommendations. (Terminology note: I prefer "chat partner" to the ugly "conversee" and we use the former term in RFC 6121. Also, let's make it clear that this applies only to messages of type "chat", and perhaps also "normal" if we agree about the latter message type.) On 8/22/11 4:33 PM, Matthew A. Miller wrote: > On Aug 21, 2011, at 04:24, Kevin Smith wrote: > >> I've been thinking about 296, and I'm still not happy with this >> 'unlock on any presence even if it's irrelevant' thing. >> >> My preference is to say something like: SHOULD (or MUST) unlock on >> a change of availability (available/FFC <> Away/NA <> DND <> >> unavailable) and MAY unlock on other changes. >> >> The current text, and Matt's preference is: MUST unlock on ... any >> <presence/> update. >> > > My preference is based on experience. Not everyone has interpreted > the use of <show/> the way we do. > > However, things did get slightly clearer between RFC 3921 and RFC > 6121. As implementations are updated, this will hopefully be less of > a problem. > > If we do make a change, it MUST also take <priority/> changes into > account. But at that point, is a client starting to reproduce some > of the server's own routing rules? Maybe unlocking on any presence > update (which, according to RFC 6121 § 4.4.1, SHOULD only to be > signal a change in availability) is more appropriate. > >> My argument is that unlocking on all presence will result in many >> messages being sent to the bare JID unnecessarily, which creates a >> bad experience for any users of multiple concurrent sessions and >> is exasperated by the clients putting extra details into their >> presence . >> > > It's not just clients putting extra details in. There are a number > of gateways into XMPP, and not all of them change show. If I recall > correctly, this behavior is often exhibited if the other end is MS > Lync (SIP-like) or IBM SameTime (SIMPLE). Note that both have XMPP > server-to-server connectors. > >> Matt's argument is that there exists a client that encourages >> people to never change availability and that it's more important to >> address this case. > > I guess I don't say more important, but that we be cognizant these > clients (and gateways). > > Also, a re-read of RFC 6121 seems to lead to a broader rule. > >> >> My suggestion to resolve this is to add a 'requirements' section >> to the start of XEP-0296 explaining what the objectives are. If we >> can agree on objectives, the rest should flow out sensibly. > > I've been thinking of what to put there. I am open to suggestions, > but it MUST to take the existing reality into account. > > > - m&m <http://goo.gl/voEzk> >
