XMPP Council - 2012-04-18

:)

howdy

Hi Ralph.

Can we just vote on http://matthewwild.co.uk/uploads/message-archive-management.html regardless of Matt not submitting it yet?

He posted to the list some time ago that we could consider that his submission if he didn't get around to it...and he hasn't.

lazy bastard

are we force-fed specs now

?

heh

Kev: take authorship … I think I remember MattJ offering that to you at one point (-:

speak of the devil!

I'm in a conf meeting that looks like it might overrun

hi devel^WMattJ

hm

oh well

I'll try and pull myself out in a few

ugh

ralphm / Tobias / linuxwolf: Do you guys mind waiting 5mins then to see if MattJ can escape?

nope..i don't mind

uh

I guess not ...

Thanks

Kev: do you think we have to wait like for the MAM spec?

I have a hard stop at 9:30

MDT

15:30 UTC?

That's 30mins from now.

right

exactly

Matt is Meeting Man!

heh

that's a great time to stop anyway

well, Meeting Man™

today is my light day

we shouldn't need the full time

really?

that's wrong

yeah

it's a Security Exploit

apparently

That's a little irritating.

it's why I bounce between Chrome and FF at this point

if I could type "http://xmpp.org/extensions/xep45" and have it "do the right thing", I would be happy (-:

Ok, let's go

well, not irritated

1) Roll call.

I'm here.

presete

gah

here

Here

Tobias: Ping!

linuxworf: what about smart bookmarks? I usually just type xep 0045

pong

I don't want to type the "45" 9-:

I suggest we start with MAM first

Heh

that's Message Archiving Manager, not Matthew A. Miller (-:

linuxwolf: Really? OK, I don't mind.

linuxwolf, Oh, so we have PSA and MAM?

2) MAM http://matthewwild.co.uk/uploads/message-archive-management.html Accept as XEP?

+1

+1

+1

!

+1

And MattJ will, on pain of DEATH send the XML to Peter today.

+1

+1.

+1

+1

+1

3) Dialback: * Where does this live? * How far does it go?

The XSF's powers are getting scary

yow

whose death, by the way?

ralphm: NaN

first we had POKE, now we'll have SMITE?

linuxwolf: This was yours, I think?

I suggested it ...

as the work on DNA slowly progresses, we need to have a dialback progressed to a "recommend implement" state, with fixes

now, I'll defer to stpeter (-:

heh

ok, I chatted with fippo in Paris at the IETF meeting and we agreed that it would be best to document dialback at the IETF (again) so that we can put all these federation + DNA pieces together in the same place

that seems sensible

Hmm, ok

stpeter: So is this the authors saying they want to retract the XEP?

basically, it appears that for DNA purposes we'll be using dialback as a "transport" for various credentials (dbkeys) and assertions (DANE, /.well-known/, etc.)

kev: not yet i think -- actually i have a version with minor bugfixes and a nice new feature

fippo: Ah, you're here :)

So is all we need to do to wait for fippo and stpeter to agree on a new version an submit it?

And then to move it up to Draft?

To the XSF or IETF?

yes, fippo and I need to chat further, but I wanted to socialize the idea of moving this back to the IETF

MattJ: I just understood from fippo that he'd like to get the XEP in order first.

Which seems to make sense to me, we can always then deprecate that once it's RFCd.

possible, yes

ok, but that case the venue is the XSF, not the IETF

truly I'd prefer to just get to work on it at the IETF

I just want *something* to progress

linuxwolf: :)

I have, I *think*, no objection to moving this back to the IETF, although I also aren't sure there's a great benefit to it.

stpeter: have any of the interested parties expressed a preference?

Dialback in SMTP?

the perceived benefit is that all federation basics are by one SDO

Zash: um, no :)

"basics" being a relative term

So, there's no Council action here anyway, right?

right...if it catches one it could be made a requirement of xmpp-core-bis

Kev: no Council action needed at this time, I think

OK.

Tobias: we're thinking this is either stand-alone, or part of the federation/dna draft

4) Obsoleting XEP-0130 No objections received onlists.

So I'm ok with this.

+1

+1

well

maybe move it to deprecated

sure, Deprecated is fine with me

linuxwolf, right..but if integrated in dna, dna could be made a requirement

dot the i's and cross the t's

linuxwolf: +1

+1 on obsoleting

Tobias: But not deprecating?

Same here

er

yeah, deprecate is fine -- that just means the Council will need to look at the issue again in 6+ months :)

Sorry, I was scrolled up

Tobias: DNA would be a requirement, if one supports this not-yet-draft thing

Why in two steps?

stpeter, and obsoleting would move it off any future agenda?

ralphm: I think we're supposed to do it in two steps, without checking XEP-0001.

ralphm: according to XEP-0001, it's supposed to be a 2-step process

right

can we vote on it being automatically moved to obsolete in 6 months?

sounds good to me

+1

+1

ralphm: I don't think it's going to be a hardship to vote on this again in 6 months :)

w00t … a use for <councilnote/> (-:

haha

But sure, let's do that.

speaking of which

+1

OK.

stpeter: I've seen no objections, so please integrate :)

<councilnote>Within six months, this XEP will automatically be determined to be Obsolete</councilnote>

5) Date of next meeting.

SBTSBC

SBtSBC works for me

Same wfm

wfm

It works for me next week (mostly) it won't the week after. So you may need to think whether you want to meet without me in a fortnight :)

6) AOB?

05/02 will not work for me

head's up

I will be on an airplane on May 2

I say we skip 05/02 (-:

and, no AOB from me

AOB: http://mail.jabber.org/pipermail/council/2012-April/003459.html

(other AOB?)

Kev and Matt said it looked fine

this Matt

if others have feedback, please say so here

linuxwolf: of course, the other one is Matthew :)

isn't MUST too strong?

Missed that email somehow

it's not like stuff actually breaks, apart from security

Oh, it's 2h old

(-:

MattJ: right

we can discuss next time

or on the list

or more widely

Sure

no big hurry

Shall we continue this onlist, then?

It seems ok to me, since ZRTP hashes will be different, unless you did something horribly wrong (IIRC)

ralphm: Phil Zimmermann said must so that seemed good enough for me ;-)

:-)

I'm ok with this change

Any other any other business?

but yeah, listage is fine with me

no other AOBs here

Right, I think we're done with 4 mins to spare then.

Thanks all.

/whew

thanks

grazie

Merci

stpeter: Please remember to extract the XML from Matt or let him die trying :)

:)

I'm going to work on it right now

I suppose we could launch some root attacks against his computers...

heehee

joking!

ralphm: I think s/MUST/needs to be/ is fine in that note -- it is just a note, after all

linuxwolf: http://xep.xmpp.zash.se/muc (re earlier talk)

you should all read < http://www.circleid.com/posts/dns_resolution_browsers_hope_for_the_future/ >, then start discussing

Zash: nice

stpeter: nod

linuxwolf: thanks for the reminder

I mean, I had dinner with Andrew and a few other folks in Paris, but that was on a slightly different topic

(-:

it was the third most talked about topic for me in Paris

and I really think everyone should care

yep

linuxwolf: he and I were talking about ways to get beyond the public suffix list (which is kind of like /etc/hosts for Web 2.0 or somesuch)

linuxwolf: interesting. Twisted implements its own resolver, partly because system calls are blocking

ralphm: exactly

"everyone" ends up doing their own, which all behave slightly differently, and give some us headaches

and prosody ...

I also found out recently that Twisted's SRV connector is hasn't changed much in 9 years, but doesn't work as specified in the SRV RFC

but I can tell you that "DNS people" don't see the current state of things as a problem, necessarily

interesting, http://xmpp.org/extensions/xep-0086.html is deprecated, too (as is XEP-0093)

I wonder if it's time to change 86 to Obsolete

the amount of time spent talking past each other is a little astounding

another trend is that recent versions of Ubuntu ship with dnsmasq by default

can you tell my 15:30 meeting ended five minutes ago (-:

quick meeting!

daily scrum!

linuxwolf: i.e. enabled by default

ralphm: I've installed a local resolver on all my boxes

linuxwolf: with network-manager telling it the nameservers it should forward requests, too

to

ralphm: that's fine and good, but if my code can't get there in an efficient manner, I might as well only use /etc/hosts

the problem is not the resolver or nameservers, it's the libraries

or the system calls

I understand this

(and the system calls?)

sorry, this is a rage subject for me now (-:

but this is an interesting approach as this gives it a better API than system calls: the DNS protocol

dude, doing the DNS protocol properly is **HARD**

regarding XEP-0130, I think we just assign it an expiration date, see http://xmpp.org/extensions/xep-0001.html#expiration

better is subjective, of course

richer is probably a better word

I'd rather not have to think about YAP if I don't have to

agreed

I'd rather have a function or two I can call, and "magic" happens

but not blocking

also, lack of an API makes processing DNSSEC very very difficult

well, lack of a library

linuxwolf: unbound

then we might want to tack DANE on top of all that, and properly validate chains

fippo: it lauches a new process, which means I can't use it everywhere I want to

I've told them about it, too

each request forks a new process to make the DNS request

that is almost worse than blocking function calls in a lot of environments

linuxwolf: iirc it can use just a single background thread which runs an event loop

libunbound \o/

fippo: it can, but I've found it difficult to get setup that way

(but doesn't give any means of integrating that loop into your own eventloop)

and it's still spawning a new process

it's eating up far more resources than just handling it async would

less on Linux than Darwin or Mac

er

Darwin or Windows

and using it on Android or iOS is …. troubleshome

Tobias has libunbound working on Android, I believe.

I tried to get it to work for iOS and had issues

at one point, I couldn't get it to compile in NDK, but that was a *long* time ago

and, anyway, spawning a process (or a thread) to make something async is a resource-hogging cop-out

"all" of the platforms (most of us care about) have a way to manage asynchronous I/O is a very efficient manner