[Standards] various rfc3920bis feedback

Pavel Simerda 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.
> > 
> > 
> 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



More information about the Standards mailing list