[Standards] various rfc3920bis feedback

Dave Cridland dave at cridland.net
Tue Feb 24 09:14:13 UTC 2009

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, 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.

> * 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.

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.

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.

> * 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.

> * 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.

> * "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.

> * 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.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list