XMPP Council - 2014-03-12

do we have a meeting today? ✏

We do.

I just have to survive until then (not feel great yesterday/today)

We've got the TLS/DNSSEC/Dialback ProtoXEP and killing 27 with fire on the agenda.

ahh..ok

meeting in 10?

yep

AFAIK

stpeter: I have a question for you

m&m: I have an answer for you!

how do you deal with the RC versions of Draft XEPs?

ah

undocumented :-)

that is not covered in the README (-:

yeah

first we make sure that they have <interim/> element the header

we can have this discuss on the editor@ list

in the header

sure

oh kev?

Tada

1) Rolls

here

here, now officially being an &yeti

Congrats :)

Tobias?

Have poked Matt.

there

OK.

2) Do we want to burn 27 with fire?

m&m: Thanks. Not sure why I missed that, will check later.

What are the problems with 27?

Lance: It's fundamentally broken.

it would be good to document those, I suppose, if someone is motivated to do so

Lance, http://wiki.xmpp.org/web/XMPP_E2E_Security#Comparative_Overview first row

and the requirements "for privacy and security features in a well-rounded instant messaging system" have changed since 2004.

Quite. I'd just like us to have a list of reasons to note when we kill it with fire

Lance: But, it encrypts but doesn't sign messages, and signs presence but without replay protection.

As long as we can point to 'this is why', +1 fire

PGP doesn't have message integrity protection

m&m, Really?

from the last I looked

m&m, PGP in general or the way XEP-0027 uses it?

it was added to CMS fairly recently, but I don't see updates to PGP for that

I /think/ the right path is that it's currently Active, so it should be moved to Deprecated and then Obsolete.

So I think 3) Move XEP-0027 to Deprecated

+1

+1

Tobias: in general, to the best of my knowledge

Hey

Afternoon.

'+1 as well

+1 to #2, +1 to #3 :)

+1

Tobias: let's talk later this week, I can help you update the E2E wiki

3) Move XEP-0027 to Obsolete

+1

heh

(-:

wouldn't that be 4)

Work that state machine.

m&m, happy to do that :) i'd be great to have a good overview of what solutions we have and how they all failed :D before we start another one

Kev, +1 on that

... +1 to burning it with fire, +1 to deprecating it, +1 to obsoleting it

+1 obsolete

I think that's everyone agreed to obsolete it. It's a shame that only the author can retract, because that seems more appropriate than Obsolete, but there we go.

4) http://xmpp.org/extensions/inbox/starttls-dialback.html Accept?

I need to vote on list on this.

+1 accept, but it needs some editing & clarifications

Kev, Retracted is only moved to from Experimental actually.

in particular, the text in example 16 confused me

Dave Cridland: By the state machine, rather than the text, I think.

+1 on accepting that

Lance, I'm certainly not going to claim it's ready for anything more than Experimental.

the text in example should say something along the lines of "capulet ignores the EXTERNAL offer, despite what xep-0178 says, and uses dialback"

+1 to accept

Assuming Fippo is +1, that leaves me on-list.

I'll note that I thought it was an informational/best practice document, until it started getting into protocol details

oh well, 0178 only says "Server1 considers EXTERNAL to be its preferred SASL mechanism", not that it should do that

"In this instance, Capulet ignores the EXTERNAL offer (counter to the advice in XEP-0178), and uses with dialback"

5) Date of next.

MattJ, It *could* be Informational; I leant toward Standards Track because it can be tested.

SBTSBC?

wfm

wfm

wfm

Re: starttls-dialback, does the Council want it to be Standards Track or Informational?

given dave's comment, i lean standards track

time/date wfm

m&m, as is, standards track

I need to have read it before I commend

Or comment, for that matter.

I commend you for commenting

I note that other similar things (e.g. 178) are Informational.

so is 0185. I have no strong preference here.

and they might be better as standards track, but I'd need to look again

stpeter, When he's commented, he'll command.

I will poll the council again just prior to advancement

I'm happy enough the ST, there isn't a clear Right Answer here, to me.

oh, fippo: is 185 obsoleted by 220?

I'll give it a read and comment/commend/command onlist.

5) Any other business

lance: no, 0185 is just a nice way to implement 0220

I'm working on an update to XEP-0138

Right, XEP-0185 is not required for interop, so Informational seems sensible. XEP-0178 is again testable, but I *think* it's merely expanding on RFC 3920 - I wonder if it's now covered by RFC 6120?

but no action by Council required at this time

ah, ok. i saw "however, the recommendations in this document have been incorporated into Server Dialback (XEP-0220) [2]." and was curious

no AOB from me

no AOB here

I think we're done then.

Thanks all.

AOB from XEPs

m&m: Just in time.

What've you got?

XEP-0124 is available now to review

m&m: So you want a vote on that next meeting?

Kev: that's your decision (-

but all of the changes are available in 1.10rc3

http://xmpp.org/extensions/tmp/xep-0124-1.11rc3.html

I'm not sure it is, actually.

I think once we get told you want a vote on a new version, we have to do it :)

whether it's the next meeting or sometime later is your decision

Fair.

(-:

OK, that's in my TODO.

Anything else?

it's up for your review, and yes a vote is expected (-:

nothing from me … will get the newest protoXEP up before the end of the week

Ta.

Then we're done.

Thanks all

Thanks Kev

thank you