XSF Discussion - 2022-02-23

do we have any XML experts here? are XSDs used in practice and do they matter at all?

context: XEP-0156 and the WebSocket RFC refer to host-meta XML format defined here https://datatracker.ietf.org/doc/html/rfc6415#appendix-A

that links to https://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html

which hilariously says: > The following URI will always reference the latest version of this file: http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.xsd

and that URL is a 404 hehe

but here is the real XSD https://docs.oasis-open.org/xri/xrd/v1.0/os/xrd-1.0-os.xsd

except, the example given in rfc6415#appendix-A is not valid according to that XSD

the XSD requires <Expires/> comes before <Subject/>

so: 1. it looks like we can add attributes and tags to <Link/> and it'll stay valid according to that XSD *if* they are in a different namespace 2. but does it matter? does anyone care if we *don't* namespace them differently?

Zash, re: our discussion the other day about incoming s2s sasl external and DANE, what about DNSSEC without DANE ?

example.org does DNSSEC and has xmpp.bob.com as a SRV record, when you connect, it gives you a cert for xmpp.bob.com, you trust it

what do you do when you get an incoming s2s claiming to be from example.org but giving you a cert for xmpp.bob.com ? lookup all SRV records over DNSSEC and offer SASL EXTERNAL if *any* of the names match ?

(do any implementations do this?)

345 is live now, isn't it?

We seem to have some applications not including the mandatory information.

Which is probably not surprising given that we don't make it easy to discover the mandatory information. I wouldn't know where to find it, for example. bylaws?

It's in 345.

But how one discovers that, I don't know.

Link from the wiki page?

Ah, no, the wiki *does* say what is mandatory.

So I think missing stuff off isn't a problem with discoverability at all.

It does indeed. To be fair, I haven't read the whole page since I first applied probably

> do we have any XML experts here? are XSDs used in practice and do they matter at all? XSD matter, just not in XMPP.

As they were never normative for XMPP, they're effectively stripped from their primary raison d'etre.

Wasn't there a question regarding bare vs full JIDs in subscriptions the other day? I just happened to stumble over RFC 6121 Section 3.1.1:

> When a user sends a presence subscription request to a potential instant messaging and presence contact, the value of the 'to' attribute MUST be a bare JID <contact@domainpart> rather than a full JID <contact@domainpart/resourcepart>,

Something Sam and me discussed in the Wordle MUC: "Spoiler warnings"... Anyone considered spoiler warnings in XMPP clients? I like the way they are implemented in Mastodon e.g. One could hide some sensitive information behind it. Of course needs Client support...

Guus, technically the question was about full JIDs in the roster, which isn't necessarily the same as having a subscription

Guus, but dangerously close, which is why I advised against allowing it (even though the RFC does not explicitly disallow it)

MattJ: I didn't recall the details. Just happened to read over this. :)

3.1.2 further says: > If the JID is of the form <contact@domainpart/resourcepart> instead of <contact@domainpart>, the user's server SHOULD treat it as if the request had been directed to the contact's bare JID and modify the 'to' address accordingly.

but, yeah.

sebastian, https://xmpp.org/extensions/xep-0382.html

HA... great... thanks MattJ

sebastian, implemented in at least Converse.js I believe, not sure what others

never seen it somewhere, didn't consider googling it... 😀

I was just about to post that :) I was filing an issue against Conversation to see if daniel would consider it.

mjk: what would be correct? can you create an issue?

emus: "for advancement to Stable." would be correct todayb seemed like a too tiny thing to open an issue for, but if you want, I'll do it ✏

Agh, how the hell did I manage to edit my message instead of writing a new one?!

emus: ↑↑

wurstsalat: does above make sense to you too?

mjk: is fine, Im on the run and did not wanted to forget

#1084 Now you won't :))

I hope I won't edit away _that one_ by mistake

mjk: thanks! if nothing works, feel free to use the comment function in the online pad

Alright!

thanks

the online pad is access for "additing" without account etc

Guus: that XRD thing isn't XMPP specific, though maybe we are the only users? But it's xsd is 404 and the example in the RFC doesn't validate

moparisthebest: I am not familiar with the XRD or its purpose - I was only talking about XSDs in general.

Guus: we use it for Bosh + websocket discovery

I was wondering if we could extend the XML, and if we need to bother with making our extensions validate with the xsd

moparisthebest: If we're defining that we adhere to an XSD but do not, we should simply drop the XSD reference.

it's somewhat analogous to claiming to do XMPP (and add the corresponding definitions in the stream elements), but adding other stanzas than IQ/presence/message to the stream.

Do not tell your consumers that you're adhering to a data structure definition, when you willingly do not: that will only lead to problems.

makes sense, thanks!

http://opensource.googleblog.com/2022/02/the-2022-season-of-docs-application-for-organizations-is-open.html