XSF Discussion - 2018-07-16

somebody with IETF strings may want to give them a hint that https://tools.ietf.org/html/draft-rescorla-tls-esni-00#section-4 may be not-cool for things not HTTPS

jonasw, why not just drop a mail to draft-rescorla-tls-esni@ietf.org, possibly cc'ing standards@?

I didn’t even know that address

do I need to subscribe somewhere before posting?

jonasw, no

Jul 16 12:34:11 c2s56231cdf2b10 debug Received[c2s_unbound]: <inactive xmlns='urn:xmpp:csi:0'> Jul 16 12:34:11 c2s56231cdf2b10 debug mod_csi_battery_saver(9380): Client is inactive the first time, initializing module for this session Jul 16 12:34:11 c2s56231cdf2b10 debug Received[c2s_unbound]: <resume h='128' previd='2121b279-b0c2-47eb-9537-2bbdeb3e2c21' xmlns='urn:xmpp:sm:3'>

this is what you get for making CSI a stream setting and not a session setting. Sigh.

And that's how you get ants

Ge0rG, that's not yaxim, is it?

MattJ: no. yaxim is on sm:2

Ah yes

We had a heated discussion about what happens with CSI state on 0198 resume. Nobody thought about what happens if you do CSI *before* resume

Madness

Where's my "told you so" stamp, again?

I guess we should just all do what Ge0rG says from now on

enabling CSI before bind should just be forbidden.

jonasw: on what grounds? ✏

wait, I got pre-bind and pre-auth confused.

You could even CSI-inactive pre-auth.

But then the stream gets restarted, so meh.

csi-inactive pre-auth should be forbidden because the server might need to allocate resources for that.

(and it’s not essential to secure the authentication channel)

jonasw: then you can tell us the place where this should be forbidden?

okay, it's rather obvious with pre-auth, but how do you handle pre-bind / pre-resume

> Clients wishing to immediately go to the inactive state should do so after stream resumption. ... is not enough?

Holger: that's not even a SHOULD

Holger: and above server log shows that client authors don't listen

If the CSI state was per-session, would that help with such client authors?

They set CSI-active before resume and after resume the state is suddently inactive?

Anyway "stream resumption does not affect the current CSI state" sounds a bit like the server shouldn't mess with pre-resume CSI. The second half of the sentence, "which always defaults to 'active' for new and resumed streams" sounds like it should, though :-)

:/

Whatever. I'd just add a MUST to that sentence (clients MUST "do so after stream resumption"), problem solved. This is not how I'd do it if we started from scratch, but I wouldn't mess with the rules again without strong reasoning.

FWIW, there's no distinction on caps, so should and SHOULD are equivalent.

Kev: can you translate that into plain English please?

Holger pasted a sentence containing a should, and you said it wasn't a SHOULD. I was pointing out that should and SHOULD are the same word.

2119 doesn't say that words need to be in caps.

> These words are often capitalized.

Hehe.

but it's generally expected

It doesn't even say they SHOULD be capitalized.

I was actually tryign to parse "caps" as "entity capabilities", leading to confusion

Ge0rG: If you get a "told you so" stamp I want a t-shirt bitching about those SHOULDs everywhere.

You SHOULD NOT use SHOULD!

"You MAY use 'SHOULD' but it is NOT RECOMMENDED to rely on its implementation."

https://mail.jabber.org/pipermail/standards/2018-July/035247.html I don't really like to have to rewrite a new XEP when there is already one existing. I think that adds to the confusion of "What XEPs do I need to implement?".

There's already a XEP for sending 'file uploading' notifications?

pep., if you can add a feature to a XEP, you can also make a new XEP which only contains that new feature

there’s no problem with a XEP-XXXX which builds on chat states and specifies a new set of elements which may be used in combination with e.g. <composing/> to show that an upload is in progress

It's not forbidden to add a sub-element to <composing/>, outlining that it's actually uploading. That would be backward-compatible

lnj: ^

jonasw, yeah but why is that not the recommended way

pep., that is what matt said

Ah wait I got it wrong

Why is that the recommended way

he surely did *not* intend to say that XEP-0085 should be copied entirel

pep., why not?

Ah, it looks like Andrew did a similar thing there.

jonasw, hmm, ok I read that as copy 0085 and include whatever you need in it.

Andrew Nenakhov, hey, mind writing down your extension?

pep., no, create a new thing which only contains the new features and which builds on top of 0085

Andrew Nenakhov, also, any reason why you didn’t opt for a child of <composing/> or next to composing instead of an attribute?

Namespaced attributes aren't the best idea in XMPP.

nobody said "namespaced"

Shoving attributes into someone else's namespace is also not great.

somebody said "hack"

Kev, ooi why it's not the best idea?

Kev, good thing that attributes aren’t even associated with a namespace by default \o/

is it*

Because it's not widely used, because it's not advertised in the RFC?

jonasw: You know what I mean. Attributes on an element in someone else's namespace.

Kev, yeah.

pep.: Because it's not likely to work.

Kev, because lack of deployment then, right?

pep., namespaced attributes require namespace prefixes, and implementations historically had ..... issues with that.

pep.: Yeah.

which I don’t get.

jonasw: We don't use namespaced attributes in XMPP, therefore XMPP XML implementations don't typically support them, therefore we can't use them.

Meet circle.

Ok, I don't think lack of deployment is really an argument. I mean things change. People should follow, otherwise things break, and that's expected

pep., issue is, if people are using XML parsers which don’t support namespacing at all (which seems to happen, because I have no idea why) and which rely on default xmlns and dirty hacks... this will be bad

although technically such implementatinos should not have issues with routing such content at least

Well then they should fix their parser, problem solved.

one does not simply make an XML parser namespace-aware.

;)

jonasw, this issue is not specific to XML parsers.

YouknowwhatImean

not really. the xml parser is a core component. "fixing" it to support namespaces usually means: - exchange the entire XML parser and/or - re-write the entire interface between XML parser and your stuff on top of it.

Let me rephrase: the issue of people not updating/projects not staying up-to-date is not specific to XML parsers

yes

I wish we could use proper namespacing in all of XMPP.

we could save quite a few bytes with that.

We can in everywhere except attributes, I think.

e.g. by declaring the stream management prefix on the stream level

Ah, right, you want to declare prefixes.

I take it back :)

yes, proper namespacing I said :)

Well, it's a bit different.

Namespaced attributes we can't use because we can't use a representation that will be understood widely.

Everything else we can represent, you just would like to use a different representation. IIRC.

*IIUC

But either way, yes. Prefixes are likely to end badly.

Are namespaces actually a problem anymore? I've never noticed any problems

I guess it's an issue of making widely used implementations support them, and then in a few years we'll be able to start thinking about using them

When stable-releases have updated their crap

jonasw: So about the uploading notifications your suggestion is to just create a new XEP?

lnj, yes, wiht 0085 as dependency

OK, thanks

Zash: Not namespaces in general, no, they're required everywhere. But prefix definitions are, and therefore namespaced attributes.

Just send a new element alongside <composing/>, job done

MattJ: Alongside? I'd inside personally, although maybe it doesn't matter.

yeah I'd make it inside as well, otherwise you'd have to deal with a lot more cases

Kev, you may not have faith in things handling namespaced attributes, I don't have faith in them handling unexpected elements properly either

Nested ones, that is

That's kinda one of the core expectations of XMPP isn't it? That you can shove new (namespaced) elements more or less anywhere.

There are a number of places we have avoided doing this in the past

we also tried to put the <forwarded> and <message> alongside each other in Carbons. That didn't went well.

I doubt that using namespaced attributes in XMPP is such a big problem as ppl here believe. I never heard of an impl that had issues, which of course, doesn't mean that such a thing does not exists. But then again, most XML parser probably support namespaced attributes out of the box.

Hmm does xep85 schema try to actively forbid extension elements within? And yes I know that schemas are only considered informative, but still. I think if we extend xep85's extension elements would be a bigger problem than namespaced attributes.

flow, I once tried to pull the 'xmpp-stanzas' namespace up into a declaration on the <error> element, instead of duplicating it on each child

Had to revert because clients didn't like it

And that's a basic namespace thing

MattJ, :(

aioxmpp would love that

Which cliens?

well, aioxmpp would deal with it, but its lead developer would love it.

Zash, I forget, it was a long time ago and although I put a COMPAT I didn't list which

MattJ, when I started with aioxmpp, ejabberd failed to process such stuff, too

I believe that Swift would cope fine with prefixes for element namespaces, but likely get confused with namespaced attributes.

why?

I fail to find the difference

Because for one it's just coming out of the XML parser, and XMPP uses namespaced elements so that's in the abstraction. XMPP doesn't use namespaced attributes, so it's not in the abstraction.

mmkay

At least, ISTR it's not.

" It is conventional in the XMPP community for implementations to not generate namespace prefixes for elements that are qualified by extended namespaces" BTW. Non-normative, but at least a record that it's not done.

And with that, I shall vanish for the night.

have a good one