XSF Discussion - 2020-04-22

MattJ: Let's replace XEP-0004 with https://www.w3.org/TR/xforms/

(I've yet to read all that so not sure if that should be /s or serious)

seems like the w3c is not doing simple specs ever (is it?)

https://xmpp.org/extensions/xep-0004.html https://xmpp.org/extensions/xep-0068.html https://xmpp.org/extensions/xep-0122.html https://xmpp.org/extensions/xep-0141.html https://xmpp.org/extensions/xep-0221.html https://xmpp.org/extensions/xep-0315.html https://xmpp.org/extensions/xep-0331.html https://xmpp.org/extensions/xep-0336.html https://xmpp.org/extensions/xep-0350.html

pep., I'd say we're doing allright

over almost 450 specs, I'm sure we can do better :p

So, those were all the XEPs I could find with "data forms" in the title.

I like how they have a section on how to read the document

in https://xmpp.org/extensions/xep-0115.html#ver-gen-simple in the example I see "S = 'client/pc//Exodus 0.9.1<'"

i think that // should be / there, no ?

Why?

Per https://xmpp.org/extensions/xep-0115.html#ver-gen > formatted as CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME].

LANG is empty string in that example

Hm

Type can be optional?

Do things do the thing with xml:lang being inherited when doing this thing?

I certainly hope so.

Link Mauve, prepare to be dissapointed

Would have been nice to separate the strings from the protocol advertising bits

at least xep390 explicitly mentions this

Meh, it’s only a SHOULD in the RFC…

Isn't that defined by XML itself?

If the initiating entity included the 'xml:lang' attribute in its initial stream header, the receiving entity SHOULD remember that value as the default xml:lang for all stanzas sent by the initiating entity over the current stream.

Section 4.7.4.

Zash, I meant adding the c2s stream’s @xml:lang to c2s stanzas.

Link Mauve: I meant having it added to the entire element tree, ie like xmlns.

Otherwise if you take out the <{disco#info}query> tag out of the <iq xml:lang="??"> you wouldn't know what lang it has

flow: while the PR isn't harmful, technically @xml:lang on the iq should equal the root's if it hasn't been redefined :x

"apply the XML rules"

jonas’: Why? Why isn't the XML parser library doing that? :(

good question

then again, there are still XML parsers which not only expose serialisation details like namespace prefixes, but require you to do the reverse mapping yourself

pep., true, but one could say the same for disco#info

hmm?

well you argue that iq inherits from stream, but disco#info also inherits from iq

at least libexpat deals with namespaces, but afaik prefixes are lost in translation

so we either say "beware that xml:lang is inherited", or explicitly mention all three sources of inheritance (instead of just two)

Or yeeeeet that and all human-readable strings out of the caps hash

ah I see. yeah I guess mentioning inheritance is more correct but that's nit

Zash, having the human-readable strings in the hash saves a round-trip though when you want to display that info

also lends its way to spoofing

Would it be too painful to have separate hashes?

yes

:(

though, maybe not

the idea to have separate hashes for identities / features / forms isn’t new

and I’m still pondering whether that’s a thing we might want

increases implementation complexity though

For the pure protocol bits it seems it could increase cache hit rate

(does jid x support feature y-kinda things)

indeed

and <identity/> is rarely needed for that kind of thing

another motivation for this is that forms may contain rapidly changing or high-cardinality data (see muc participant count)

flow, !

good idea to write down that concatenated hashes can be used if you don’t want to treat the split data

Truncated hashes is another way to reduce the size of the caps blob

jonas’, implementations could simply hash the multiple hashes if they don't want additional complexity ✏

Zash, didn’t you link a thing the other day which specified some way to refer to some hash functions including stuff like truncation and other parameters?

Not sure

should we maybe robots.txt-deny the attic?

Sounds sensible, yes

or at least have a fat warning on every thing there that it’s old

I was thinking of other far higher effort solutions

(that)

since when is sed high effort?

"Hey jonas’, ..."

I wrote an XMPP client within a day in sed, it can’t be that bad.

but yeah, first robots.txt, we can alleviate that at a later point when we get around to do a sed hack

Comic Sans?

haha, good idea

render the whole XEP in CS? cool!

does *anything* use xep4 <reported/> somewhere?

the only other occurence of <reported/> in the xeps repo, which I found, is xep390 ✏

flow: not aware of anything,