Peter Saint-Andre wrote: > > Let's assume the new path replaces the old path for stanzas directed > > from Romeo to the full jid of Juliet that Juliet used to negotiate the > > end-to-end stream. Now, of course, it's still possible to send stanzas > > to Juliet's bare jid: > > > > Q4. Should stanzas directed to a bare jid always be sent > > via the server, or should the client look at received > > presence stanzas from that jid and, if the client has > > a end-to-end connection with the resource of the > > highest priority, send it directly over the new path? > > I think that if you have an e2e stream, you would prefer to use that > (it's encrypted, after all).
Right. But there are some cases in which a server handles a stanza on behalf of a user. If you use the new path for everything (except the control messages and stanzas directed to other full jids), you'd have to inspect each outgoing stanza if it matches one of those cases, and if it does, send it over the old path for the server to be able to handle it. > > Q5. When an end-to-end stream is closed, should a client > > reject / store offline / send over the old path any > > further stanza that is directed to the full jid? > > It could lead to severe security issues if a user > > believes that communication is still secure. > > No! If Juliet terminates the e2e stream, Romeo's client needs to pop up > a big warning that communication is now insecure and give him the option > of negotiating a new encrypted channel. So, Romeo types in text chat message, hits ENTER and in the same second gets a big warning that communication is now insecure before the client was able to send the message over the secure path. Should that message be discarded/queued until a secure connection is available again? Then, which stanzas should be allowed to be sent over the unsecure path after the secure path has closed: messages no, service discovery, jingle IQs yes? Or should the message be delivered (->security problem)? Treating end-to-end streams like additional resources might help here: If the end-to-end stream is closed, the resource becomes unavailable and all stanzas directed to it are not delivered. The old path identified by a different resource identifier is used to re-establish the secure con- nection or may be used for unsecure text chat again (which due to the different resource identifiers usually takes place in a different tab/window). > > Q8. How are stanzas routed if there are two or more end- > > to-end streams between two entities? > > It's probably good to have only one. Why would you need two? Perhaps one > for file transfer and one for XMPP chat? > > > Q9. If only one end-to-end stream is allowed, what should > > happen if a second one is negotiated (e.g., is the > > old one dropped)? > > I don't think we would forbid more than one stream, but I also think we > wouldn't encourage it. Well, I don't need two end-to-end XML streams, but I have to write code that handles incoming requests for end-to-end XML streams. The question is how to behave in the case an end-to-end connection with the same full jid already exists: If I allow multiple connections, which connection should be used for which stanza? If I do not allow multiple connections, which connection wins? I, too, think that we should not forbid more than one stream but should not encourage them. The question which stanza to route over which path could be solved if each path was addressable. (If someone creates two end-to-end-streams, he obviously wants to use both.) --K.
