Thank you for looking at this. I think the suggestions are a worthwhile improvement.
I'll look at Kev's recommendation around single-resource optimizations, and reconcile the caps/chatstates concerns stated previously. - m&m <http://goo.gl/LK55L> On Oct 21, 2011, at 15:22, Peter Saint-Andre wrote: > 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> >>
smime.p7s
Description: S/MIME cryptographic signature
