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.
* 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.
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
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.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
