On Jul 14, 2013, at 1:13 PM, Mathieu Pasquet <[email protected]> wrote:
> On Sun, Jul 14, 2013 at 05:36:51PM +0100, Kevin Smith wrote: >> On Sun, Jun 9, 2013 at 7:40 PM, Mathieu Pasquet <[email protected]> >> wrote: >>> I was starting to implement carbons in poezio when I came across some >>> kind of design issue that I haven’t been able to work out. >>> >>> As I understand it (and in the use case explained in the introduction), >>> Carbons provide a way to minimize the nuisance of changing devices, by >>> providing all the messages with 'chat' type to all the carbon-enabled >>> clients. >>> >>> The requirements also state that “All clients that turn on the new >>> protocol MUST be able to see all inbound chat-type messages”. >>> >>> However, in the case of private MUC messages (XEP-0045, 7.5), the >>> messages are also of type 'chat', causing them to be forwarded as normal >>> chat messages. But the other resources are not necessarily present on >>> that MUC, so they will receive the messages just fine, as with any >>> direct conversation with a fulljid, but they won’t be able to reply, >>> because I believe most MUC implementations will check the fulljid and >>> reply with an error. >>> >>> I can’t think of a straightforward solution to this issue, as the server >>> doesn’t know about MUC, neither does the other resource. >>> >>> On the sender part, it might be solved by including a <private/> with >>> each message sent through such chats, but on the receiving part, AFAIK >>> there is no way to distinguish those. >>> >>> I think the XEP should cover that case, because it is rather common to >>> have private conversations with people in a groupchat, and letting >>> clients guess how they should handle the message is very error-prone. >> >> Could you disco any unknown JIDs to see if they're users or MUCs? >> >> /K > > Yeah, that’s what I went with (I had forgotten about it at the moment of > writing that email). > > I think the XEP should indicate such a behavior, as a client developer > might forget about this case. > > Or even better, maybe the server could perform that disco, although I > get that making changes to already-deployed implementations might be > painful. > > -- > Mathieu Pasquet (mathieui) > This makes sense; I'll try to get this added in the coming weeks, post-IETF (-: - m&m Matthew A. Miller < http://goo.gl/LK55L >
smime.p7s
Description: S/MIME cryptographic signature
