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.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
