* Philipp Hancke <fi...@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? 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). Holger _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
