On Tue, 24 Feb 2009 09:14:13 +0000 Dave Cridland <[email protected]> wrote:
> On Tue Feb 24 00:31:25 2009, Pavel Simerda wrote: > > * bidirectional s2s could be announced in <stream:features> sent > > right after the opening <stream> tag from the initiator. > > > > > Well... > > What you need is to: > > a) Signal the ability of the receiver to handle features sent by the > initiator. Why? > b) Signal the ability of the initiator to handle bidi streams. Agreed. > c) Turn this on, which presumably involves an authorization phase. Ah, that'true... > > I was thinking that the receiver has a stream:feature to handle > stream:features, the initiator then sends these, If the reciever is not handling <features/>, it can ignore it, can't it? Peter said it was never forbidden to send them anyway. > and the receiver > can then proceed as the initiator in the other direction. So the > initiator would send SASL mechanisms, and the receiver would act as > a SASL client to the initator and request authorization. Some way or another, mutual authentication should be established, two SASL exchanges seem an obvious way to do that. > > > > * connection reuse for multiple s2s links would be a very useful > > feature, ask Dave for details > > > > > Piggybacking. > > What I'd like to do here is use the dialback elements as an > authorization request mechanism. What I would like... is to have an easy-to-understand and easy-to-implement piggybacking feature without unnecessary hassle. > In fact, by specifying how to do this without actually doing > dialbacks, but instead by verifying the identity of the sender based > on the X.509 cert, we can actually get rid of SASL EXTERNAL and just > use X.509 only, which eliminates the difference between the "first" > authorization and subsequent ones. I don't see any reason to get rid of SASL EXTERNAL. I quite like the concept of using the same authentication flows for all authenticated connections. It would be nice to be able to authenticate each virtual connection separately. It's a multiplex, anyway, if one associations fails, others should remain working. > > The dialback flow then becomes: > > 1) O2R : <db:result/> > 2) R: If TLS, and X.509 cert matches requested domain, goto ACCEPT > 3) R: Connect to A > 4) R2A: Establish TLS. > 5) R2A: If A's certificate matches O's, goto ACCEPT > 6) R2A: <db:verify/> > 7) A2R: <db:verify/>, goto ACCEPT > ACCEPT: > 8) R2O: Authorize O as requested domain, send <db:result/> > > > > * resource conflicts should be handled consistently in servers > > > > > It's not always possible to handle conflicts in the same way. Could you please be more specific? > > > > * an explicit way to kick other resources might be very handy > > > > > Here be tigers. > > > > * multiple resources could have a less confusing named feature (not > > unbind, but something like multi-bind probably) > > > > > I'm less than convinced about the validity of multiple resources as > a solution to any problem. It doesn't matter so much... it's an optional feature that seems to help someone. Anyway it's just c2s multiplexing, a counterpart to s2s multiplexing that you want. > > * xml:lang per stanza seems to be pretty rare, I would prefer MAY to > > SHOULD, or even to discurage per-stanza xml:lang entirerely and > > encourage use of xml:lang only for elements with localized > > strings. > > Many users (and also client developers) just don't care about > > languages. Unqualified strings are (and will be) very common, I > > would > > use MAY even for the elements. > > > > > In principle, the stanza-level xml:lang can be used especially over > S2S sessions to indicate a preferred language for errors. This doesn't seem to be too useful. We use language-neutral XMLish errors anyway, not localized errors (except additional info for geeks). > However... various protocols have had features like this for years, > and to the best of my knowledge nobody ever uses them. I'd guess this won't be used even when SHOULD... and I see no reason for the SHOULD for something that is generally considered useless. > > > > * "gone" has a very good usecase that could be made explicit... it > > is > > JID redirection and could be handled by clients (e.g. the client > > could > > offer the user to add the new JID upon error - presence/message > > would trigger it). > > > > > Right - a jid redirection would be useful. We'd also need to put > together a companion protocol for users to enable it. Would be nice. > > > > * Consider including XEP-198 Stream Management in the RFC > > We need to actually prove it, first. I don't think anyone's got as > far as coding it, yet. Prove or test? :D > Dave. -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
