[Standards] XEP-0215: External Service Discovery

Philipp Hancke fippo at goodadvice.pages.de
Sat Apr 11 18:24:12 UTC 2020


Am 11.04.20 um 20:01 schrieb Holger Weiß:
> I stumbled over two things while adding XEP-0215 support to ejabberd:
> 
> 1. The "type" attribute specifies the "service type as registered with
>     the XMPP Registrar".  As far as I can see, no types are registered so
>     far; and at least to me, it's not completely obvious how (STUN and)
>     TURN over TLS services should be specified.  I see two ways:
> 
>     	<service type='turns' protocol='tcp' [...]/>
>     	<service type='turn' protocol='tls' [...]/>
> 
>     Personally I'd opt for the first one (to be consistent with e.g.
>     <https://tools.ietf.org/html/rfc5389#section-9>), but I don't care
>     much.  Either way, I guess this should be clearly defined.


TURN/TLS uris are of the form
   turns:host:port?transport=tcp
and this is mapping to
   https://tools.ietf.org/html/rfc7064
   https://tools.ietf.org/html/rfc7065
so type => scheme, protocol to transport

> 2. The XEP allows clients to either request the list of <services/>
>     (optionally limited by the desired service "type"), or to request
>     <credentials/> (limited by the desired "host", "type", and optionally
>     "port"; but not e.g. by the "protocol").  As credentials can be
>     included with the <services/> response, I don't quite see the point
>     of having a seperate <credentials/> request.  Wouldn't it make more
>     sense to allow the client to specify arbitrary <service/> attributes
>     (except maybe "username" and "password") with the <services/> request
>     for filtering the response, e.g.
> 
>     	<services type='turn' protocol='udp'/>
> 
>     and then drop the <credentials/> thing?

I think that was intended for the XMPP variant of 
https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00
but I don't think that variant was ever implemented.


More information about the Standards mailing list