XMPP Council - 2011-07-06

hmm, I need to push out revised versions of http://datatracker.ietf.org/doc/draft-blanchet-precis-framework/ and https://datatracker.ietf.org/doc/draft-saintandre-xmpp-6122bis/ before the document deadline next Monday....

And ding, 4pm.

Are we sitting comfortably? Then let's begin.

stpeter: That sounds fun.

yes, fun indeed

1) Roll Call

I'm here.

here

presente

Here

omfg…we actually have a Fritzy! (-:

Huzzah.

2) Agenda bashing.

I've noted adding Compliance.

none

AOB, mabye

maybe even

Ok.

3) Accept 1.1rc2 of XEP-0143 ("Guidelines for Authors of XMPP Extension Protocols"). http://xmpp.org/extensions/tmp/xep-0143-1.1.html http://xmpp.org/extensions/diff/api/xep/0143/diff/1.0/vs/1.1rc2

This has been nagging at me for a while

Why do we have agenda bashing /and/ AOB? :)

MattJ: I have no idea, and often wondered that.

that sounds like a topic for AOB

;)

Kev, you have the power!

agenda bashing could include removing items, I'd think

that's what I was about to say, @Fritzy (-:

But I treot Agenda Bashing as Things Wot Require Votes, and AOB as discussion points.

In any case...

3) Accept 1.1rc2 of XEP-0143 ("Guidelines for Authors of XMPP Extension Protocols"). http://xmpp.org/extensions/tmp/xep-0143-1.1.html http://xmpp.org/extensions/diff/api/xep/0143/diff/1.0/vs/1.1rc2

Fair enough

I'm +1.

Me too

I haven't read it in detail so maybe missed anything editorial

+1

I'll vote on list

But I like this XEP and these changes

I wonder if it's sensible to reference something else for the instructions on how to submit a patch, just so Peter doesn't require Council approval if he changes his favourite Git workflow, but I don't mind.

ah, that's probably a good idea for a future revision. ;)

/nod

probably not a bad idea for the Council to be aware of how things are done

Maybe it's sensible to require approval so Peter can't require authors to jump through hoops :)

Or "future evil editor"

hello

4) Reverting the compliance suites.

howdy

+1 on #3

what does that mean exactly (#4)

Are we agreed that Peter reverting the compliance suite 6120/3920 references was the right thing?

Fritzy: Was typing.

I'm agreed

I think we didn't intend the compliance suites to be updated in the first place when we issued the blanket "please update everything".

the reverting is good

/agreed

Good.

ok

5) Compliance 2012.

Do we want compliance suites this year?

+1, IMHO

I've always been a fan of the compliance XEPs, even though not as much has been made of them that could have been

I think they're worth the small amount of effort

+1 also

they help authors determine what's in, and what they can cut corners on

I guess the logical follow-up question is what goes in them :)

well, we could use the previous versions as a starting point (-:

sounds logical

I think we skipped 2011, making http://xmpp.org/extensions/xep-0270.html the most recent.

then s/392[01]/612\1/g (-:

yes we skipped 2011

I don't think we need a new suite every year…but it's worth it now with the new XMPP specs

I'd like to strike -16 off the list, and replace it with 191.

I don't like -16.

:)

yeah I don't either

Well, 'replace'. 191 is already there.

Otherwise, that looks like a fairly sensible base.

I'm not sure what else we'd particularly need on there.

I'd like to add −201

should someone copy it up and put it in inbox for next meeting?

maybe −296 if I can get it updated (-:

Fritzy: +1

and thanks for volunteering? (-:

heh

I'm not entirely convinced about 201.

I am

296 seems much more valuable.

I have a couple of nits to clean up in 296

but I can also see about starting on this compliance 2012

Shall we take it to list, then, and you can justify including 201 there? :)

(-:

it's not a hill for me to die on

I'd be unsure of very recent XEPs in compliance suites

MattJ: Yes, me too, except that 296 is documenting best practice.

exactly

it's something a lot of clients are already doing

well, the "good" clients (-:

stpeter: hehe

:-D

Although maybe referencing experimental XEPs in a compliance suite isn't smart.

I wonder if any of the others are.

I fully agree there

ok, so then I'll propose 296 move forward? (-:

so I suppose stuff needs to happen before 2012

haha

Right.

ralphm: we can start on it, but yes

So rough idea for the moment is to make compliance 2012 = 2010 + 6120 -16, and to consider threads and locking on-list?

+1

sure

Ok.

6) Date of next meeting.

SBTSBC?

+1

+1

+1

whether I can make it I don't know yet, I won't know until next week

I'll try to send apologies in advance if I can't

Ta.

7) Any other agenda bashing?

uh, AOB vs. Agenda Bashing?

;)

1) a nit in 0297, the namespace is "urn:xmpp:forward:tmp", but it should be "urn:xmpp:forward:0", yes?

2) did anyone ever follow up on the xep-0220 discussion?

I did not follow up on dialback

that was my action item

linuxwolf: It should be, really, yes, now it's accepted.

+1

to #1

and to following up on 220 as well

Kev: I'm starting on an update to carbons, including msg-fwd, and found that little nit (-:

Wonderful, thanks.

I'll poke the authors.

(-:

I'll send the 220 message now before I do a deep dive on i18n madness

I can provide you a patch (-:

I wouldn't bother, unless you've already done it :)

I think I have…in one of my clones (-:

I suspect it'd take as long to apply the patch as to write it.

Kev: yeah, pretty much

Aaaaanything else?

nope

nay from me

nodda

I'll try to remember to not include agenda bashing next time, and we can bash on-list, or AOB in the meeting.

Right, if we're all done...

Thanks all.

ah no, lw to vote on list

stpeter: I didn't read the changes yet, sorry!

no worries

details, details

ok, off to prep for my next meeting...adios

Enjoy.

enjoy!

today's light…only 3 (-:

heh

ok I looked at the XEP-0220 issues

at least briefly

it is very frustrating

and I have some IETF deadlines so I might need to delay real work on this until Tuesday

I'm sure it'll wait.

I am about ready to suggest that Philipp and I need to work on separate specifications of the protocol, and the Council can decide which one it wants to advance -- until then, RFC 3920 will remain the canonical documentation

That would be sad, but if it needs to happen to further the specs, so be it

not sure yet -- I'll try to reach some consensus on the list

stpeter, you're a trouble-maker ;)

/-:

sorry, I got annoyed

there's no reason to be so snarky

we're all trying to work toegher on this stuff

together, even

+1, your last email is fine by me

I think I would have been ruder, myself (-:

and http://about.psyc.eu/Jabber still contains numerous errors, but I don't publicly question their motives

Don't remind me that page exists

It's better than it used to be, at least

Mainly since it no longer has the out-of-context quote of me

ok, enough dialback for today, now I need to crank out a bunch of internationalization work and put together some slides for a presentation about XMPP on Friday before some "smart grid" group

What's the not-so-smart grid?

the dumb grid

how electricity gets to your house :)

people are making it smarter using demand-response technologies and such

Evidently

in fact they're already using XMPP (some of them, anyway)

"price went up, you might want to turn off the clothes dryer" and such

but the folks using XMPP are doing commercial and industrial applications mostly

They should purchase Swiften licenses to use as their libraries...

Kev: good idea, I'll let them know ;-)

also some embedded stuff -- actual XMPP-enabled washers and dryers and such

They should...

it's a bit crazy ;-)

the sensors stuff is semi-related -- I never saw further replies to those threads, though...

anyway, bbiab

:)

brb, need to relocate to a printer

I think it's time for lunch…bbl

lunch is a good idea