XMPP Council - 2013-03-20

might be a tad "late"

or unfocused right at the start

OK.

I'm *still* reviewing stuff.

Kev, Anyone would think you were busy these days, for some reason.

How little they would know.

Right. 'tis time.

1) Roll call.

present physically

er … logically

hey

from pycon

Ah.

Hail, pycon.

MattJ / Tobias?

Present

Tobias is auto-away, I can tell because Swift has put a Zzz icon over his avatar :D

Right. So let's start.

Does that mean he's asleep?

Probably.

2) Let's start with the completely uncontentious one. LC on 220?

+1

+1

I'm +1

yea

Magic.

as I work on making db irrelevant (-:

3) 308 to Draft?

I have, I believe, addressed all the LC feedback in one way or another.

I think so, too

I'm +1

+1

+1

Amazing.

That wasn't the contentious item, was it? :)

4) http://xmpp.org/extensions/inbox/dtls-fingerprint.html Accept as Experimental?

Kev: http://xmpp.org/extensions/inbox/dtls-fingerprint.html: XEP-xxxx: Use of DTLS-SRTP in Jingle Sessions

no objections

I know nothing about the subject matter, but that presumably just means I have no meanginful objections.

Or spelling.

I thought we had something like this already.

Or was that ZRTP?

ZRTP, IIRC

ZRTP.

dave: 0262 -- dtls is significantly different

I've no objections so far, but that's likely because I only saw the document this morning and haven't read it through yet

No objection

5) http://xmpp.org/extensions/inbox/roster-management.html Accept as Experimental?

Kev: http://xmpp.org/extensions/inbox/roster-management.html: XEP-xxxx: Remote Roster Management

I have assorted issues with this, but I don't think they're fundamental to the design, they just need maturing on the vine.

I think fundamentally "use iq:roster" is right.

I haven't read it yet

I'm +1

It does have questions, but it's implemented in places and working

No objection

I read something that I thought was broken, but I don't remember what it was. But I'm not objecting anyway.

heh

It wasn't show-stopping.

m&m: So, a fortnight for you to object :)

6) http://xmpp.org/extensions/inbox/sensor-data.html Accept as Experimental?

I'm not objecting now

Kev: http://xmpp.org/extensions/inbox/sensor-data.html: XEP-xxxx: Sensor Data Interchange over XMPP

(-:

m&m: Noted, ta.

This was the last on my list, and I've not got to it yet. Objections, or lack thereof, within a fortnight.

I glanced over this earlier … no objections

No objection

I've no objection to accepting

I think it needs some work though

indeed

I'd encourage people to post comments to the list :)

but I like people are working on this stuff

In fact, not only would I, but I do!

7) http://xmpp.org/extensions/inbox/exi.html Accept as experimental

Kev: http://xmpp.org/extensions/inbox/exi.html: XEP-xxxx: Using Efficient XML Interchange (EXI) Format in XMPP

Yay!

I haven"t looked at the exi stuff yet

I have some issues with this.

I'm trying to work out if they're sufficiently fundamental to object or not.

I'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.

right

I /think/ that at least none of this stuff can happen pre-auth.

Dave Cridland, because of bootstrapping?

Kev, why not?

(And pre-TLS)

dwd: I agree with you

MattJ, There's some negotiation going on, and all sorts.

also http://www.quickmeme.com/meme/3tfmdg/

m&m: http://www.quickmeme.com/meme/3tfmdg/: Southpark Instructor - if youre going to compress after encryption youre going to

Dave Cridland:how would you use it, roughly?

m&m: haha

MattJ: Because you're sending assorted stuff to the server

m&m: Negotiation and layering don't need to be equivalent.

ralphm, What, use EXI? Or use EXI within the context of XMPP?

But you need to have verified the server's identity before you're going to be willing to download schemas.

And similarly it'll need to have authenticated you for the same.

Good point

right

Dave Cridland: latter

I do understand the basic principle that compressing data that's indistinguishable from random is a Really Good Idea.

Kev, 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.

ralphm, I think it's possibly a new binding, as PSA discussed.

Dave Cridland: If I MITM to add somehow malicious schemas, and you download them after auth, that still seems bad.

right

Kev, I don't know - the data is still authenticated, it's just it may be compressed in odd ways.

I could be wrong, but the compression could be to the point where a MITM could inject a schema that fundamentally changes the data

You could start with a common mandatory schema for auth, and negotiate others after TLS+auth

I'm at least not sufficiently knowledgeable on this to be confident that it's not introducing some really nasty issues.

Nevertheless, I don't object to accepting it

I think it would be good for people to poke at it

Enough are interested that I think it'll happen

exactly

Though "enough" are a vocal minority I think :)

Right, I'm not sufficiently knowledgeable either. But I do think this is generally wrong; a "pure" EXI binding seems the appropriate construction.

I'll hold off for today, and get my thoughts in order within the fortnight.

nod

dwd: that's my feeling, too

FWIW, I note yusuke.doi is present and might have some opinion.

Hi, am I allowed to speak?

yusuke.doi: Of course.

yes

Dave Cridland is not on the council, either

Thanks. I believe this proposal should be discussed more, either in experimental state or pre-XEP.

having it on the list wouldnbe awspme

I have no clear opinion to accept or not, but I feel this proposal have slight variation from 'regular' EXI.

yay lag and tablet

yusuke.doi: ??

that's a little concerning to me … XMPP already abuses XML stacks enough

m&m: I see :-) If it's okay for the committee, I don't object.

m&m, for that suggestion I'll deal with you later :)

So, 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.

yeah

Sounds good

m&m: shall i propose a asn.1 binding for xmpp? :-)

sure

my problem is that I don't understand EXI enough to feel comfortable commenting

I'm not fundamentally opposed to the idea of EXI for XMPP, at least.

You need to invent namespace in asn.1 :-)

and a protocol buffers oene

Right. I think we're done.

7) Date?

protobuff!

yusuke.doi, X.693

8) Date, rather

JSON!!

next week works for me

sbtsbc

Dave Cridland: Thanks

wfm

OK.

9) AOB?

nack

the IETF meeting was rather uneventful

glad about per's message

mostly because it was the very last session of the week

and we were all brain-dead

I noticed :)

OK, that's it then.

Thanks all.

someone has to be the sacrificial goat; RAI likes to rotate which group that is

Thanks Kev

Thanks

people at pycon are really cynical about Google's plans with XMPP

I just want to know I think EXI for XMPP is interesting, but I'm not sure this is the right a approach

ralphm: Oh? This because of the somewhat political "Google Bad, Mkay" thing prominent people have done this week?

ralphm: I can't blame them

yeah, many misinformed opinions

ralphm: as long as google doesn't put jarkko (the irc guy) in charge there is no reason to worry :-)

hah

no comment (-:

google reader thing and caldav didn't go over well, and then this came up

CalDAV isn't being dropped, though.

Just require you to be whitelisted to access?

I'm told that it's being moved to an Oauth2 based service, but the transition just happens to be a bit rough.

well that's entirely different from what they wrote themselves

Once it's OAuth2, it will have per-application keys, though I don't know the details.

m&m: I'd like to propose different port approach for EXI with XMPP soon.

yusuke.doi: that sounds like the alternative binding route … which is probably the right approach

in the announcement they said move to the google calendar api

m&m: depends on use case (is the fair answer, I believe alternative binding should be better :-)

ralphm, Yes, they did. I think the road to OAuth2 CalDAV is long and rocky.

ok, but communicating that would've been nice

oh well

gotta walk to sprints now

Enjoy.

m&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?

See you ralphm

mattj: i think so

m&m, or will we have a way in XMPP to hint that POSH should be used to verify?

MattJ: or everytime you see a new domain

yusuke.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.

MattJ: Just as we would need to fire off a DNS lookup for DANE

Do both at the same time, and see which returns faster? ;)

basically, yes

Dave Cridland: Personally I agree. But Peter should have different answer

Happy Eyeballs for Everyone!

Doesn't it essentially make everyone with a cert their own CA? :)

mattj: you might even do traditional dial-back in parallel :-)

it's the Oprah paradigm for protocols

MattJ: DANE? Yes. :D

DANE definitely does, POSH could depending on what other HTTP-based things you support

even though i think that the samecert stuff might be faster than POSH (less secure though sincc it works with self-signed certs)

fippo: dialback is not a prooftype

fippo, samecert?

m&m: not for the ietf at least ;-)

fippo: not for anyone that actually cares about assurances d-:

Neither for Prosody, as of the next version

It's also an open question as to whether we allow dialback by default in the config

mattj: open a reverse connection to the host, starttls, compare certificates. slighty better than 0185, less roundtrips

But either way it's motioning towards being called "insecure"

m&m: well, 99%+ of server admins don't care

fippo, ah, right

!xep 185

m&m: shall i point out that muc.xmpp.ogr was using an invalid cert until like two weeks? :-)

Zash: XEP-0185(N/A): http://xmpp.org/extensions/xep-0185.html Dialback Key Generation and Validation - Informational/Active - Updated: 2007-02-15

fippo, it wouldn't have been if nobody could connect to it :)

Someone needs to jump first

right

Is samecert documented somewhere?

yeah. that big hammer called "jabber.org" ;-)

fippo, well yes, there is that

zash: dave had a blogpost describing it...

I was thinking of shipping XMPP servers, but jabber.org would be a better hammer

Kev, yeah..the zZz meant i was asleep..sry

or Google, but... meh

fippo: orly?

Dave Cridland: orly?!

Wasn't that d-w-d, which iirc was about verifying certs as normal

But in a dialback

that's what I thought

i think it descried samecert, too

Dave Cridland: Your blog, when will it return to the land of the online?

m&m: btw, DNA still needs a turbohalibut prooftype, otherwise that cridland guy will block it :-)

http://jabber.soup.io/post/88601075/Dave-Cridland-Dialback-Now-without-dialback -- cached version

the third paragraph describes samecert

And 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 :)

Tubrohalibut. Mmmmm.

Zash, 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+.

nanoc!

(Nanoc really does seem to be quite competent)

It's really that I'm not sure I can be bothered having a traditional blog, rather than G+.

It wouldn't be the same :(

But then, I'm in the 'doesn't really want to depend on Google'-crowd.

we should have recorded peters statement on open federation at the summit

fippo: summary? not sure I recall

zash: i don't recall exactly either :-( maybe webex was active and is recorded

One day I'll finish my blog

http://blog.matthewwild.co.uk/

MattJ: http://blog.matthewwild.co.uk/: Matthew Wild's Blog

haha

!

that reminds me of http://216.119.142.188/~jbwp/wp-content/uploads/2011/05/2011-05-01-Homer-Web-Page.jpg

but sure beats the design of my blog