jdev - 2020-04-24

Not really no.

XEP-0215 client implementers, do you implemente the <credentials/> thing at all?

Forwarded to conversations muc.

thx

Zash: > i don’t use credentials From Daniel

Mhm

Philipp tried to explain on the list but I still don't get the point of the seperate `<credentials/>` request.

Imagine handing out a HTTP Upload slot in every disco#info. That's what it does.

Dunno the XEP is a super-trivial request-response thing plus two different syntaxes to allow the client to filter the response list; neither of which allow the client to query just the single service it wants.

I don't see a generic implementation of 215 working this way.

At the same time a single tag (`<services/>`) has different syntax depending on whether it's used in the request or the response so you can't properly schema-validate it.

Zash, generic implementation of 215 working what way?

Holger: More like how mod_disco in prosody works, with other modules adding 'items' (features, identities, stuff) and then mod_disco composes replies from that.

Ah, right.

Gets awkward if those items are supposed to be dynamic.

Ah there's also the push support of course.

The <credentials/> query lets you limit your dynamicness ✏

And if it's something where it's expensive to produce those crendentials you don't wanna do that a lot just becasue the client wants to know what's available.

Heh, ok.

I implemented the `<credentials/>` thing anyway, glad to hear a reasoning why that might make sense 🙂

Or we might as well rename 215 "TURN/STUN query protocol" and drop the genericness

pep., yeah. My XMPP library doesn't.

"Holger> At the same time a single tag (`<services/>`) has different syntax depending on whether it's used in the request or the response so you can't properly schema-validate it." not in the xml schema (and I also find this meh) but you can have a In/Out Receiver/Sender foo/bar structure in the code for sure ✏

My library mostly just does (de)serialization based on XML-schema-like schemas. I can't tell it about in/out.

Zash, I think 0215 originally was STUN/TURN-specific and then switched to genericness.

Aha https://xmpp.org/extensions/xep-0215.xml#revision-history-v0.2

I would love for mine to do that but unfortunately it's not possible as schemas are (first not normative ?!?! but also) not always how you'd like to structure data :/

I think there's the same issue for <bind/>

and maybe others

Well it's just schema-like-schema 🙂 We invented our own thing to describe XMPP syntax.

Well then why is http upload its own completely separate thing?

But issues such as the `<services/>` thing are the same for us as for standard XML schema.

One of these days I might have to invent one of those too

Schema / data mapping thingymajigger

I now gotta check syntax within the query handling code rather than in the deserialization layer.

Separation of syntax and semantics checking might be sensible tho?

> Well then why is http upload its own completely separate thing? Good question.

Holger, re bind: BindQuery: https://gitlab.com/xmpp-rs/xmpp-rs/-/blob/master/xmpp-parsers/src/bind.rs#L15 BindResponse: https://gitlab.com/xmpp-rs/xmpp-rs/-/blob/master/xmpp-parsers/src/bind.rs#L73