I also feel like bare jid sending would have better behavior in the presence of multiple client connections. I don't see why you wouldn't want your existing conversations to follow you when you switch from one device to another.
It's not what clients do currently, though. I'm not sure whether it's wise to encourage such a fundamental change at this point. On Tue, 2007-12-11 at 21:22 +0100, Tomasz Sterna wrote: > On Wt, 2007-12-11 at 13:10 -0700, Peter Saint-Andre wrote: > > Because that's what it means to be in a chat session with someone -- > > you have a FullJID-to-FullJID connection, as it were. > > This is kind of "it is like this, because it is like this" answer. > > And as Robin pointed "a chat session" is a very fuzzy "definition". > > I still se no advantage in this approach. > And Robin and I pointed a few advantages of bare JID messaging. > > > > And remember that these messages are not necessarily human-readable > > text. What if you're sending a file via In-Band Bytestreams? Does half > > the file go to one resource and half to another? Ick. > > Is a IBB a "chat session"? Really? > This makes "chat session" definition even more fuzzy... > > > And I have a feeling of deja-vu. > We had this talk before and IIRC concluded that bare JID messaging is > better and is what we should recommend it and discourage the existing > full JID binding. > > Instead, we documented the full JID binding in RFC3921bis and encourage > it even more... :-/ > >
