XMPP Council - 2020-05-20

yos

1) Roll Call

Good morning

Good morning everyone

Good afternoon.

hi

full house, nice!

2) Agenda Bashing

anything I missed? ✏

LGTM

3) Editor’s Update

- Calls in progress: - LC for XEP-0393 (ends at 2020-05-26) - Expired/Expiring calls: - LC for XEP-0320 (ends today!) - LC for XEP-0339 (ends today!)

%s/ends today/ended yesterday/g

4) Items for Voting

4a) Decide on Advancement of XEP-0339 Title: Source-Specific Media Attributes in Jingle URL: https://xmpp.org/extensions/xep-0339.html Abstract: This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP to Jingle

the LC expired

+1

with very sparse feedback

but the feedback was thoroughly positive, so +1

the feedback we had was positive

and it is a very niche topic

also, two independent implementations would make this ripe even for final

+1 from me to for much the same reason.

+1

Ge0rG, ?

on-list

sorry

alright

4b) Decide on Advancement of XEP-0320 Title: Use of DTLS-SRTP in Jingle Sessions URL: https://xmpp.org/extensions/xep-0320.html Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the Jingle application type for the Real-time Transport Protocol (RTP) as a way to negotiate media path key agreement for secure RTP in one-to-one media sessions.

also on-list

similar amount and kind of feedback

again +1

+1 (few but positive feedback)

Same deal, +1.

I've also missed both LCs :(

+1

Thanks

5) Outstanding Votes

I didn’t update the SoD much since last week, but I think there are still some

on the channel binding spec

So much red

we should probably discuss if me vetoing it is exaggerated

I'd be okay with it if the changes mentioned on the list were applied.

dwd, in context of this?

jonas’, do you agree that 'florians proposal' would be better?

or good enough?

daniel, yes

jonas’, No, it just reminded me.

I think I said so on list, too

i think in that case it doesn’t really matter

because i think we all want the xep to change in that direction

and Sam should just change it. imho

daniel, We do (even though I've not veto'd).

does "we all" include Sam though?

and then jonas’ can un-veto

either way, let’s get this under the XSF umbrella and fix things there.

+1 on Channelbinding pseudomechanisms, in the hope that it’ll get fixed to not be pseudomechansims

+1, what jonas’ said

dwd, I can’t find your vote on-list, you said you were +1?

I believe I did say as much, yes.

thanks, Ge0rG ?

Although where I can't recall.

dwd, this shall do

jonas’: is my non-vote blocking progress?

Ge0rG, no, it expires today

but I wanted to give you a chance to veto

jonas’: I'm aware of that.

But for the record, +1 although with the understanding we'll fix it in Experimental.

if you don’t want to vote that’s fine and we can move on to AOB

I sent a vote on the FROM_TYPE thing to the list yesterday

Quickly injecting: I probably won't change the current draft. If you want to immediately deprecate/obsolete it that's fine, but I'd like it documented and would appreciate it if you'd still accept it. I will likely continue to use pseudomechanisms in my deployment because they're working just fine and so far I haven't had a single problem with them so having them documented somewhere would be nice.

Zash, saw taht

huh

I retract my +1

I may start a separate document since it seems clear that no one else likes pseudomechanisms, or I may not, I still haven't finished the other suggestion to see how well it works.

SamWhited, You don't own the current spec. So if your intent is to refuse updates I'll veto it now and save us the bother.

yeah

I don’t see a point with that

dwd: fair enough. I would appreciate if people would accept it and immediately obsolete it, but I suppose there's no point in the XSF owning it either

SamWhited, huh? what’s the issue with 'Florians proposal'? ✏

I’m back to -1.

SamWhited, The XSF isn't a Wiki. :-)

the rationale I’ve given on-list in https://mail.jabber.org/pipermail/standards/2020-May/037388.html, also a clear statement of the author that they don’t want to change that document to fix things.

dwd: I thought we did something like the IETF does where we sometimes just document unrecommended or proprietary things that most stuff shouldn't implement but is good to have written down in case others want to be compatible with eg. a closed service liek HipChat?

SamWhited, we *do* have wiki.xmpp.org

daniel: I'm not sure, it may be fine. I need to go back and summarize the thread and decide.

Sam can repropose the document if he decides to change it. If and why and how can be discussed in a different venue, since we have an AOB pending.

6) AOB

Yes! Some good news, Sam's password storage draft has been adopted as a Working Group draft.

Kool.

nice!

which one?

It was "individual", it's now a formal product of the IETF.

Now only 10 years or so before it can actually be published as an RFC :) https://datatracker.ietf.org/doc/draft-whited-kitten-password-storage/

daniel, kitten

I think Robbie is going to put out a call for adoption for the channel binding one in kitten too, just waiting to hear back from him on that one.

Great.

So anyway, that was it. Really pleased that's happened, and hopefully we'll get some useful input from that.

Any other AOB?

any news on that routing sprint?

right, I forgot to send out the planning mail

I shall do so tomorrow

the weekend was not as quiet as I hoped for

they never are

true words

and with that

weekend starts now!

8) Ite Meeting Est

Zash, INDEED!

thanks everyone

Thanks yall

Thanks jonas’!

jonas’: you forgot an important thing, #7

Ge0rG, We're never having another meeting now.

dwd: that's good. No need to tell everybody that I might not make the next two meetings, then.

oh

You going anywhere nice?

well

7) Date of Next

+1w wfm

dwd: not to Denmark, unfortunately.

+1w wfm

+3w wfm

+1w WFM.

Ge0rG, so you’re skipping two weeks? will you be able to vote on list?

+1w

jonas’: I might or might not make the actual meetings, and I'll probably be able to vote on list

thanks

8) Ite Meeting Est For Real

thanks again