XMPP Council - 2013-05-08

anything important on the agenda for today?

The two proposals from yesterday.

do we want to handle them this week or next? might be a bit close for today...

Today seems fine, we have two weeks to deal with them after the meeting.

mea culpa

I will not be able to attend today

even if I appear online!

howdy

hi

brb

m&m: Ta.

Right, it is time.

1) Roll call.

I'm here.

soami

Me to

o

I poked Ralph, and m&m's not here.

"Harpier cries 'Tis time, 'tis time."

2)http://xmpp.org/extensions/inbox/pubsub-subs.html Accept?

Kev: http://xmpp.org/extensions/inbox/pubsub-subs.html: XEP-xxxx: Pubsub Subscription

I didn't really get the whole 'id' thing in this.

I think it's so you don't end up with duplicates, for example

And I'm not sure that the security considerations should have been copy/pasted from user tune :)

or can easily check for the presence of an item in the list

The hash isn't correct, I checked :)

It doesn't have a JID in it anyway

But, can't you easily check for the presence of an item in the list anyway?

How?

http://xmpp.org/extensions/xep-0060.html#entity-subscriptions ← What about that format that already exists?

Zash: http://xmpp.org/extensions/xep-0060.html#entity-subscriptions: XEP-0060: Publish-Subscribe

why not just use UUIDs?

Zash: It's a reasonable question - although I think the one-sub per item they're going for might be sensible.

stpeter, well then you can let the server generate them for you... but that still lets you have duplicates of a subscription

MattJ: ah, sure

MattJ: But won't you only have duplicates of a subscription if you put them there?

Or are you thinking of two clients with a race condition?

With the hash, if I want to see if someone is subscribed to a node, I can just do a simple iq get for that item id

Well two clients is a case it could easily happen

given that we deferred most of the other "User *" specs for lack of interest years ago, I wonder what the compelling use cases are here...

stpeter: Presumably they have a use for it, and we don't judge community interest until going to Draft.

So I'm not opposing it.

Me neither, it has some editorial work to be done, but I like it

Kev: agreed, I was just curious

i'm with MattJ here

3) http://xmpp.org/extensions/inbox/http-over-xmpp.html

Kev: http://xmpp.org/extensions/inbox/http-over-xmpp.html: XEP-xxxx: HTTP over XMPP transport

I need to read this.

I'm assuming the ultimate aim is to do XMPP over BOSH over HTTP over XMPP over websockets?

heehee

yeah..who wouldn't want that...

Heh

probably it's to tunnel HTTP over XMPP-over-EXI

for some reason :-)

It reminded me of this part of an interview with jer: http://prosody.im/pastebin/95529bb1-b125-46ff-ab0e-526f78b4f176

wouldn't shoving it through IBB be way easier?

To be entirely fair, I /can/ see situations in which HTTP over XMPP might be a sensible thing to do.

...in 2001

now, I admit it would have been helpful for our friends in Cuba a few years ago

So I need to vote onlist for this.

Matt /Tobias?

I'm +1, but as ever it needs some work :)

i'll vote on list too, after i've read it

OK.

My thought on it is that people are going to do it anyway, and it's best to spec it

4) Date of next. I can't do next week. Week after?

and this doesn't seem like a terrible solution

Week after is fine

MattJ: I'm not opposed to the principle, but I've not read the spec at all, and I want to before voting.

Yep, I understand :)

I'll take that as an OK from Tobias.

5) Any other business?

yeah..fine with me as long as it ends up in the calendar

as to AOB, the http-over-xmpp proposal raised the issue of whether we can re-use SHIM headers

I also haven't read that thread.

heh ok

I've read the thread, but not the SHIM spec

our resident literalist took issue with my suggestion

:)

Kev: no worries, we can discuss on the list

maybe XEP-0131 was worded too narrowly

I don't have anything intelligent to say here, at least.

yep, understood :-)

stpeter, you speak in the past tense, but it's still Draft :)

Although, at a very high level, I'm not sure re-use of 131 buys very much if people don't implement 131 much :)

But anyway, I'll try to catch up and comment on list.

was, is, has been, will be...

yep

What will be will be

OK, we're done then?

i think so

Right, thanks all.

thanks you

Thanks

Tobias: shall I update the calendar to remove next week's meeting?

will it annoy people too much when it's wrong? :)

maybe I'll add some June meetings while I'm at it

i don't care personally

fixing it now

hmm, lots of php5-cgi processes using memory on athena, will have to check into that

er, lots of CPU

wordpress :)

it's evil

moar caching!

less dynamic pages

calendar updated

Ta.