XMPP Council - 2010-03-29

!ping

Hi Ralph.

Hi Remko.

hidiho

Give me 60 seconds to finish the iteam minutes, and see if Matt gets back in time.

howdy

Hi Peter. You should be relaxing :p

:P

hi peter

mostly just catching up today

lots of errands

hi Remko!

Ok, let's get started and we can backpedal if Matt arrives in the next 3 minutes or so.

I cleared out much of my unread mailinglist stuff

1) Roll call. Kev, Ralph, Remko here, Matt probably not here with apologies.

ralphm: I think you're current, indeed, thanks.

2) Agenda bashing.

Anyone?

psa: I had over 3000

ouch

I think I'm on ~1000. Only 257 threads with unread messages, though.

Anyway.

I'll assume that's a "no-bashing" :)

no bashing

(Just had a 20minutes iteam meeting, going to try and beat that)

heh

3) XEP-0136: Message Archiving http://xmpp.org/extensions/tmp/xep-0136-1.2.html Diff: http://xmpp.org/extensions/diff/api/xep/0136/diff/1.1/vs/1.2rc1 Votes needed from Kev, Matt, Remko

(I didn't actually read most of it)

Matt voted +1 today.

i promise to vote on-list

+1 given that today is a snipperdag for me ;-)

remko: today is the last day for voting on this.

snipperdagen WTF

psa: i have a snipperdag tomorrow ;-)

kev: ok, in that case +0

Matt did have some remarks

well, +1 actually, i did read them

I'm unhappy with this, because it feels wrong.

about the complexity

It feels complicated, and not fully thought out.

I don't have any one specific exception to it, though.

kev: so, what do we do about this then?

My problem is that 136 was mostly workable before all this complexity, and was Draft. It's now going to be more complicated, without any interop testing and no idea how well it'll work.

is it about the new stuff, the rewrite or the whole thing?

naturally, most of it is too complicated

(the complexity issues)

ralphm: it wasn't trivial to start with, but the new stuff feels very complex.

all the Ian stuff is too complicated

remko: yes, that's the question, I'm debating whether to block it until I'm convinced it's sensible, or not.

right

Kev: so if you really feel it needs a second look, -1 it?

the xep is already very complicated indeed

I don't want to be 'that guy' if it's just me and the world wants to move on.

Kev: it is our job, really

we've killed off most of that stuff -- looking forward to an end to XEP-0155 too

psa: as one of the authors, how do you feel about the complaints?

the entire spec is too complex

the spec or the protocol itself?

clearly people have implemented it

the protocol

psa: they've only implemented the old one though, haven't they?

I thought there was no server support for the new stuff.

If we've got interoperable implementations, I don't have much of an argument to have.

Alexander and Yann have implemented the new stuff AFAIK, in ejabberd and gajim respectively

i thought there was

Ah.

do the implementations implement all of the (old) aspects

?

ralphm: that, I'm not sure

ralphm: quite possibly not

I mean, if most of the complexity is not implemented, maybe we can cut stuff there?

I'll +0 it, then, but can we attach a Council note saying that I'm uncomfortable with the complexity, and that it should have a review and possible simplification if needed?

the XSF needs an interoperability process so that we can reduce complexity before pushing things to Final

psa: yeah

i'm +0ing too

Kev: that does not seem unreasonable

IMHO we need to take a close look at this one

Excellent, thanks.

and simplify

so that basically means that we are now accepting the changes but don't like it?

This is something I do actually care about - server side history is great.

right now the protocol has too many bells and whistles and options

*nod*

ralphm: if half of council are in favour of the changes (you and Matt), half of Council don't like it, but don't have a specific complaint to block with (Remko and me), and there are interoperable implementations of the new stuff...I think that's a good summary, yeah.

as a first step, I think we need to gather a list of implementations (not sure if Google ever implemented it with this namespace) and poll them regarding which particular features they implement

Kev: I'm ok with the changes, yes. On the complexity, maybe the whole thing needs to be reconsidered

ralphm: yeah

psa: I think that'd be good.

so perhaps the Council can write up a note that we can add to the spec

There's also scope for a Simplified Message Archiving spec if such a thing is needed, or whatever.

so a Call for Experience

psa: I'll take that action.

ralphm: only with a little c, because it's not a CfE :)

Or are we allowed to issue those without advancement?

ralphm: well, we issue a CfE only when we want to move ot Final

sure we can

hmm

In any case, yes.

I'll write a note, and we'll ask for experience.

we *have* issued those only before advancing to Final

14 minutes gone, let's get a wriggle on :)

we want to move this eventually, and as-is we don't seem to like it much

doesn't mean we couldn't do so under other circumstances

4) XEP-0184: Message Receipts http://xmpp.org/extensions/tmp/xep-0184-1.1.html http://xmpp.org/extensions/diff/api/xep/0184/diff/1.0/vs/1.1rc7 Updated to reflect Kev's objections. Accept 1.1rc7?

I'm +1 after the latest changes.

Ralph's already +1d

I like it much better now

Kev's criticisms were quite warranted

good changes, indeed

kev: is there still time to vote for this tomorrow for me?

remko: yes, voting on this starts tonight, you've got a fortnight.

ok

5) Distributed MUC http://www.xmpp.org/extensions/inbox/dmuc2.html Another distributed MUC proposal - accept as Experimental?

+1

Would it be better to accept this as a competing Experimental, or have the XEP authors work together on the existing Experimental?

I'm not opposed to either approach.

psa / fippo: what are your thoughts?

I prefer both

i don't mind publishing this as an experimental for aske of history, and then merging both

I admit that I didn't get to read fippo's document as I had hoped to on the flight back from IETF 77

s/aske/sake/

psa: I have comments on both dmucs, but I'm happy to have both on the vine.

So I'm not not objecting to publishing.

I like to publish documents :)

as is well-known

Ok.

in the early days we had 3 or 4 pubsub specs, as Ralph no doubt recalls

dmuc2 is not complete yet. I am especially interested in the netsplit/join stuff

psa: indeed

psa: and you added all four together to get the monster we have now? :)

dmuc1 is not complete, either

psa: sure

No, both are WIPs

Anyway, shall we move onto 6) Fifth member. Nathan and Jack standing.

Kev: actually, no. The first pubsub spec worked with IQs :-)

Where are they standing?

Shush.

:-P

I'm sure either Jack or Fritzy would be a fine fifth member.

indeed

[oh, I have two AOB items...]

Kev: as am I

Given that Jack's done this before, and he's on Board, I'm inclined to suggest Nathan for some fresh perspective, and to avoid getting too inbred, but I'd be very happy with either.

same comment from me.

it also seemed that jack was willing to do this more as a fallback, but i might be wrong

I asked Fabio as well, as he applied at the start of the session, but he's snowed under at the moment.

despite the fact that I lack a vote in the matter, I agree with the sentiment of having new people on the Council -- it's a form of recycling

ralphm: what think you on Jack and Nathan?

Kev: I had the same feeling

and I'm sure Jack just wants the spot filled

Ok, we'll wait for Matt to express an opinion on-list, but that looks like Fritzy unless some terrible secret comes forward.

heh

Ok, AOB. I believe someone's waiting in the wings with two items...

since there is no actual process, do we vote or is it a humming thing?

ok, AOB

ralphm: we vote. I'm assuming that until Matt votes we have the chance to revoke our previous votes, though, thus not taking it as done yet.

ok

I think it's a vote but that's not explicit at http://xmpp.org/council/policies.shtml

ok

first AOB, Thursday is April 1 :P

psa: when I checked the bylaws, I believe it said 'vote'

oh no

will we be fooled again?

so I might cook something up for April 1, but I haven't come up with anything yet

remko: Guess who I'm listening to at the moment ;)

and select a new member from among the applicants.

psa: OK. It's not strictly vital to have an AFD post, you know.

last week was busy (as were all the weeks leading up to IETF 77)

Kev: true -- I prefer quality over quantity

second AOB

don't leave us hanging here

at IETF 77 I met with a guy who has an implementation of http://xmpp.org/extensions/inbox/sxe.html for whiteboarding (so that includes http://xmpp.org/extensions/inbox/whiteboard.html I suppose)

and he is working on fixes to that spec

Oh, great.

excellent, taht spec needed some love

in fact I heard from someone else recently who has implemented it

this is the muc based one, yeah?

ralphm: it can go through MUC

the guy I met with implemented it over link-local

ralphm: but it doesn't need to go over MUC

ah

anyway, I wanted you guys to know that we might have a revised version to consider soon for publication

cool

I seem to recall that we had discussions about this at Fosdem.

that's it from me

Although possibly it was at dinner.

Kev: I don't recall discussions, but I wasn't there on Friday

Oh, I remember

It was how you can use whiteboarding over muc assuming the muc knows nothing about whiteboarding

yes

but if you /do/ have a whiteboarding-enabled muc, it can make things much better for people joining an active whiteboard later.

right

Ok, that's easy to put into any spec.

I am wondering if the suggestions around pubsub in mucs would help this effort

So, we've a minute over my half hour tolerance.

nothing more from me

Unless there are any other other businesses, I suggest we close.

next meeting?

OH, next ...

right

same time next week?

next week

Ah, no.

It's Easter Monday.

Shall we treat ourselves to a week off?

ok

Next meeting same time a fortnight today, then.

sounds good

WFM

Excellent, thanks all.

thanks

thanks guys

I'll sort out minutes before too long.

thanks

I'll soon go back to being offline :)

psa: noooo

psa: about XEP-0060, the remarks around node deletion with redirect are basically this:

1) it uses jid/node attributes, rather than the uri thing I have implemented

2) There is no mention of the <redirect/> being sent along with notifications.

actually I only implemented 2 with a <delete node='test'><redirect uri='xmpp:example.org?;node=test2'></delete>

and did not implement the stuff for requesting delete with redirect, because that's internal to my implementation

ok

I am not really wedded to using URIs, per se

URI is consistent with http://xmpp.org/extensions/tmp/xep-0060-1.13.html#example-44

except that is not allowed by Core

i.e., the <gone/> error in XMPP core

'cause that mentions that the character data must be a JID

even in bis?

no in 3920

I think URI is better, but then we need to grandfather JIDs in

(e.g. by accepting schema-less URIs)

yes

a redirect on node acces example should be in XEP-0060, next to the one you linked to

and then we now get to decide on using URIs or jid/node for the delete+redirect request and notification

what do you mean by "2) There is no mention of the <redirect/> being sent along with notifications."?

in a delete event notification sent out to (former) subscribers of the node

it should include the redirect

you mean at http://xmpp.org/extensions/tmp/xep-0060-1.13.html#example-158

yes

we need the redirect there

this is essential for making redirects work

yes

so /that/ is actually the only thing I implemented

that = with <redirect/> ?

er

without

delete notification with redirect

ok

that's better

(if a redirect is in place, naturally :)

I didn't implement 8.4.1

because node deletion is internal to my implementation

yes, of course it is optional

so with jid/node it would look like this:

<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <delete node='princely_musings'>/> </event> </message>

oops

<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <delete node='princely_musings'> <redirect jid='pubsub.shakespeare.lit' node='something_else'/> </delete> </event> </message>

vs.

<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <delete node='princely_musings'> <redirect uri='xmpp:pubsub.shakespeare.lit?;node=something_else'/> </delete> </event> </message>

right

Using URIs has the potential of hybrid protocol solutions

I am not sure if we need to cater for that

the only reason to use URIs in the error element is because it requires character data

true

and URIs are an easy way to specify JID+node

they look funny, but they are easy :)

it is still too bad the first element is required (even if it may be empty)

anyway, in the end I have no real preference

the uri stuff is currently in wokkel

but the only working deployment is under my control

(that I know of)

I think URIs are preferable simply because new subscribers are going to receive an XMPP <gone/> error with a URI anyway (under 3920bis)

the lack of a <redirect/> error in the examples right now is a simple spec bug so I will fix that

s/error/element/

ok, let's go with URIs then

+1

leaves the possibility to go to PuSH or some other fancy other thing

yep

now I am going to relax a bit. Have a good snipperdag!

:)

ralphm: where do we stand on IQ notifications?

oh, nobody replied to my post

ah I see it

I'll try to do that tomorrow

thanks for the reply

drop me a line to chat on it, if needed

ok

will do

cool

now, back to our regularly schedule snipperdag :)

:-)

+d

thanks, Ralph!

and you