XMPP Council - 2013-02-27

is there a council meeting tomorrow?

from the logs, it looks like there is

done (board too)

Sorry, I've been unwell. I think I'll be able to do Council later, but if I don't make it - apologies.

Get well.

if it helps your condition there are somd patches to review ^^

bbl

Ah. I guess I should have sent out an agenda.

(-:

Righty.

I've poked Ralph.

k

Present

1) Roll call

here

-1 to MattJ for top-posting :)

:P

haha

presente

sort of here :-)

Present. And what Kev said

I was pipelining

haha

+1

2) Move for MattJ to buy cakes for everyone

+1

+1

+1

+1

don't forget international shipping costs!

:D

2b) http://xmpp.org/extensions/inbox/last-seen-online.html Accept as Experimental?

Kev: http://xmpp.org/extensions/inbox/last-seen-online.html: XEP-XXXX: Last Presence using Delayed Delivery

+1, typo fixes will follow when it's in the repo

no objections

Minor issue in that it's not legal by 6121 :p

Clients can't send probes.

who are you , the XMPP police?

Kev, is that a MUST NOT or a SHOULD NOT?

SHOULD

SHOULD was allowed when there one knows what one is doing, right?

I was just looking at that indeed

"Presence probes SHOULD NOT be sent by a client, because in general a client will not need to send them since the task of gathering presence from a user's contacts is managed by the user's server. However, if a user's client generates an outbound presence probe then the user's server SHOULD route the probe (if the contact is at another server) or process the probe (if the contact is at the same server) and MUST NOT use its receipt of the presence probe from a connected client as the sole cause for returning a stanza or stream error to the client."

arguably that would be more appropriate as an "ought not"

process the probe is a problem

for this protocol

ralphm: Is it?

I think this protocol is legal for the letter of 6121

You don't want any caching or whatever here.

it might not fit the spirit

by the server, when responding to the probe

(if it processes it)

ralphm: if I (linuxwolf@outer-planes.net) probe my wife (wifey@outer-planes.net), why would it send a probe?

[note: one of those is not a real jid]

Because it has no sense of personal boundaries.

You didn't want a serious answer, right? :p

Anyway, I'm not opposed to pushing it to Experimental, but might need more persuading that it's good to go to Draft.

well, I kind of wanted to prove a point about users on the same server, but whatever (-:

m&m: you might be right, never mind then

not opposed

the server's going to cache some stuff, or it would be constantly probing connected clients

right

MattJ: ?

personally, I'm ok with this, but an explanation of why it bends the SHOULD NOT from 6121

and maybe a discussion on performance and security ramifications

will add a sentence or two for that

but wait

this is about the uptime of servers and components

Yes.

ralphm, also

those are not really bound by 6121 are they?

ralphm: The client is bound by not doing things that 6121 tells it not to.

hm yeah

I think MattJ's wandered off, so...

3) http://xmpp.org/extensions/inbox/last-user-in-presence.html

Kev: http://xmpp.org/extensions/inbox/last-user-in-presence.html: XEP-XXXX: Last User Interaction in Presence

I still say run it up the flag pole and see who salutes

I guess we wanted to discourage to avoid presence probe storms

m&m: Yes, I agree.

in 6121bis I'll change that to "there's really no reason for the client to send probes, because the server does that on its behalf" :P

OK.

I'm +1 on (3).

Not opposed

I'm +1 on (2) and (3)

other than the illegal protocol, I've no objections

+1

m&m, illegal protocol?

show>available?

("available" is not one of the enumerated show values)

yeah..typos

will fix those

hehe

(-:

i falsely expected the IETF to publish consistent documents ^^

next thing you know, he's introduce <presence type='available'/>, or even <presence type='invisible'/> (-:

Tobias: pffth

<priority>-128</priority>

I think that's all of us.

<priority>65356</priority>

I've got a 0.2 of 308 waiting for our esteemed Editor to publish :)

oh yeah

yay!

I saw that

I don't really think the LC feedback was substantive enough to justify a second LC for that.

4) Do we need another LC for 308?

I think it was pretty much a tightening of language and adding detail so it's not worth it.

But we can issue another LC if people want.

Is there a diff somewhere?

I think you're right, but I'd like to see the diff first

MattJ, the diff tool should be working again

http://gitorious.org/xmpp/xmpp/commit/3a09ba0ef53087de391985bd9439b8df60840a25/diffs/e68bc9404d260908b9f9c9060f5a4413cbdf9b7f

Kev: http://gitorious.org/xmpp/xmpp/commit/3a09ba0ef53087de391985bd9439b8df60840a25/diffs/e68bc9404d260908b9f9c9060f5a4413cbdf9b7f: Gitorious

Kanchil: so helpful

Yeah. Sometimes that feature's handy. Other times, not so much.

I like the namespace registration bit change, THIS PROTOXEP

So, shall we issue another LC, or vote on moving this to draft next meeting?

I need time to read it

LGTM

I'm fine with delaying, no need to rush it now

m&m: I'm not asking you to vote now, only if we should plan to LC it or plan to vote on it for next meeting.

But we can delay that too if you want.

I understand that, but I kind of wanted to peruse it before deciding (-:

Tell you what - I'll shove a vote on Draft to the next agenda unless you get in touch to say we need another LC instead.

we could just declare the vote starts meeting, and I could −1 if I really object

wfm

OK.

5) Date of next.

Next week?

+1

IETF is the one after, right?

I'm not available

IETF is the week after, I was taking a short holiday immediately preceding

OK. So three weeks, then?

next week wfm

Tobias: Do keep up, 007.

I am good for any week for the forseeable future

Kev, will do

Let's do three weeks today, then, when Matt and Peter will be recovered from the IETF :)

wfm

k

heh, "recovered"

wfm

i.e. until I have found a new gig

m&m: Repossessed? :p

heh, I'm sure IETF does need recovery time

6) AOB?

stpeter, don't do that

here: what about deprecating XEP-0012? any requirements for this? should any of the new XEPs have a note about it or so?

stpeter, seems to work now..strange...didn't work a minute agao

Tobias: so I noticed

Tobias: I don't think we do anything about it until the new ones are more mature.

Kev, oki dokey

exactly

Although you can add notes saying "Intend to ..." to the new ones if you want.

the others need to get to draft first, I think

m&m, ah..good to know

Kev: XEP-0308 updated

w00t

brb

stpeter: Ta muchly.

No AOB?

none from me

and stpeter wandered away irl

mine was just answered

Longest Council meeting for ages, nearly the full 30 mins!

Right, we're done.

28 on my clock

Thanks all :)

yay

thank you

so March 20 for the next meeting, right?

Sounds about right.

Yes, March 20th.

calendar updated

yay

the start of spring

North America will be on Daylight Saving Time by then, I think

yes

and europe not

so we yanks will try not to get confused

31st March the Council times will change :D

UTC FTW :)

(Which is when GB changes)

don't know when DE changes, but my clock will probably tell me

all of europe changes at the same time

ralphm, really? didn't know that

it's be awfully confusing otherwise

stpeter, that hasn't stopped civilisation from doing so anyway

Tobias: yes. In fact where the UK changes at 01:00, CET changes at 02:00 and so on