[Standards] XEP-0215: External Service Discovery

Philipp Hancke fippo at goodadvice.pages.de
Mon Apr 13 14:25:55 UTC 2020

Am 11.04.20 um 20:35 schrieb Holger Weiß:
> * Philipp Hancke <fippo at goodadvice.pages.de> [2020-04-11 20:24]:
>> Am 11.04.20 um 20:01 schrieb Holger Weiß:
>>> 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
> Makes sense, thanks.
>>> 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.
> I might be misunderstanding, but isn't Prosody's mod_turncredentials
> (which you wrote initially, I think) doing just that?

Yes. However it usually doesn't cover the case where new credentials 
need to be pushed (which is why we have example 5).

 From what I recall this kind of querying was added to support a case 
where you needed the same server but new credentials to handle refreshes 
of an allocation. This never turned out to be relevant and wasn't 
possible to implement in webrtc until quite recently.

> Either way I'm not sure how that relates to my point?  Which was mainly
> about the request syntax being redunant (plus semantics being limited in
> that the client can't filter by arbitrary attributes).

I agree with that one :-)

More information about the Standards mailing list