On 2/24/09 2:14 AM, Dave Cridland 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. > > b) Signal the ability of the initiator to handle bidi streams. > > c) Turn this on, which presumably involves an authorization phase. > > I was thinking that the receiver has a stream:feature to handle > stream:features, the initiator then sends these, 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.
Interesting. I think we need a separate thread about this topic. I'll try to start that soon. >> * 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. I think that connection re-use is broader than dialback. > 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'm not convinced of that. Why get rid of SASL EXTERNAL? (It seems preferable to use TLS+SASL for both c2s and s2s.) And what does it mean to "just use X.509"? > 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/> Perhaps. :) >> * resource conflicts should be handled consistently in servers >> >> > It's not always possible to handle conflicts in the same way. What do we mean by "handled consistently"? >> * an explicit way to kick other resources might be very handy >> >> > Here be tigers. I'd rather punt on this one. What problem are we solving here, exactly? Can't we use XEP-0146 for this? >> * 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. I think we have consensus to remove this from rfc3920bis. >> * 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. > > However... various protocols have had features like this for years, and > to the best of my knowledge nobody ever uses them. So it seems. So perhaps Pavel's proposal is appropriate. >> * "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. http://xmpp.org/extensions/inbox/forwarding-delivery.html http://xmpp.org/extensions/inbox/forwarding-request.html >> * 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. Now we have Prosody on the server side and Lampiro on the client side. Time for some testing. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
