On 26 Jun 2015, at 00:51, Peter Saint-Andre - &yet <pe...@andyet.net> wrote: > > Lance Stout and I had a conversation the other day about what we call "guest > access" to an XMPP application. As example, consider a chat service (text, > video, what have you) that has registered users and the ability for > registered users to invite ad-hoc users to a session or meeting. This kind of > functionality is quite common with applications like video conferencing > (Talky, Jitsi Meet, WebEx, etc.). > > If this kind of application is based on XMPP, the invited user needs to gain > access to the network (i.e., authenticate somehow) in order to join the > conference. However, for security and scaling reasons it makes sense to have > these ad-hoc users authenticate at a different place than the registered > users. (Often, but not always, the ad-hoc users might "authenticate" using > the SASL ANONYMOUS mechanism, but other methods are possible such as token > auth.) > > Thus we need a way for a client to discover where it can authenticate as an > ad-hoc or guest user. We don't want to use a DNS SRV Service name of > "xmpp-client" because that will point clients to the service endpoint for > registered users. What we came up with was to use a new DNS SRV Service name > of "xmpp-guest", which would point to the service endpoint for guest access. > > Has anyone else deployed this kind of pattern? If so, how did you solve the > problem of service endpoint discovery? Would you find it helpful to have a > DNS SRV Service name for this kind of access? > > If there is wide enough interest, I'd be happy to write a spec and pursue > registration of the service name with our friends at IANA.
I guess the two options are either another SRV entry, or using the standard client endpoint and then advertising after connection. I know a surprising number of people have issues with SRV, so that’s an argument in favour of doing a redirection in stream:features or the like, but SRV is the neater solution, I think. /K
