On Sat Apr 11 00:24:45 2009, Peter Saint-Andre wrote:
> 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.)
But we're not - SASL EXTERNAL is, essentially, a way to say "I don't
want to use SASL". Given that, and given that our protocol
architecture doesn't require a SASL step at all, we may as well drop
that pretense. (Unless we really want to use anything else but
EXTERNAL on S2S links).
And what does it mean
to "just use X.509"?
Aside from SASL, I mean - so the basis of a server's identity becomes
the X.509 certificate, which we're using already.
> 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. :)
Philipp's suggestion of splitting the matter of authentication
request and verification in XEP-0220 makes this clearer, since there
are then multiple ways of verifying, but only one way of requesting
authentication.
>> * 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"?
I would assume statements such as "The new connection wins, and the
old one is disconnected", or some such. That's not always possible -
consider the case of a split cluster, where one node knows that a
conflict exists, but cannot signal that to the other node. In this
case, the best option is to allocate a new resource, yet wherever
possible one should test and kill the "old" session and replace it.
>> * 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.
Well, if you're going to markup anguages, then unless we mandte what
that language must be, we'll have a mixture over S2S channels, in
which case you have to markup per-stanza.
>> * "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
I'll read up.
>> * 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. :)
For XEP-0198? I thought they'd only done XEP-0237?
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
