XEP-0215 client implementers, do you implemente the <credentials/> thing at all?
Martin
Forwarded to conversations muc.
Zash
thx
Martin
Zash:
> i donβt use credentials
From Daniel
Zash
Mhm
Holger
Philipp tried to explain on the list but I still don't get the point of the seperate `<credentials/>` request.
Zash
Imagine handing out a HTTP Upload slot in every disco#info. That's what it does.
Holger
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.
Luciolehas left
Luciolehas joined
kikuchiyohas left
Zash
I don't see a generic implementation of 215 working this way.
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.
Holger
Zash, generic implementation of 215 working what way?
Zash
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.
Holger
Ah, right.
Zash
Gets awkward if those items are supposed to be dynamic.
Holger
Ah there's also the push support of course.
Zash
The <credentials/> lets you limit your dynamicness✎
Zash
The <credentials/> query lets you limit your dynamicness ✏
Zash
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.
Holger
Heh, ok.
Holger
I implemented the `<credentials/>` thing anyway, glad to hear a reasoning why that might make sense π
pep.
"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 for sure (and I also find this meh) but you can have a In/Out Receiver/Sender foo/bar structure in the code for sure✎
Zash
Or we might as well rename 215 "TURN/STUN query protocol" and drop the genericness
Holger
pep., yeah. My XMPP library doesn't.
pep.
"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 ✏
kikuchiyohas joined
Holger
My library mostly just does (de)serialization based on XML-schema-like schemas. I can't tell it about in/out.
Holger
Zash, I think 0215 originally was STUN/TURN-specific and then switched to genericness.
Zash
Aha https://xmpp.org/extensions/xep-0215.xml#revision-history-v0.2
pep.
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 :/
pep.
I think there's the same issue for <bind/>
pep.
and maybe others
Holger
Well it's just schema-like-schema π We invented our own thing to describe XMPP syntax.
Zash
Well then why is http upload its own completely separate thing?
Holger
But issues such as the `<services/>` thing are the same for us as for standard XML schema.
Zash
One of these days I might have to invent one of those too
Zash
Schema / data mapping thingymajigger
Holger
I now gotta check syntax within the query handling code rather than in the deserialization layer.
Zash
Separation of syntax and semantics checking might be sensible tho?
Holger
> Well then why is http upload its own completely separate thing?
Good question.
jdevhas left
pep.
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