- Expired calls:
- LC for XEP-0280 expired without feedback.
- Calls in progress:
- LC for XEP-0320 (ends at 2020-05-19)
- LC for XEP-0339 (ends at 2020-05-19)
jonas’
+ a protoxep
jonas’
4) Items for Voting
Ge0rG
I wonder why nobody commented on Carbons.
jonas’
4a) Decide on Advancement of XEP-0280: Message Carbons
URL: https://xmpp.org/extensions/xep-0280.html
jonas’
everyone is worn out about that probably
Ge0rG
I'm torn about it.
Zash
I just started looking at carbons (the code) again recently
daniel
yes. i don’t even have an opinion on that anymore
Ge0rG
I like most of the XEP, except for this one line:
> it contains payload elements typically used in IM (...)
Ge0rG
Personally, I'd rather roll back Carbons and fix message routing, than entrench the mess. But that's not going to happen, so... 🤷
Zash
It's already entrenched tho
Zash
IM-NG can obsolete it when it's ready :)
daniel
Ge0rG, well some time before the summit I thought so too. (see my emails from january) but after more discussions during summit I came to the conclusion that im-ng isn’t going to be easy either
daniel
and share a lot of the problems with carbons
jonas’
it won’t indeed
Zash
Is anything ever easy?
jonas’
though having clear semantics is a good start
Ge0rG
daniel: right. My hope was that we can invest some work into Carbons to make IM-NG profit from the rules later on
Ge0rG
jonas’: yes, the fallback rules would be only for legacy-interop
daniel
yes we won’t get around of defining some ruleset probably
daniel
or start over with the whole pubsub mess
daniel
sorry; rambling; all that is to say that i don’t know what to do with carbons status wise at the moment
Zash
With my Implementer Hat on, I have something slightly different from the rules in the XEP now, which might be better, or not. Going to need some time and deployment experinece with it I think.
Ge0rG
daniel: you could check whether §6.1 is sufficient and adequate for all your use cases.
daniel
does it cover jingle messages?
Ge0rG
Zash: that sounds like we should postpone advancing Carbons
Ge0rG
daniel: are jingle messages of type=chat?
daniel
well you can make everything type chat
Zash
And/or extend the LC, tho I'm not sure I'll have energy to post about it in the next to weeks either.
daniel
but usually (following the examples from the xep) they are not
Ge0rG
or is jingle one of the gazillion XEPs that don't define an appropriate message type?
Ge0rG
I want Carbons and MAM sync to become type=headline
Zash
One thing: The new mod_carbons acts on anything that's been archived.
daniel
Conversations makes them type chat to get around 6.1 rules
daniel
but arguably they probably maybe shouldn’t be?
Ge0rG
daniel: what about fixing §6.1 rules instead?
Ge0rG
Zash ~volunteered~ proposed to fix https://xmpp.org/extensions/xep-0226.html
jonas’
I wonder whether we need a routing-WG like we had (have) an E2EE WG
daniel
but yeah that's the point? so do we have to touch 280 every time there is a new xep around?
Zash
jonas’, good idea
daniel
and subsequently all implementations
Ge0rG
I suppose Carbons has no meaning outside of IM anyway, and Jingle is kinda-sorta-IM now
jonas’
daniel, supposedly, since you send to bare-JID (under IM-NG rules) this would be broadcast✎
Ge0rG
jonas’: that would be good
jonas’
daniel, supposedly, since you send to bare-JID (under IM-NG rules) this would be multicast to all resources ✏
Zash
also, is there a Jingle WG that could comment on this batch of Jingle XEPs?
jonas’
which is one of the key reasons for IM-NG, so that we don’t have to touch things every time a new protocol comes aroundy
daniel
but because of backward compat you still have to have rules
Ge0rG
is there any single implementation of `urn:xmpp:carbons:rules:0` ?
jonas’
I see a few people who have a certain share in implementations (daniel, Holger, Zash, Ge0rG, someone from the Dino folks, lovetox) which could sit down for a sprint and work out rules for different use cases.
Ge0rG
daniel: yes, and we need to define those rules
jonas’
and who could drive IM-NG forward
jonas’
I think this is most direly needed
Ge0rG
jonas’: I agree.
jonas’
daniel, you have the compliance checker to pressure people to deploy an update
Zash
Ge0rG, I /think/ Prosody actually does something very close to the rules in the XEP
Ge0rG
most of the rules we sort out will apply equally to IM-NG, Carbons and MAM
Zash
As in, the stable release. Trunk now does something else.
jonas’
can someone of you folks take the hat for this sprint?
Ge0rG
Zash: the delta would be a good addition to the 0280 LC
jonas’
because we won’t solve this in this session.
jonas’
I’ll be happy to move 280 back to Experimental in that case
Ge0rG
I'm not good at organizing.
Zash
jonas’, sure
jonas’
Zash, thank you very much
daniel
+1 moving it back
Ge0rG
But I'm motivated to bring 0280 + IM-NG rules into a sane state
jonas’
I can offer a jitsi meet instance for a virtual meeting, though I suppose you’ll find other instances, too
jonas’
so Zash will organize a virtual(?) sprint on that one; please announce it on standards@ and also ping ejabberd, dino and gajim devs at least
Zash
jonas’, +1 for back to experimental.
Zash
also +1 to whoever invents <in-reply to=id/>
jonas’
Zash, was that in implicit "I didn’t want to volunteer for organizing this!!!"
Zash
yes
jonas’
darn
jonas’
ok, then I’ll step up to try to get everyone on a table, but I won’t actively participate most likely
jonas’
4b) Request LC for XEP-0393: Message Styling
URL: https://xmpp.org/extensions/xep-0393.html
Abstract: This specification defines a formatted text syntax for use in instant messages with simple text styling.
jonas’
+1
daniel
+1
danielgrabs popcorn
Zash
+1
Zash
LC all the XEPs?!
Ge0rG
+1
jonas’
4c) Proposed XMPP Extension: Channel Binding Pseudomechanisms
URL: https://xmpp.org/extensions/inbox/cb-pseudomechanisms.html
Abstract: A method for advertising and negotiating types of channel binding
supported by SCRAM based SASL mechanisms.
jonas’
even more so than with the previous spec about password storage, I’m fairly certain that this needs to be addressed on the IETF-level✎
jonas’
-1, even more so than with the previous spec about password storage, I’m fairly certain that this needs to be addressed on the IETF-level ✏
Zash
I approve of the general goal tho.
jonas’
me too
daniel
> I approve of the general goal tho.
+1
Ge0rG
on-list
jonas’
hm, I’m changing my vote to on-list.
jonas’
I have to read it more closely
SamWhited
This will *never* be addressed at the IETF level, FWIW. The XMPP WG is shut down and this is protocol specific.
jonas’
SamWhited, yeah, I just realised that
jonas’
so going on-list, because I’m not sure that mangling the mechanism names is a great way to do that
daniel
But the approach feels wrong
jonas’
yeah, a lot wrong
jonas’
if only we had namespaced attributes
Zash
on-list
daniel
If only we had namespace attributes
daniel
Lol
Zash
I'd like to have Dave around to discuss this one
jonas’
let’s not discuss protocol specifics in this meeting; I’m assuming you’re on list too, daniel?
daniel
Yes on list
jonas’
5) Outstanding Votes
I lied in the email, there are no outstanding votes.
(pretty sure I'm -1 but I want to elaborate more on list)
jonas’
there is the RIPE General Meeting and I was appointed responsible for doing on behalf of my company which is a LIR there
jonas’
I’m not sure what the schedule is and when I’m expected to participate there, so I can’t say for sure I can chair the meeting here
jonas’
I’ll prepare an agenda on tuesday, who volunteers to chair?
SamWhited
Please let's have a discussion on list before you all finish voting if possible. I'm open to being convinced of alternative methods, but the ones I could think of were much more obnoxious to implement or required major modifications to our SASL profile (which is not likely to happen)
jonas’
SamWhited, I’m going to reply on-list soon
SamWhited
But I also knew this method would be an uphill fight :)
Zash
Something something XEP-0388
SamWhitedshuts up and lets you finish the meeting.
jonas’
yes, thanks
jonas’
we’re at Date of Next, and we need a chair for next week
daniel
i can chair
jonas’
Thanks
Zash
so +1w then
jonas’
excellent
jonas’
7) AOB
jonas’
none from me
Zash
none here
jonas’
alright
jonas’
8) EOM
jonas’
thanks all
Zash
ACK, FIN, RST
dwdhas joined
dwd
Well, taken me all afternoon, but I can apparently get in this room again.
jonas’
\o/
Zash
Äntligen!
Ge0rG
dwd: how many yaks did you shave today?
dwd
Not enough. I don't *think* I can connect outbound and establish TLS to this server, and I do not understand why.
Zash
_this_?
Zash
`locate iteam-hat`
dwd
Zash, As in xmpp.xmpp.org. But not just this one, cerdale.zash.se is the same.
Zash
If mine doesn't want to talk to you it should send you a <stream:error> with the reason
dwd
TLS negotiation fails, though, so no opportunity.
Zash
I see you → here connections, but unencrypted in the other direction
dwd
Right, because Openfire can actually fallback to retry without TLS.
dwd
Which is what's happened here I think.
Zash
for reverse connections?
Zash
crazy
jonas’
May 06 15:12:15 s2sin5578e86691d0 debug Incoming s2s received <stream:stream xmlns='http://etherx.jabber.org/streams' version='1.0' to='xmpp.org' from='dave.cridland.net'>
May 06 15:12:15 s2sin5578e86691d0 debug Sending[s2sin_unauthed]: <stream:stream id='3bdeff5f-b26a-4635-a2d6-1d37c1ab1db9' xml:lang='en' xmlns='jabber:server' to='dave.cridland.net' xmlns:db='jabber:server:dialback' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' from='xmpp.org'>
May 06 15:12:16 s2sin5578e86691d0 debug Incoming s2s received <stream:stream xmlns='http://etherx.jabber.org/streams' version='1.0' to='xmpp.org' from='dave.cridland.net'>
May 06 15:12:16 x509 debug Cert dNSName dave.cridland.net matched hostname
May 06 15:12:16 s2sin5578e86691d0 debug Sending[s2sin_unauthed]: <stream:stream id='57b0f2aa-5f41-4a53-ba20-3e5c8686952a' xml:lang='en' xmlns='jabber:server' to='dave.cridland.net' xmlns:db='jabber:server:dialback' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' from='xmpp.org'>
May 06 15:12:16 s2sin5578e86691d0 info Incoming s2s stream dave.cridland.net->xmpp.org closed: stream closed
May 06 15:12:16 s2sin5578e86691d0 debug Destroying incoming session dave.cridland.net->xmpp.org
jonas’
that doesn’t seem useful
dwd
Sorry, distracted by Atlassian apparently having a dodgy cert on their cloud hosting.
Zash
I see some failed attepmts at dialback and some timeouts
dwd
That would have been earlier, I suspect.
Zash
after what jonas’ posted
SamWhited
I get a *lot* of errors from your server as well, dwd. Mostly useless things about being unable to connect.
SamWhited
FWIW
dwd
How bizarre.
Zash
May 06 15:13:46 s2sout5578e7a3df20 debug Destroying incomplete session xmpp.org->dave.cridland.net due to inactivity
Zash
May 06 15:12:17 s2sout5578e7a3df20 debug sent dialback key on outgoing s2s stream
Ge0rG
TLS version mismatch?
Ge0rG
something like TLS 1.0 vs TLS 1.2? dh keys?
jonas’
2020/05/06 17:54:43 failed to probe c2s to xmpp:cridland.net: dial tcp 74.125.28.125:5269: connect: connection refused
dwd
Yeah, not cridland.net
dwd
dave.cridland.net
jonas’
also, why does it write c2s
dwd
Anyway. More usefully:
Zash
Huh, but this one is TLS'd
dwd
XEP-0280 - I thought we'd discussed this in the Summit and come to some kind of conclusion abotu moving the routing rules themselves into a new XEP, that would be pointed to by IM-NG on the basis that IM-NG was Carbons with better PR^Wsyntax?
Zash
May 06 15:12:17 s2sout5578e7a3df20 debug Sending[s2sout_unauthed]: <stream:stream xml:lang='en' xmlns='jabber:server' to='dave.cridland.net' ...
May 06 15:12:17 s2sout5578e7a3df20 info Stream encrypted (TLSv1.3 with TLS_AES_256_GCM_SHA384)
dwd
Yeah, from * -> dave.cridland.net it negotiates TLSv1.3 and AES etc.
Zash
Then it does dialback, which times out. Then some time later it tries again
dwd
So:
dwd
4a) On-list, I need to look at what was discussed at the Summit.
dwd
4b) +1
jonas’
I admit I speculated you’d take time to vote on 4b so that we don’t have three LCs starting within just 24 hours ;-)
jonas’
still, welcome back
undefinedhas left
dwd
4c) I'm somewhat torn about this. It's a revolting syntax, but I wonder if just listing channel bindings, and mandating that sorry, but if you offer it for one it's offered for all mechanisms, might be preferable. As to whether this lives here or IETF, I'm inclined to say it lives here - as Sam notes, XMPP-WG is dead, and KITTEN is probably not ideal, though definitely worth talking to Simon Josefsson there as he's discussed this kind fo thing before quite recently. So Sorta +1 but dear dog can we change this?
Wojtekhas joined
jonas’
dwd, I think quite similar as you do, and I think we should discuss those specifics on-list
dwd
By which I mean, on-list to give me some time to think, but if it weren't using pseudo-mechanisms I'd be a firm +1.
undefinedhas joined
Neustradamushas left
pep.
If only we had namespace attributes
dwd
I'm not sure those help here.
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
debaclehas left
sonnyhas left
sonnyhas joined
Wojtekhas left
sonnyhas left
sonnyhas joined
danielhas left
danielhas joined
Wojtekhas joined
debaclehas joined
robertooohas left
raspbeguyhas joined
danielhas left
danielhas joined
Neustradamushas joined
Tobiashas left
moparisthebesthas left
moparisthebesthas joined
debaclehas left
sonnyhas left
SouLhas left
dwd
Scribbled that listwards, and I'll vote +1 on 4c).
undefinedhas left
Zash
I'm not sure how I feel about "(oh btw channel bindings in TLS 1.3 are undefined)" hidden away in an appendix in an RFC that doesn't update the channel binding document.
dwd
Zash, Channel bindings are in general a bit stalled. I think the XMPP community is the only group that really cares, sometimes, and we're not very vocal within the IETF, so they probably don't realise there's interest.
SamWhited
The two channel bindings it's talking about are broken anyways, and I assume even more broken on TLS 1.3 because they won't work in-0RTT mode (I think)
SamWhited
I'm only guessing, but I assume that's why they decided to just say that they're undefined. Libraries won't be able to give you the data half the time, or even worse, they will try to give you non-unique data
Zash
Found a single thread from 2015 discussing it
SamWhited
Link? I didn't find anything when I looked
dwd
SamWhited, And by the way, you're doing a great job in KITTEN, pushing this stuff. It probably feels like you're getting nowhere, but I think it's making an impact slowly - but the recent last-minute-virtual IETF meeting has probably drained people of energy.
SamWhited
dwd: thanks; I was worried I was beign a pest, I never know how the IETF works or how much I should stay on top of things
SamWhited
being, even
Zash
SamWhited, not sure which thread it was but a couple of threads from 2015-2016 pop up in https://mailarchive.ietf.org/arch/search/?qdr=a&start_date=&end_date=&email_list=tls&email_list=kitten&q=text%3A%28channel+binding%29&as=1
SamWhited
Thanks
SamWhited
Oh hey, if I filter by date and list there's a whole topic called "Deprecating tls-unique for TLS 1.3". Dunno why I never realized there was a convenient list-only search that doesn't involve Google or DDG or whatever.
Zash
This is a pretty great mailing list interface indeed. I wish we used it for our lists.
SamWhited
+1
danielhas left
SamWhited
Aha, and it mentions an old draft name I never found by searching either!
SamWhited
Hopefully I can find discussion on that and finally know what had been done towards this in the past. It's just about impossible to dig information out of the IETF.
Zash
I think I searched for the channel binding RFC number as well last time
danielhas joined
SamWhited
This works almost exactly the same as how mine did originally, that's encouraging (or maybe not, since it just dissapeared in 2015 and I'm not sure why yet)
Zash
This?
SamWhited
sorry, the other draft I found in that email thread that expired in 2015: https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03
SamWhited
The author amusingly responded to the other I-D I have out right now, but not the emails to KITTEN and TLS about the channel binding draft, so I pinged him to ask him about the history of it and what not.