XMPP Council - 2012-02-29

Hi Ralph.

I haven't even forgotten. Yet :)

heh

I was in a Zoo last week, so I did.

oopsie

yeah, that too (last week)

Howdy folks.

1) Bap call.

I'm here.

presente

Matthew seems to be offline

stpeter: I still don't see it

Marrrrvellous.

his server seems to be gone

/-:

2) http://xmpp.org/extensions/inbox/pubsub-since.html

Accept as XEP?

+1

+1

I'd like to see an example of how it would work with RSM

ralphm: true

I have serious reservations about this. Firstly that using a timestamp for this is broken, secondly that it says to use Last Activity In Presence, but doesn't cover what to do on non-initial presence, and thirdly that it says to use RSM but not how.

+1... but... timestamps.

+1

by "timestamps" do you mean UTC?

clock skew

instead of last presence?

I just used the format from iq:last

So I think all of those should be addressed in some way. That can happen on the vine, although I don't like it.

Clock skew is my concern... giving 5 minutes' grace is fine, but then you possibly send duplicate updates

We have systems like this already, and they're proven not to work.

Kev, what exactly has been proven not to work?

Tobias: Using time-of-last-something as a way of resynchronising history. Swift does it for MUCs, and you frequently end up with duplicate notifications.

MattJ: true. This is only a problem with notifications that are idempotent. In some cases, they aren't, but I'm not sure if delayed delivery in those cases are proper anyway.

/not/ idempotent

Kev, ah..right

You don't even need clock skew for things to go wrong. You can both have duplicates and missed notifications.

Kev: for MUCs it is a bigger problem because messages are not idempotent there

(using pubsub-since)

But anyway. It can go on the vine as everyone else is happy with this.

well, it is not an active standard yet

I wouldn't push it to Draft in its current state, though.

I'm not against publishing

no one is asking to push it to draft yet

right..but all this can be fixed in Experimental state

linuxwolf: No, but I'm giving a heads-up.

3) Obsoleting 130.

Kev: just be sure to post to the list, too

linuxwolf: Reasonable.

One could also argue that we are jumping through a lot of hoops to make automatic subscriptions work without the cooperation of your 'home' server. If you lose that constraint other solutions might be better.

ralphm: as in ask your home server to do the subscription for you?

+1 to -0130

stpeter: in one way or the other, yes. Then it could also just receive notifications in offline storage, for example.

also +1 to −0130

I'd like to do a ~Last Call on standards@ for a few weeks to say "We'll obsolete this on the Xth March unless someone says it's in use".

Kev: for sure

of course

stpeter: It wasn't clear to me how obsoleting this would affect your cleanup, though.

Kev, sounds like a good idea

linuxwolf, I like what you did there :)

Kev: http://xmpp.org/extensions/xep-0172.html#waitlist

Ah, I'd completely forgotten that was there.

Fairy nerfs, then.

what is the necessity of obsoleting this specification?

ralphm: first, I'd like to clean up XEP-0172

ralphm: second, no one is using it

so it's cruft

we don't want people to come along and implement things that aren't in use and weren't such good ideas in the first place ;-)

Do other standards organizations do a similar thing?

sometimes, yes

but e.g. the IETF has a lot more cruft than we do

I'm just thinking aloud here, wether we should actively work to reduce the number of standards we have around, even if noone uses it anymore, as far as we know.

they had an effort to clean out the cruft some years ago and it was overwhelming

As long as the bar for cleaning up is very very high, I'm all for it

The reference to 130 could easily be removed from 172 at least.

to the best of my knowledge, though, XEP-0130 didn't really solve the problem it set out to

Wait... how did it get to be historical?

jabber:iq:agents, maybe?

MattJ: because it documented a protocol in use at the time

Who used it?

anyway, I'm +1 in this case

Jabber Inc

MattJ: France Telecom

Ok

with France Telecom, right?

ralphm: correct

JINC had support for it in XCP, but that support is gone

So we believe that the only people using it are now saying it's obsolete. That seems fine to me. Put out a ~Last Call and fine.

Kev: rightio

4) The continuing shortification effort.

stpeter: You wanted to further discuss this?

I didn't see people jumping up and down with excitement about my rough split of XEP-0045

Indeed

I have it open in my browser, but haven't read it yet.

I haven't finished reading it yet

it's very rough, just to give a sense

perhaps it's not worth the effort

(well, I haven't started either (-: )

I think the difference is less marked with XEP-0045, since it doesn't have a lot of optional features like pubsub

/nod

MattJ: perhaps

I've looked at pubsub

MattJ: revising XEP-0060 is on my to-do list for Life After IESG™

Those many mandatory features are also tricky there

it is ongoing work, that I plan to take my time on

I think it's much easier to split 60 than 45, but I'll give this split a read through.

stpeter, there is life after IESG??

stpeter: that should be a TV show (-:

Kev: all right

I haven't looked at 60

One thought I had is that if we do split 45, we should leave 45 in place with a reference to all three subXEPs, saying "You MUST implement all of these".

will do in April, I think

That way the function of -45 doesn't change, but people could support just XEP-0313 or whatever, if that's deemed useful. Although I'm not sure yet that it is.

Kev: that makes sense

Is there more to discuss on this right now, or shall we move on?

move on

5) Date of next meeting.

The same could go for XEP-0060, but I'm not that far to reach a conclusion on that yet.

Same old story?

WFM

+1

wfm, though I'm terribly confused by all these changes :)

and the fact that there was a meeting last week with no agenda

heh

I can't keep up

(-:

MattJ: I thought we could meet in case there was AOB.

what are the changes?

Aren't the meetings usually Tuesday?

I was going to suggest we cancel, and then I realised that other people might come along with AOB for us and be horribly disappointed that we weren't here.

No, Wednesday, have been for aages :)

+1 for same time

they've been Wednesday

We did Tuesday for a brief while and then switched back.

we did a couple of Tuesdays because I'm a git

Well yes, it's been Wednesday forever

(as far back as my memory goes)

then we switch to Tuesday and I get used to it

as long as I can blame linuxwolf it's fine

Ok, I'll assume we're on for SBTSBC then.

6) AOB?

-

nack

calendar updated

nay

Thanks Peter.

Ok, then I think we're done.

Thanks all.

Fini.

BTW I shall fix up pubsub-since before publishing it

and 6 minutes to spare (-:

stpeter, btw any progress on the fosdem/summit recap for http://xmpp.org? anyway i could help?

oh yeah

I'm applying for GSoC in between trying to get work done, BTW.

Florian's helping with some stuff.

We need to put out a call for ideas, once Florian's sorted out that page.

Thanks Kev, +1 to GSoC if people can manage it :)

Kev: are we working on the application via wiki or somesuch?

I was going to try and find last year's, and mostly duplicate it.

Do you want to help?

yes

although the mostly duplicate strategy sounds good

I'll need something to occupy my time in Life After IESG™

Yees.

Hmm, I notice both XEP-0045 and XEP-0060 are still Draft.

yeah..we have just 11 final XEPs

right, the observation makes me less nervous about splitting stuff up.

Heh

I was hoping we could push 45 to final less than 10 years after it went to draft, but probably no such luck

Criteria?

"been in the Draft state for at least six (6) months, has been implemented in at least two separate codebases, and has been voted forward on the standards track by the XMPP Council."

Zash: quoting XEP-0001 on us, huh?

;P

Seriously, though, it was never deemed ready for a vote, so far.