Tomasz Sterna wrote: > Dnia 27-08-2007, Pn o godzinie 10:03 -0600, Peter Saint-Andre > napisał(a): >>> Sally: Help. [multicasted to all 3] >> <message from='[EMAIL PROTECTED]/foo' >> to='[EMAIL PROTECTED]' >> type='chat'> >> <body>Help.</body> >> </message> >> >> NOTE: This is directed to the bare JID because Sally doesn't have any >> context about which resource will reply. In this case, yes it is >> encouraged to send to the bare JID, not the full JID. And yes, the >> message is multicasted to all 3 of the contact team's resources. >> >>> Joe: Please describe your problem. [to Sally] >> <message from='[EMAIL PROTECTED]/joe' >> to='[EMAIL PROTECTED]/foo' >> type='chat'> >> <body>Please describe your problem.</body> >> </message> >> >> NOTE: Joe sends from his full JID (stamped by his server) to Sally's >> full JID (previously stamped by Sally's server). Now they are in a "chat >> session" and will send to/from full JIDs the whole time. So this message >> is NOT multicasted to all 3 of Sally's resources -- it is delivered ONLY >> to her "foo" resource. > > IIRC exactly _this_ chatwindow to resource binding was discouraged. > Could clients developers take voice here? I do remember snoring, that > they would need to ditch the resource to window binding code.
It is recommended to send the first message to the bare JID, then after you receive a reply from a full JID to send to that full JID. What that means for chat *windows* is an implementation detail. See also: http://www.xmpp.org/extensions/xep-0201.html But you're a server developer so you don't have to worry about all that. >>> Sally: I cannot do XXX. [multicasted to all 3] >> <message from='[EMAIL PROTECTED]/foo' >> to='[EMAIL PROTECTED]/joe' >> type='chat'> >> <body>I cannot do XXX.</body> >> </message> >> >> NOTE: This is NOT multicasted to all 3 of the contact team's resources, >> instead it is delivered ONLY to Joe (the "joe" resource). However, on the model you describe, the initial message would in fact be sent to all three resources, so the following is possible: >>> Jeff: Hi Sally. Please describe your problem. [to Sally] > > And this? OK. It comes from /jeff resource. But shows where? Sorry, I missed the names. So yes, Jeff could reply to the initial message and he wouldn't know that Joe already replied. The result is confusion. Therefore, I would encourage people to use XEP-0142 (smarter handling on the receiver side) or XEP-0155 for this kind of functionality. Overloading [EMAIL PROTECTED] with extra meaning and having that account controlled by multiple entities introduces the possibility for confusion. > In the window labeled "[EMAIL PROTECTED]" (or any petname Sally had > given to this rosteritem) opened for Joe? These will be mixed with /joe > messages? No, IMHO that would probably be a separate window -- they are two different chats. See XEP-0201 for more. > In a separate window? How should it be named? Two windows of > "[EMAIL PROTECTED]"? Probably. See above on the strong possibility for confusion here. > And if so, this would break functionality for normal users changing > resources. Every time I would switch /work to /mobile, the conversation > that is going with me to /mobile would appear in a separate window at my > contacts PC. Not nice. There is no "chat handover" protocol. Usually this is handled socially right now ("switching to my mobile, will chat with you from there"). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
