-
jonasw
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
-
flow
jonasw, why not just drop a mail to draft-rescorla-tls-esni@ietf.org, possibly cc'ing standards@?
-
jonasw
I didn’t even know that address
-
jonasw
do I need to subscribe somewhere before posting?
-
flow
jonasw, no
-
Ge0rG
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'>
-
Ge0rG
this is what you get for making CSI a stream setting and not a session setting. Sigh.
-
daniel
And that's how you get ants
-
MattJ
Ge0rG, that's not yaxim, is it?
-
Ge0rG
MattJ: no. yaxim is on sm:2
-
MattJ
Ah yes
-
Ge0rG
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
-
Zash
Madness
-
Ge0rG
Where's my "told you so" stamp, again?
-
MattJ
I guess we should just all do what Ge0rG says from now on
-
jonasw
enabling CSI before bind should just be forbidden.
-
Ge0rG
jonasw: why?✎ -
Ge0rG
jonasw: on what grounds? ✏
-
jonasw
wait, I got pre-bind and pre-auth confused.
-
Ge0rG
You could even CSI-inactive pre-auth.
-
Ge0rG
But then the stream gets restarted, so meh.
-
jonasw
csi-inactive pre-auth should be forbidden because the server might need to allocate resources for that.
-
jonasw
(and it’s not essential to secure the authentication channel)
-
Ge0rG
jonasw: then you can tell us the place where this should be forbidden?
-
Ge0rG
okay, it's rather obvious with pre-auth, but how do you handle pre-bind / pre-resume
-
Holger
> Clients wishing to immediately go to the inactive state should do so after stream resumption. ... is not enough?
-
Ge0rG
Holger: that's not even a SHOULD
-
Ge0rG
Holger: and above server log shows that client authors don't listen
-
Holger
If the CSI state was per-session, would that help with such client authors?
-
Holger
They set CSI-active before resume and after resume the state is suddently inactive?
-
Holger
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 :-)
-
MattJ
:/
-
Holger
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.
-
Kev
FWIW, there's no distinction on caps, so should and SHOULD are equivalent.
-
Ge0rG
Kev: can you translate that into plain English please?
-
Kev
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.
-
Kev
2119 doesn't say that words need to be in caps.
-
Holger
> These words are often capitalized.
-
Holger
Hehe.
-
Ge0rG
but it's generally expected
-
Holger
It doesn't even say they SHOULD be capitalized.
-
Ge0rG
I was actually tryign to parse "caps" as "entity capabilities", leading to confusion
-
Holger
Ge0rG: If you get a "told you so" stamp I want a t-shirt bitching about those SHOULDs everywhere.
-
Holger
You SHOULD NOT use SHOULD!
-
Ge0rG
"You MAY use 'SHOULD' but it is NOT RECOMMENDED to rely on its implementation."
-
pep.
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?".
-
Kev
There's already a XEP for sending 'file uploading' notifications?
-
jonasw
pep., if you can add a feature to a XEP, you can also make a new XEP which only contains that new feature
-
jonasw
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
-
Ge0rG
It's not forbidden to add a sub-element to <composing/>, outlining that it's actually uploading. That would be backward-compatible
-
Ge0rG
lnj: ^
-
pep.
jonasw, yeah but why is that not the recommended way
-
jonasw
pep., that is what matt said
-
pep.
Ah wait I got it wrong
-
pep.
Why is that the recommended way
-
jonasw
he surely did *not* intend to say that XEP-0085 should be copied entirel
-
jonasw
pep., why not?
-
Ge0rG
Ah, it looks like Andrew did a similar thing there.
-
pep.
jonasw, hmm, ok I read that as copy 0085 and include whatever you need in it.
-
jonasw
Andrew Nenakhov, hey, mind writing down your extension?
-
jonasw
pep., no, create a new thing which only contains the new features and which builds on top of 0085
-
jonasw
Andrew Nenakhov, also, any reason why you didn’t opt for a child of <composing/> or next to composing instead of an attribute?
-
Kev
Namespaced attributes aren't the best idea in XMPP.
-
jonasw
nobody said "namespaced"
-
Kev
Shoving attributes into someone else's namespace is also not great.
-
Ge0rG
somebody said "hack"
-
pep.
Kev, ooi why it's not the best idea?
-
jonasw
Kev, good thing that attributes aren’t even associated with a namespace by default \o/
-
pep.
is it*
-
pep.
Because it's not widely used, because it's not advertised in the RFC?
-
Kev
jonasw: You know what I mean. Attributes on an element in someone else's namespace.
-
jonasw
Kev, yeah.
-
Kev
pep.: Because it's not likely to work.
-
pep.
Kev, because lack of deployment then, right?
-
jonasw
pep., namespaced attributes require namespace prefixes, and implementations historically had ..... issues with that.
-
Kev
pep.: Yeah.
-
jonasw
which I don’t get.
-
Kev
jonasw: We don't use namespaced attributes in XMPP, therefore XMPP XML implementations don't typically support them, therefore we can't use them.
-
Kev
Meet circle.
-
pep.
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
-
jonasw
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
-
jonasw
although technically such implementatinos should not have issues with routing such content at least
-
pep.
Well then they should fix their parser, problem solved.
-
jonasw
one does not simply make an XML parser namespace-aware.
-
pep.
;)
-
pep.
jonasw, this issue is not specific to XML parsers.
-
pep.
YouknowwhatImean
-
jonasw
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.
-
pep.
Let me rephrase: the issue of people not updating/projects not staying up-to-date is not specific to XML parsers
-
jonasw
yes
-
jonasw
I wish we could use proper namespacing in all of XMPP.
-
jonasw
we could save quite a few bytes with that.
-
Kev
We can in everywhere except attributes, I think.
-
jonasw
e.g. by declaring the stream management prefix on the stream level
-
Kev
Ah, right, you want to declare prefixes.
-
Kev
I take it back :)
-
jonasw
yes, proper namespacing I said :)
-
Kev
Well, it's a bit different.
-
Kev
Namespaced attributes we can't use because we can't use a representation that will be understood widely.
-
Kev
Everything else we can represent, you just would like to use a different representation. IIRC.
-
Kev
*IIUC
-
Kev
But either way, yes. Prefixes are likely to end badly.
-
Zash
Are namespaces actually a problem anymore? I've never noticed any problems
-
pep.
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
-
pep.
When stable-releases have updated their crap
-
lnj
jonasw: So about the uploading notifications your suggestion is to just create a new XEP?
-
pep.
lnj, yes, wiht 0085 as dependency
-
lnj
OK, thanks
-
Kev
Zash: Not namespaces in general, no, they're required everywhere. But prefix definitions are, and therefore namespaced attributes.
-
MattJ
Just send a new element alongside <composing/>, job done
-
Kev
MattJ: Alongside? I'd inside personally, although maybe it doesn't matter.
-
pep.
yeah I'd make it inside as well, otherwise you'd have to deal with a lot more cases
-
MattJ
Kev, you may not have faith in things handling namespaced attributes, I don't have faith in them handling unexpected elements properly either
-
MattJ
Nested ones, that is
-
Kev
That's kinda one of the core expectations of XMPP isn't it? That you can shove new (namespaced) elements more or less anywhere.
-
MattJ
There are a number of places we have avoided doing this in the past
-
Ge0rG
we also tried to put the <forwarded> and <message> alongside each other in Carbons. That didn't went well.
-
flow
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.
-
flow
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.
-
MattJ
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
-
MattJ
Had to revert because clients didn't like it
-
MattJ
And that's a basic namespace thing
-
jonasw
MattJ, :(
-
jonasw
aioxmpp would love that
-
Zash
Which cliens?
-
jonasw
well, aioxmpp would deal with it, but its lead developer would love it.
-
MattJ
Zash, I forget, it was a long time ago and although I put a COMPAT I didn't list which
-
jonasw
MattJ, when I started with aioxmpp, ejabberd failed to process such stuff, too
-
Kev
I believe that Swift would cope fine with prefixes for element namespaces, but likely get confused with namespaced attributes.
-
jonasw
why?
-
jonasw
I fail to find the difference
-
Kev
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.
-
jonasw
mmkay
-
Kev
At least, ISTR it's not.
-
Kev
" 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.
-
Kev
And with that, I shall vanish for the night.
-
jonasw
have a good one