On 26 June 2015 at 15:45, Peter Saint-Andre - &yet <pe...@andyet.net> wrote: > On 6/26/15 6:46 AM, Matthew Wild wrote: >> >> On 26 June 2015 at 13:38, Peter Saint-Andre - &yet <pe...@andyet.net> >> wrote: >>> On 6/26/15 5:26 AM, Matthew Wild wrote: >> I'm not sure I understand completely, then. Are you proposing that the >> target of the SRV record is the XMPP host (and thus ignore the port?)? > > > I'm not sure I understand completely either. :-) > > We'll probably do something like this: > > _xmpp-client._tcp.talky.io. 400 IN SRV 20 0 5222 auth.talky.io > _xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io > > Naturally the ports might not be 5222 and such, but the general idea is that > we want to point guest users at a different auth service. By "SRV two-step" > I mean that the client would still need to resolve auth.talky.io or > anon.talky.io in the normal ways (we're not necessarily going to point > directly to what in draft-ietf-dane-srv we called the "connection > endpoint").
Right, as I suspected. So the flow would be something like: 1) Client knows it wants to connect to "talky.io" on XMPP, but it doesn't have credentials for that domain so it... 2) Attempts to resolve _xmpp-guest._tcp.talky.io, which returns: _xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io 3) This isn't a network-level connection endpoint, so it discards the port number and uses "anon.talky.io" as the XMPP service name in a usual connection attempt, so it 4) resolves _xmpp-client._tcp.anon.talky.io, etc. and once connected, authenticates using whatever mechanism it supports (ANONYMOUS, or whatever) As I mentioned, I completely agree with the principle, but I don't think the technique is ideal. I need to think about it more... :) Regards, Matthew
