On Thursday 05 March 2009 05:45:09 Guillaume Desmottes wrote: > First, the XEP is unclear about JID's usage when trying to establish a > bytestream with a muc contact (for example to send him a file).
Yes, S5B is totally busted with MUC JIDs. We mostly brushed this off, saying that you have to use real JIDs. I think it is not unreasonable to require using real JIDs for a P2P connection, if only we had a better way of communicating the JIDs (e.g. trading them in the file transfer exchange, rather than requiring a non-anonymous MUC). > C) When activation failed (or if the initiator can't connect to the > proxy for any reason), the initiator is never informed of the failure > and think the bytestream is open. You mean the target is never informed. > A) We should always MUC JID's so we don't restrict ourself to > non-anonymous muc. Do we have to require their use? Is there a harm in using real JIDs even if both peers are in a MUC? I don't think this needs to be specified. > B) The activation IQ should contain the initiator JID instead of > assuming it from the "from" attribute of the IQ. This may be fine, but, does it open up any security issues? People hijacking proxy connections by spoofing initiator JIDs? > C) We should add an extra IQ round trip between the initiator and the > target. Once the initiator got the activation IQ reply, he sends an IQ > to the initiator to inform him of the success (or failure) of the > operation. The target shouldn't consider the bytestream as open while he > don't receive this IQ. I'd have to think more about this, but maybe it's fine. Of course, your modifications would have to be optional extensions, to ensure backwards compatibility. -Justin
