XMPP Council - 2018-06-20

Anything on the agenda for today?

tedd sterr secretly trying to take over council chair?

I think it's fairly overt.

'tis time.

Who's here?

Oh hey, I appear to be here now and not silently dropped. *sigh* mcabber.

hi

We seem to not have a chair. So

1) Roll call

Me, Daniel and Sam, I think.

2) Isn't it nice that Tedd Sterr does the agenda?

3) Advance XEP-0363: HTTP File Upload

I'm afraid that without the agenda in advance, I failed to look at this again, so onlist for me.

I'm also on list; I'm still nervous about he http headers stuff being too restrictive.

+1

4) Deprecate XEP-0229: Stream Compression with LZW (and XEP-0138: Stream Compression)

+0 for both.

I'm missing context for this being on the agenda - does anyone remember the background?

didn’t we vote on that 6 month ago?

We have certainly had this come up before.

i think the background is 'insecurity'

Right, but I mean the background for why it appeared Right Now :)

not that i agree necessarily but that's probably why someone requested to deprecate

The last thing I can see was back in April when we decided not to advance it.

So I'm -0 on this right now.

daniel?

-0

5) Any outstanding votes people want to make now?

in general i think that compression is nice to have. maybe with proper business rules (resetting the compression when ever the address changes or something) this can be made secure and useful

that way the 100+ stanzas a server sends you with the archive can be compressed

I think that's a "no" for this one.

6) Date of next

SBTSBC?

wfm

Sam?

WFM

7) AOB

I agree with daniel about compression FWIW. I'm not against getting rid of it, but it also helped us massively at HipChat.

Clearly some sort of compression is desirable, as XMPP is used on poor links sometimes, and XML is heavily compressible.

Yes we should resurrect this soon ish

Whether that's these two XEPs, or EXI or whatever, I don't know, but I'm not sure deprecating at the moment is the Right Thing.

I think that's "No AOB" unless someone shouts imminently.

Yah, I agree.

Exi doesn't really seem in usable state

So, thanks all, we're done.

(Fini)

daniel: EXI itself, or the XEP?

Both

And compression with proper secure business rules is probably easier to do

Both

i like the idea of exi

but it doesn't seem achievable any time soon

EXI is a bit like 138 with preshared dictionaries, in effect, which is something that's been pondered about before.

(I use "a bit like" somewhat loosely here)

Except it also is extremely specialized (to XML) and doesn't have implementations anywhere. Meanwhile every platform, language, and even a lot of hardware have LZ4 and gzip implementations.

I mean the promise of exi is that you parse that directly instead of converting that to an XML stream first

Thus saving CPU time

At HipChat we actually saved CPU time from using zlib or whatever it was because encryption overhead is a lot higher and it reduced the number of packets that needed to be encrypted.

Since most people are using TLS these days (I hope), that seems like it would be pretty common.

Right. Yeah no argument here that gzip is beneficial for multiple reasons compared to plain

So depreciating stream compression will send the wrong signal I'm afraid. But someone should rework the xep and bump the NS

daniel: Except you'll end up converting to XML anyway, because good luck with your server design that is carrying two stream formats through it without an abstraction that looks a lot like a DOM.

To enforce the rules

That was 'except' in reply to "I mean the promise...".

Kev: yeah that's the problem I was talking about when I said it's not really usable right now

Both from the xep and the exi side