KevI just have to survive until then (not feel great yesterday/today)
KevWe've got the TLS/DNSSEC/Dialback ProtoXEP and killing 27 with fire on the agenda.
Tobiasahh..ok
Tobiashas left
Tobiashas joined
m&mhas joined
stpeterhas joined
Lancehas joined
bearhas joined
Zashhas joined
m&mmeeting in 10?
stpeteryep
stpeterAFAIK
m&mstpeter: I have a question for you
stpeterm&m: I have an answer for you!
m&mhow do you deal with the RC versions of Draft XEPs?
stpeterah
stpeterundocumented :-)
m&mthat is not covered in the README (-:
stpeteryeah
stpeterfirst we make sure that they have <interim/> element the header
m&mwe can have this discuss on the editor@ list
stpeterin the header
stpetersure
fippooh kev?
KevTada
Kev1) Rolls
Lancehere
fippohere, now officially being an &yeti
KevCongrats :)
Dave Cridlandhas joined
KevTobias?
KevHave poked Matt.
Tobiasthere
KevOK.
Kev2) Do we want to burn 27 with fire?
m&mvaguely recalls MattJ sending apologies?
Kevm&m: Thanks. Not sure why I missed that, will check later.
LanceWhat are the problems with 27?
KevLance: It's fundamentally broken.
stpeterit would be good to document those, I suppose, if someone is motivated to do so
TobiasLance, http://wiki.xmpp.org/web/XMPP_E2E_Security#Comparative_Overview first row
fippoand the requirements "for privacy and security features in a well-rounded instant messaging system" have changed since 2004.
LanceQuite. I'd just like us to have a list of reasons to note when we kill it with fire
KevLance: But, it encrypts but doesn't sign messages, and signs presence but without replay protection.
LanceAs long as we can point to 'this is why', +1 fire
m&mPGP doesn't have message integrity protection
Dave Cridlandm&m, Really?
m&mfrom the last I looked
Tobiasm&m, PGP in general or the way XEP-0027 uses it?
m&mit was added to CMS fairly recently, but I don't see updates to PGP for that
KevI /think/ the right path is that it's currently Active, so it should be moved to Deprecated and then Obsolete.
KevSo I think
3) Move XEP-0027 to Deprecated
Kev+1
Lance+1
m&mTobias: in general, to the best of my knowledge
MattJHey
KevAfternoon.
fippo'+1 as well
MattJ+1 to #2, +1 to #3 :)
Tobias+1
m&mTobias: let's talk later this week, I can help you update the E2E wiki
Kev3) Move XEP-0027 to Obsolete
Kev+1
stpeterheh
m&m(-:
stpeterwouldn't that be 4)
Dave CridlandWork that state machine.
Tobiasm&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
TobiasKev, +1 on that
fippo... +1 to burning it with fire, +1 to deprecating it, +1 to obsoleting it
Lance+1 obsolete
KevI 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.
Lance+1 accept, but it needs some editing & clarifications
Dave CridlandKev, Retracted is only moved to from Experimental actually.
Lancein particular, the text in example 16 confused me
KevDave Cridland: By the state machine, rather than the text, I think.
Tobias+1 on accepting that
Dave CridlandLance, I'm certainly not going to claim it's ready for anything more than Experimental.
fippothe text in example should say something along the lines of "capulet ignores the EXTERNAL offer, despite what xep-0178 says, and uses dialback"
MattJ+1 to accept
KevAssuming Fippo is +1, that leaves me on-list.
MattJI'll note that I thought it was an informational/best practice document, until it started getting into protocol details
fippooh well, 0178 only says "Server1 considers EXTERNAL to be its preferred SASL mechanism", not that it should do that
Dave Cridland"In this instance, Capulet ignores the EXTERNAL offer (counter to the advice in XEP-0178), and uses with dialback"
Kev5) Date of next.
Dave CridlandMattJ, It *could* be Informational; I leant toward Standards Track because it can be tested.
KevSBTSBC?
Lancewfm
Tobiaswfm
fippowfm
stpeteragrees with Dave about testability
m&mRe: starttls-dialback, does the Council want it to be Standards Track or Informational?
Lancegiven dave's comment, i lean standards track
MattJtime/date wfm
MattJm&m, as is, standards track
KevI need to have read it before I commend
KevOr comment, for that matter.
stpeterI commend you for commenting
KevI note that other similar things (e.g. 178) are Informational.
fipposo is 0185. I have no strong preference here.
stpeterand they might be better as standards track, but I'd need to look again
Dave Cridlandstpeter, When he's commented, he'll command.
m&mI will poll the council again just prior to advancement
KevI'm happy enough the ST, there isn't a clear Right Answer here, to me.
Lanceoh, fippo: is 185 obsoleted by 220?
KevI'll give it a read and comment/commend/command onlist.
Kev5) Any other business
fippolance: no, 0185 is just a nice way to implement 0220
stpeterI'm working on an update to XEP-0138
Dave CridlandRight, 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?
stpeterbut no action by Council required at this time
Lanceah, ok. i saw "however, the recommendations in this document have been incorporated into Server Dialback (XEP-0220) [2]." and was curious
Tobiasno AOB from me
Lanceno AOB here
KevI think we're done then.
KevThanks all.
m&mAOB from XEPs
Kevm&m: Just in time.
KevWhat've you got?
m&mXEP-0124 is available now to review
Kevm&m: So you want a vote on that next meeting?
m&mKev: that's your decision (-
m&mbut all of the changes are available in 1.10rc3