XMPP Council - 2011-10-05

I'm going to pop out for a couple of minutes. Should be back for the meeting in 40mins, but if I'm a couple of minutes late...apologies.

ok, no worries

pong?

testing

this is going to be interesting …

the power is on and off at home today

so I might not be able to stay in this meeting

pong

ping?

A neutrino walks into a bar.

"No charge"

An infinite number of mathematicians walk into a bar.

so, I'm getting solar panels installed today…was supposed to be done yesterday

so if I drop, it's because they're switching from evil grid-based electricity to good sun-based electricity

but at least you're saving the planet!

Remind me where the energy for the grid-based electricity comes from :)

coal

It's some big glowing thing somewhere.

But I'm sure it must be evil :D

mostly I don't want another rate hike

"since you're doing such a good job conserving energy, we're rewarding you with a higher rate"

ok, quick run for caffeine … should be back in two minutes

Ralph appears to be offline

And it's 4pm.

correction, he's just away

So let's start.

1) Roll call.

I'm here.

MattJ? linuxwolf?

Present

clearly linuxwolf hasn't found coffee yet

ugh

now I'm here

Righty.

2) 296.

linuxwolf: do you want to call for a vote on this, or leave it in Last Call for a while?

I still think that this breaks caps.

it can stay in LC awhile longer

can you explain how it break capabilities

Whenever you unlock a chat, you no longer have caps available to you for the current chat.

So, for example, CSN will stop working every time you unbind the chat.

Currently 296 recommends/mandates unlocking in situations where it's completely redundant (only one resource available, but you still unbind because it changed status) - but beyond this all this unbinding means you break caps far more often than you need to.

I'll think about language for single resource

I will tell you that when multiple clients are in place, this is working very wonderfully

I take the point of there being some semi-broken clients out there on board as an argument for always unlocking on presence of anything anywhere, but the consequences of this for well-behaved clients (and this *is* a list of best practise, rather than how to work around dodgy clients and gateways) are negative.

*practice

you're assuming that a change availability MUST mean a change in <show/>

I'm assuming that's the typical case, yes.

Without statistics to the contrary, I think it's probably true, too.

I don't think that's a vaild assumption

it's not a valid assumption on the networks I've worked with … some of them being buggy clients but a lot of them having legitimate reasons for it

it's not infrequent that I change from dnd "in a meeting" to dnd "on a conference call" or whatever

linuxwolf: Networks on the Internet?

still available but in a meeting

stpeter: These are the same status, though - you're still DND.

different status, same show

Right, I didn't mean same <status/>

You are still saying "Don't disturb me".

With the proposed unlocking scheme, you start getting messages because of this change, which doesn't seem right at all.

when I had more capable clients, I would switch priorities and statuses, but not <show/>

Kev: clearly I need to review it more closely

and there are clients that allow for that, even if the user doesn't really realize it

linuxwolf: A switch of priority is a good reason to unlock, I think.

it's a crucial reason to unlock

I think it's also important to unlock if you get a new caps hash

I'll buy that, too.

but instead of adding a million special cases, we tried this

it seems to be working very well

for about 6 years now between all the clients I've had influence with (-:

I'm not arguing that there's no deployments, especially when using corporate gateways potentially, where the proposed scheme works well.

I don't think it's the right thing for the Internet, though.

the internet is not the majority of users

not by a long long shot

if we're going to write our protocols for a minority, we're going to get into trouble

I wouldn't call the internet a minority either :)

of XMPP users, it most certainly is

I'm quiet because I'm not sure what the correct solution is... resource locking in general feels more like a hack to me daily

*most* of us are on some sort of private or corporate service

MattJ: While I can see that, I'm not sure how else we get there

When I say I'm not sure what the correct solution is, I suggest there might not be one... we need to decide what we're designing for and choose the best option possible

SIMPLE+MSRP seems worse to me (-:

Well you're clearly using this in production, and you're saying this logic works

yes

linuxwolf: If you're writing this XEP for non-federating deployments, then call it Best Practices for Internal Corporate Resource Locking or something, and I don't have issue with it, and we can come up with another one for the public network.

Kev: this is federating

I agree with Kev though that e.g. a repeated <presence/> shouldn't really cause an unlock

I think it's difficult to say where the majority of deployment occurs.....

for the most part, presence changes don't happen that often for a given indivdual

perhaps do we need to do a bit of research here?

Or just listing the assumptions and requirements in the protoXEP as a start.

I can add a list of assumptions

Ok, moving on then.

3) Account management.

Are we satisfied with the state of community feedback to the point that we can now reject/accept it?

in it's current form, I think so

In the weeks the discussion's been open, I've yet to see anyone argue in favour of it, so if we're doing this now I'm -1.

although

Jehan did just state he'd been out of contact, so was not able to respond

Yes.

Although ideally I'd like to see someone other than the author think it's a good idea to publish it.

But I'm happy to put this off for another week.

Yes, I don't see his reply yet

so, calling the linuxwolf from a minute ago a moron, we might want to give him a few days to respond

4) Server Dialback - the way forward.

I'm in favour of that

Quite an agenda today :)

yes

:P

stpeter: Over to you.

so I updated XEP-0220 to incorporate a few bug reports

have not heard from fippo since then, although it took me months to reply to him the last time!

it might make sense to hold another Last Call

I think the way forward is for Peter to put out a new version 220, start a new LC and go from there. If Fippo, or any other authors, think there are bugs in the spec, they can also propose a new version (or a rollback), and we can compare in LC.

right

/nod

WFM

Ok.

5) 234.

Me too

we need to push on that

or maybe the next council does (-:

so, about 234, I think the primary thing is the hashes spec http://xmpp.org/extensions/xep-0300.html

Tobias and others might have feedback more directly related to 234

I think we can probably LC 300 if we want to.

It's fairly simple.

but we can't advance 234 until we advance 300

/nod to both

one thought: we might want to look at how 300 would slot into other extensions

stpeter: Is that a prerequisite to advancing 300?

so that we can figure out if it's generic enough

Kev: well, I'd hate to advance it while thinking that it solves all problems when it solves only the file transfer problem

Ok.

one concern I have is that existing protocols might use hashes as attributes, not elements

I seem to remember a post where you listed the possible other protocols that could use it

so we'd need to see how to retrofit

MattJ: probably, I need need to go back and look at those

but we could do that during LC

/nod

I just wanted to raise the issue so we're thinking about it

It's hard to apply multiple hashes in an attribute though (-:

that's all from me

linuxwolf: right :)

Ok then. So I see this as nothing for Council to do but wait for Peter to look at updating other XEPs for 300.

6) -0009

Not something I ever expected to discuss in a Council meeting.

Kev: sure

no?

I thought it was a) dead and b) ancient :)

it would require a new version to correct that error

(-:

oh

heh

well, periodically we receive reports of people using it

Wait, what's up with 0009? Have I missed a mail?

MattJ: yes, you have

[Standards] Regarding capitalization of base64 type in Jabber-RPC (XEP-0009)

<base64/> vs <Base64/>

Ah, that one!

right

Sorry, I remember now... forgot which spec was under discussion in that thread :)

So we should just update -9 to use the right caps, shouldn't we?

I think so

yeah

Although...

I think the book from which we borrowed the XML schema is simply wrong

It's final. This is an incompatible change.

I am happy to check with Dave Winer

So I guess we shouldn't and should live with the wart.

/sigh

probably

Time for XMPP-RPC? :)

we have that with XEP-0004 d-:

/ducks

We *could* update -9 with a new namespace and a note saying that in the new namespace you use the right case but everything else is identical.

I'm not convinced we should change −0009, personally

if we change it, it's to add language that we acknowledge our fallibilities

we might want to at least document the wart

right

Yes.

OTOH, it's just a schema issue, right?

"just"

Well, we've typically declared our schemas as informational only

MattJ: Right, but unfortunately the schema is the only content of xep9.

heh

So there's no text that contradicts the schema or anything.

well

So this could be construed as an editorial issue... perhaps ;)

the spec says: There is no official XML schema for XML-RPC. The main body of this schema has been borrowed from an unofficial schema representation contained in the book "Processing XML With Java" by Elliotte Rusty Harold

I would expect existing XML-RPC libraries to use <base64/>

so I think further research might be useful

Right.

So is the right/easy thing to do to copy/paste xep9 into xep3xx, change that one thing plus the namespace, and obsolete xep9?

+1 to research, what actually breaks if we change it is what counts

nod

+1 to research

Asking people who've implemented what happens if we change it is fine by me.

Ok.

7) Next date.

SBTSBC works for me

Next week's going to be somewhere between impossible and P(0) for me, i think.

http://groovy.codehaus.org/Groovy+Jabber-RPC and all that

or not (-:

I will be offline next week

Council *can* have a meeting without me if they want, but it's being a bit optimistic expecting quorum :)

so … is this the last meeting this term?

hmm

possibly, yes

I can do next week, the week after is hard for me

probably

Next term starts 25th, IIRC

anytime in Oct works for me

October 19 would be within this term

10/12 is impossible for Kev, and 10/19 is hard for MattJ

assuming elections are the week of 10/23, that would make this meeting the last

I'm working, but I'm in the office and there are only a few hours everyone will be there.

Maybe different days for next week could work?

We can always pick one on list if we need to discuss something

I'm open to any day but Tuesday

Well, I'm in the office all week next week, but can probably sort something out on Tuesday... :)

Monday, maybe, at a pinch, but it'd be hard.

Tuesday is impossible for me, unless it's after 13:00 MDT

I have a sprint planning meeting, and they go about 4 hours

We could try Monday or Tuesday of the week of the 25th.

Just before term ends.

Assuming we have anything to discuss, of course.

http://search.cpan.org/~qmacro/Jabber-RPC-0.01/lib/Jabber/RPC.pm uses http://search.cpan.org/~rtfirefly/Frontier-RPC-0.07b4p1/lib/Frontier/RPC2.pm and that has <base64>

let's see where we're at on Friday, and go from there

just FYI :)

Yay

and Fronter::RPC2 is probably the reference implementation

stpeter: So maybe no-one implements the XEP and we should fix it.

Anyway.

We're way gone tolerance now.

right

(-:

Heh

I'll do more research

Kev is going to explode

Shall we call for a meeting onlist if it turns out we have something to discuss, but otherwise assume this was the last meeting?

that's what I was suggesting (-:

yes

+1

8) AOB

And risk my wrath :p

No?

Jolly good :)

Thanks all.

Wait!

I had an AOB for 17 minutes!

Just to see what would happen

I've already blown off one meeting

I hope they enjoyed that.

I'll find out in about 30 seconds (-:

it's at 9:30 MDT

We seem to be short of a MattJ on the Council applications at the moment.

Yes...

I'll write it

Jolly good.

you have until Sunday

Oh, that's ok then

I'll write it on Sunday

I'm useless at writing about myself

dude

1) find last year's page

2) copy

:D

3) paste

(-:

4) minor edits for changes in priorities

DONE

The wiki looks very smart, I rarely go to the front page

http://svn.python.org/projects/python/trunk/Lib/xmlrpclib.py has <base64>

We're winning

no, we're losing (-:

I'll keep pasting data points here

linuxwolf, I'm still in favour of changing the schema

It's 1 byte!

I know there's a few people using it for PRC

RPC even

Me too

(-:

In this situation I'm not opposed to correcting the XEP.

case is 1 bit diff in ASCII

Update the schema with a note that the update was made to correct the schema and reflect reality

I use UTF-32, you insensitive clods

(which is also a 1-bit difference, yes)

I starting to accept a schema change, as long as we add some text about what it used to be

and that such text is not only found in the Revision History!

for sure

http://ditchnet.org/xmlrpc/ has <base64>

Ok, Jury's in, then.

the qxmpp library seems to have <base64>

http://www.ntecs.de/ruby/xmlrpc4r/ has <base64>

http://louizatakk.fedorapeople.org/sleekxmpp-1.0-Beta2-0/sleekxmpp/plugins/xep_0009.py

SleekXMPP uses Base64, but I can change that

Base64

Lance Stout, nice :)

http://hg.python.org/cpython/file/2.7/Lib/xmlrpclib.py has <base64>

I might be finding repeats at this point....

all this because someone pressed the shift key a little too long

Heh

and it's the only one that's capitalized, too

that's even funnier

which one?

Base64

oh

yeah

the xmppframework libraryhas <base64> .... http://code.google.com/p/xmppframework/source/browse/Extensions/XEP-0009/XMPPIQ%2BJabberRPC.m?spec=svnb6dfb5e2b007bb59043f82a7156a3710e4bbcb13&r=b6dfb5e2b007bb59043f82a7156a3710e4bbcb13