KevI have assorted issues with this, but I don't think they're fundamental to the design, they just need maturing on the vine.
KevI think fundamentally "use iq:roster" is right.
m&mI haven't read it yet
MattJI'm +1
MattJIt does have questions, but it's implemented in places and working
ralphmNo objection
KevI read something that I thought was broken, but I don't remember what it was. But I'm not objecting anyway.
ralphmheh
KevIt wasn't show-stopping.
Kevm&m: So, a fortnight for you to object :)
Kev6) http://xmpp.org/extensions/inbox/sensor-data.html
Accept as Experimental?
m&mI'm not objecting now
KanchilKev: http://xmpp.org/extensions/inbox/sensor-data.html:
XEP-xxxx: Sensor Data Interchange over XMPP
m&m(-:
Kevm&m: Noted, ta.
KevThis was the last on my list, and I've not got to it yet. Objections, or lack thereof, within a fortnight.
m&mI glanced over this earlier … no objections
ralphmNo objection
MattJI've no objection to accepting
MattJI think it needs some work though
ralphmindeed
KevI'd encourage people to post comments to the list :)
ralphmbut I like people are working on this stuff
KevIn fact, not only would I, but I do!
Kev7) http://xmpp.org/extensions/inbox/exi.html
Accept as experimental
KanchilKev: http://xmpp.org/extensions/inbox/exi.html:
XEP-xxxx: Using Efficient XML Interchange (EXI) Format in XMPP
MattJYay!
ralphmI haven"t looked at the exi stuff yet
KevI have some issues with this.
KevI'm trying to work out if they're sufficiently fundamental to object or not.
Dave CridlandI'd note that while I think EXI may be mature enough (and useful enough) to consider now, I don't think this fits as a compression mechanism - ie, within the XEP-0138 model.
ralphmright
KevI /think/ that at least none of this stuff can happen pre-auth.
MattJDave Cridland, because of bootstrapping?
MattJKev, why not?
Kev(And pre-TLS)
m&mdwd: I agree with you
Dave CridlandMattJ, There's some negotiation going on, and all sorts.
m&malso http://www.quickmeme.com/meme/3tfmdg/
Kanchilm&m: http://www.quickmeme.com/meme/3tfmdg/:
Southpark Instructor - if youre going to compress after encryption youre going to
ralphmDave Cridland:how would you use it, roughly?
Zashm&m: haha
KevMattJ: Because you're sending assorted stuff to the server
Kevm&m: Negotiation and layering don't need to be equivalent.
Dave Cridlandralphm, What, use EXI? Or use EXI within the context of XMPP?
KevBut you need to have verified the server's identity before you're going to be willing to download schemas.
KevAnd similarly it'll need to have authenticated you for the same.
MattJGood point
m&mright
ralphmDave Cridland: latter
KevI do understand the basic principle that compressing data that's indistinguishable from random is a Really Good Idea.
Dave CridlandKev, I'm not sure that's true. You can exchange which schemas you're willing to support for compression without security risk, I *think*. Not sure though.
Dave Cridlandralphm, I think it's possibly a new binding, as PSA discussed.
KevDave Cridland: If I MITM to add somehow malicious schemas, and you download them after auth, that still seems bad.
ralphmright
Dave CridlandKev, I don't know - the data is still authenticated, it's just it may be compressed in odd ways.
m&mI could be wrong, but the compression could be to the point where a MITM could inject a schema that fundamentally changes the data
MattJYou could start with a common mandatory schema for auth, and negotiate others after TLS+auth
KevI'm at least not sufficiently knowledgeable on this to be confident that it's not introducing some really nasty issues.
MattJNevertheless, I don't object to accepting it
MattJI think it would be good for people to poke at it
MattJEnough are interested that I think it'll happen
m&mexactly
MattJThough "enough" are a vocal minority I think :)
Dave CridlandRight, I'm not sufficiently knowledgeable either. But I do think this is generally wrong; a "pure" EXI binding seems the appropriate construction.
KevI'll hold off for today, and get my thoughts in order within the fortnight.
MattJnod
m&mdwd: that's my feeling, too
Dave CridlandFWIW, I note yusuke.doi is present and might have some opinion.
yusuke.doiHi, am I allowed to speak?
Kevyusuke.doi: Of course.
ralphmyes
ralphmDave Cridland is not on the council, either
yusuke.doiThanks. I believe this proposal should be discussed more, either in experimental state or pre-XEP.
ralphmhaving it on the list wouldnbe awspme
yusuke.doiI have no clear opinion to accept or not, but I feel this proposal have slight variation from 'regular' EXI.
ralphmyay lag and tablet
m&myusuke.doi: ??
m&mthat's a little concerning to me … XMPP already abuses XML stacks enough
yusuke.doim&m: I see :-) If it's okay for the committee, I don't object.
MattJm&m, for that suggestion I'll deal with you later :)
KevSo, I think we need to take this to list. I'll try and post something soon, and see if I can form a sensible opinion within a fortnight.
ralphmyeah
MattJSounds good
fippom&m: shall i propose a asn.1 binding for xmpp? :-)
ralphmsure
m&mmy problem is that I don't understand EXI enough to feel comfortable commenting
KevI'm not fundamentally opposed to the idea of EXI for XMPP, at least.
yusuke.doiYou need to invent namespace in asn.1 :-)
ralphmand a protocol buffers oene
KevRight. I think we're done.
Kev7) Date?
m&mprotobuff!
Dave Cridlandyusuke.doi, X.693
Kev8) Date, rather
ZashJSON!!
m&mnext week works for me
ralphmsbtsbc
yusuke.doiDave Cridland: Thanks
MattJwfm
KevOK.
Kev9) AOB?
MattJnack
m&mthe IETF meeting was rather uneventful
ralphmglad about per's message
m&mmostly because it was the very last session of the week
m&mand we were all brain-dead
MattJI noticed :)
KevOK, that's it then.
KevThanks all.
m&msomeone has to be the sacrificial goat; RAI likes to rotate which group that is
MattJThanks Kev
yusuke.doiThanks
ralphmpeople at pycon are really cynical about Google's plans with XMPP
Kevbangs the gavel.
m&mI just want to know I think EXI for XMPP is interesting, but I'm not sure this is the right a approach
Kevralphm: Oh? This because of the somewhat political "Google Bad, Mkay" thing prominent people have done this week?
m&mralphm: I can't blame them
ralphmyeah, many misinformed opinions
fipporalphm: as long as google doesn't put jarkko (the irc guy) in charge there is no reason to worry :-)
ralphmhah
m&mno comment (-:
ralphmgoogle reader thing and caldav didn't go over well, and then this came up
Dave CridlandCalDAV isn't being dropped, though.
ZashJust require you to be whitelisted to access?
Dave CridlandI'm told that it's being moved to an Oauth2 based service, but the transition just happens to be a bit rough.
ralphmwell that's entirely different from what they wrote themselves
Dave CridlandOnce it's OAuth2, it will have per-application keys, though I don't know the details.
yusuke.doim&m: I'd like to propose different port approach for EXI with XMPP soon.
m&myusuke.doi: that sounds like the alternative binding route … which is probably the right approach
ralphmin the announcement they said move to the google calendar api
yusuke.doim&m: depends on use case (is the fair answer, I believe alternative binding should be better :-)
Dave Cridlandralphm, Yes, they did. I think the road to OAuth2 CalDAV is long and rocky.
ralphmok, but communicating that would've been nice
ralphmoh well
ralphmgotta walk to sprints now
KevEnjoy.
MattJm&m, by the way - a question that came up after IETF: as an implementor, how would I actually use POSH? Am I supposed to fire off HTTPS requests every time I see an invalid cert?
MattJSee you ralphm
fippomattj: i think so
MattJm&m, or will we have a way in XMPP to hint that POSH should be used to verify?
m&mMattJ: or everytime you see a new domain
Dave Cridlandyusuke.doi, I don't see nearly as many benefits for in-stream negotiated EXI, since you need a traditional XML parser, fallback cases, and so on. Feels all wrong.
ZashMattJ: Just as we would need to fire off a DNS lookup for DANE
MattJDo both at the same time, and see which returns faster? ;)
m&mbasically, yes
yusuke.doiDave Cridland: Personally I agree. But Peter should have different answer
m&mHappy Eyeballs for Everyone!
MattJDoesn't it essentially make everyone with a cert their own CA? :)
fippomattj: you might even do traditional dial-back in parallel :-)
m&mit's the Oprah paradigm for protocols
ZashMattJ: DANE? Yes. :D
m&mDANE definitely does, POSH could depending on what other HTTP-based things you support
fippoeven though i think that the samecert stuff might be faster than POSH (less secure though sincc it works with self-signed certs)
m&mfippo: dialback is not a prooftype
MattJfippo, samecert?
fippom&m: not for the ietf at least ;-)
m&mfippo: not for anyone that actually cares about assurances d-:
MattJNeither for Prosody, as of the next version
MattJIt's also an open question as to whether we allow dialback by default in the config
fippomattj: open a reverse connection to the host, starttls, compare certificates. slighty better than 0185, less roundtrips
MattJBut either way it's motioning towards being called "insecure"
fippom&m: well, 99%+ of server admins don't care
m&mwanders back to his day job responsibilities
MattJfippo, ah, right
Zash!xep 185
fippom&m: shall i point out that muc.xmpp.ogr was using an invalid cert until like two weeks? :-)
MattJfippo, it wouldn't have been if nobody could connect to it :)
MattJSomeone needs to jump first
m&mright
ZashIs samecert documented somewhere?
fippoyeah. that big hammer called "jabber.org" ;-)
MattJfippo, well yes, there is that
fippozash: dave had a blogpost describing it...
MattJI was thinking of shipping XMPP servers, but jabber.org would be a better hammer
TobiasKev, yeah..the zZz meant i was asleep..sry
MattJor Google, but... meh
Zashfippo: orly?
ZashDave Cridland: orly?!
ZashWasn't that d-w-d, which iirc was about verifying certs as normal
ZashBut in a dialback
m&mthat's what I thought
fippoi think it descried samecert, too
ZashDave Cridland: Your blog, when will it return to the land of the online?
fippom&m: btw, DNA still needs a turbohalibut prooftype, otherwise that cridland guy will block it :-)
m&mgoes off for more caffeine
fippohttp://jabber.soup.io/post/88601075/Dave-Cridland-Dialback-Now-without-dialback -- cached version
fippothe third paragraph describes samecert
ZashAnd as I said at the summit, I'd like to see "If the SRV record is Secure, then the target name is acceptable in the certificate" in a standalone document :)
Dave CridlandTubrohalibut. Mmmmm.
Dave CridlandZash, So, my blog is more or less shot. I might resurrect it at some point. Or I might do something odd with having it semi-present and backed onto G+.
Kevnanoc!
Kev(Nanoc really does seem to be quite competent)
Dave CridlandIt's really that I'm not sure I can be bothered having a traditional blog, rather than G+.
ZashIt wouldn't be the same :(
ZashBut then, I'm in the 'doesn't really want to depend on Google'-crowd.
fippowe should have recorded peters statement on open federation at the summit
Zashfippo: summary? not sure I recall
fippozash: i don't recall exactly either :-( maybe webex was active and is recorded
MattJOne day I'll finish my blog
MattJhttp://blog.matthewwild.co.uk/
KanchilMattJ: http://blog.matthewwild.co.uk/:
Matthew Wild's Blog
Tobiashaha
Zash!
Tobiasthat reminds me of http://216.119.142.188/~jbwp/wp-content/uploads/2011/05/2011-05-01-Homer-Web-Page.jpg