[Standards] various rfc3920bis feedback
pavlix at pavlix.net
Tue Feb 24 18:04:06 UTC 2009
On Tue, 24 Feb 2009 09:14:13 +0000
Dave Cridland <dave at cridland.net> 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.
> What you need is to:
> a) Signal the ability of the receiver to handle features sent by the
> 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,
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
> 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
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
> 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
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
Freelance consultant and trainer
in networking, communications and security.
Jabber, Mail: pavlix(at)pavlix.net
More information about the Standards