jonas’- 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!)
jonas’%s/ends today/ended yesterday/g
jonas’4) Items for Voting
jonas’4a) Decide on Advancement of XEP-0339
Title: Source-Specific Media Attributes in Jingle
Abstract: This specification provides an XML mapping for translating the RFC
5766 Source-Specific Media Attributes from SDP to Jingle
jonas’the LC expired
jonas’with very sparse feedback
jonas’but the feedback was thoroughly positive, so +1
danielthe feedback we had was positive
danieland it is a very niche topic
jonas’also, two independent implementations would make this ripe even for final
dwd+1 from me to for much the same reason.
jonas’4b) Decide on Advancement of XEP-0320
Title: Use of DTLS-SRTP in Jingle Sessions
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.
jonas’similar amount and kind of feedback
daniel+1 (few but positive feedback)
dwdSame deal, +1.
Ge0rGI've also missed both LCs :(
jonas’5) Outstanding Votes
jonas’I didn’t update the SoD much since last week, but I think there are still some
jonas’on the channel binding spec
Ge0rGSo much red
jonas’we should probably discuss if me vetoing it is exaggerated
ZashI'd be okay with it if the changes mentioned on the list were applied.
dwdwaves AOB flag.
jonas’dwd, in context of this?
danieljonas’, do you agree that 'florians proposal' would be better?
danielor good enough?
dwdjonas’, No, it just reminded me.
jonas’I think I said so on list, too
danieli think in that case it doesn’t really matter
danielbecause i think we all want the xep to change in that direction
danieland Sam should just change it. imho
dwddaniel, We do (even though I've not veto'd).
jonas’does "we all" include Sam though?
danieland then jonas’ can un-veto
jonas’either way, let’s get this under the XSF umbrella and fix things there.
jonas’+1 on Channelbinding pseudomechanisms, in the hope that it’ll get fixed to not be pseudomechansims
Zash+1, what jonas’ said
jonas’dwd, I can’t find your vote on-list, you said you were +1?
dwdI believe I did say as much, yes.
jonas’thanks, Ge0rG ?
dwdAlthough where I can't recall.
jonas’dwd, this shall do
Ge0rGjonas’: is my non-vote blocking progress?
jonas’Ge0rG, no, it expires today
jonas’but I wanted to give you a chance to veto
Ge0rGjonas’: I'm aware of that.
dwdBut for the record, +1 although with the understanding we'll fix it in Experimental.
jonas’if you don’t want to vote that’s fine and we can move on to AOB
ZashI sent a vote on the FROM_TYPE thing to the list yesterday
SamWhitedQuickly 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.
jonas’Zash, saw taht
jonas’I retract my +1
SamWhitedI 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.
dwdSamWhited, 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.
jonas’I don’t see a point with that
danielSamWhited, huh? what’s the issue with 'Florians' proposal?
SamWhiteddwd: 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
danielSamWhited, huh? what’s the issue with 'Florians proposal'?
jonas’I’m back to -1.
dwdSamWhited, The XSF isn't a Wiki. :-)
jonas’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.
SamWhiteddwd: 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?
jonas’SamWhited, we *do* have wiki.xmpp.org
SamWhiteddaniel: I'm not sure, it may be fine. I need to go back and summarize the thread and decide.
jonas’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.
jonas’hands the mic to dwd
dwdYes! Some good news, Sam's password storage draft has been adopted as a Working Group draft.
dwdIt was "individual", it's now a formal product of the IETF.
SamWhitedNow only 10 years or so before it can actually be published as an RFC :) https://datatracker.ietf.org/doc/draft-whited-kitten-password-storage/
SamWhitedI 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.
dwdSo anyway, that was it. Really pleased that's happened, and hopefully we'll get some useful input from that.
jonas’Any other AOB?
Ge0rGany news on that routing sprint?
jonas’right, I forgot to send out the planning mail
jonas’I shall do so tomorrow
jonas’the weekend was not as quiet as I hoped for
Ge0rGthey never are
jonas’and with that
Zashweekend starts now!
jonas’8) Ite Meeting Est
Ge0rGjonas’: you forgot an important thing, #7
dwdGe0rG, We're never having another meeting now.
Ge0rGdwd: that's good. No need to tell everybody that I might not make the next two meetings, then.
dwdYou going anywhere nice?
jonas’7) Date of Next
Ge0rGdwd: not to Denmark, unfortunately.
jonas’Ge0rG, so you’re skipping two weeks? will you be able to vote on list?
Ge0rGjonas’: I might or might not make the actual meetings, and I'll probably be able to vote on list