XMPP Council - 2011-12-20

meeting begins in 1 minute?

It does.

it seems that some pokage in order :)

I've poked Ralph.

I don't see Tobias or Matt online.

aha ok

seems not

/-;

clearly these guys don't live by the calendar

Matt's just come online.

Sorry I'm late - someone was using my computer :)

The cheek.

Indeed

Well, we have quorum.

/whew

Or a quorum, probably.

So, assuming we're keeping last term's lateness rules in place, let's start.

1) Roll call.

I'm here.

presente

Here

2) DMUC3

Heh

We should really make a decision about this.

/sigh

I don't like it, but I'm abstaining from a veto.

Have you both read this now

cat fmuc.xml | sed 's/proxy/mirror/g'

?

:)

I have, and yes, DMUC3 looks a lot like a FMUC

Now, it *does* have some differentiating text

So I'm just going to assume they used FMUC as a base as it was closest to what they wanted

(I note that we now have an implementation of FMUC, and I have updates to do once I'm not 'on holiday' in the new year accordingly)

MattJ: so it seems

But considering the end result is still somewhat the FMUC flow, I'm not sure we need another XEP doing the same thing

especially considering FMUC is still experimental

I'd rather the author's feedback on why FMUC doesn't work for them, and how it can be made to work

Indeed

precisely

hi

Hi Tobias.

MattJ: true, that would be helpful

It turns out that FMUC is pretty easy to implement, especially in fire-and-forget mode, so I'm expecting MattJ will be implementing this in Prosody shortly after I update the XEP :)

(-:

Then I'll probably call for a move to draft, as we'll have two (hopefully interopping) implementations :)

FWIW, I've been having some chats with people off-list about distributed chat (e.g., doing a better job of defining the requirements)

But I have to drastically improve the state of the XEP before then.

Kev, interestingly I already implemented it before you published the XEP :)

stpeter: Yes, so've I.

so, the action on DMUC3 … reject with a request from the authors to explain what's broken in FMUC?

But without the remote MUC sending just one stanza per event to the proxy

MattJ: So...isn't that MUC, then? :)

The problem with FMUC is that it requires the primary MUC to support it

Ah, right.

Kev, well if s2s went down, the users could still chat locally

Gotcha.

This doesn't need any extra protocol work, to do it your way.

Agreed

linuxwolf, I agree

It doesn't cover the use cases for (F|D)MUC, though :)

Well, not some of them, anyway.

Yep

linuxwolf: That seems reasonable to me.

I've also reached out to the folks at http://www.cococorp.com/ -- they have an implementation of XMPP over NORM (RFC 5740) that seems to be quite interesting and I would like to make sure that anything that's defined for link-local-ish chat would work with distributed chatrooms (I have a sense that this would be the case for FMUC, but I'm not sure yet)

As someone abstaining :D

stpeter: Ok.

ok, I'll take the responsibility of rejecting DMUC3 then (-:

I'll get something on the list before the end of the week

Ta.

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

I don't see any particular reason to reject this.

no objections from me

Especially when the examples mention my party

+1

Incidentally, does anyone mind that my flow is usually: Present item Express my opinion

how does it and file transfer thumbnails work together?

isn't that metadata too?

It occurs to me that this could potentially be considered leading the discussion the way the Chair wants it.

Kev, nope, go ahead :)

Equally, I consider you all sufficiently independent to not be put off by it ;)

I pay more attention to linuxwolf, I agree with everything he says

Excellent.

Kev: I'll call you out if I think there's over bias (-:

Tobias: It is, yes.

thumbnails = http://xmpp.org/extensions/xep-0264.html

haha

+1

Tobias: I don't *think* it conflicts with that - do you think it does?

Or are you suggesting they should be rolled together?

Kev, right...the reference to the thumbnail could be included in the metadata form as a field

I'd prefer we figure out a way to add things without rolling all of these meta-data things into one über-meta-spec

yay, über-meta!

but I'd not object to rolling everything together

So, what's the tone here? Accept it and extend it for other extensions, or reject for not being complete?

I'm on the first of these.

especially considering that thumbnail is currently deferred

I

gah

Kev, pidgin transfers thumbnails via bits of binary

linuxwolf: it was deferred mostly because we were waiting to finish the other FT specs

I'd accept as is, and work in extensions by draft

linuxwolf: wfm

right

Does anyone disagree with this?

i'm all okay for accepting it as experimental

I agree with linuxwolf

Cool.

4) 47 to Final

Which I think means 47 Last Call.

Ahem.

CFI

+1

+1

+1

those Final XEPs are so lonely, they need some more friends...

:)

Ok. Peter gets to issue a CFE then. Lucky Peter :)

let's make sure every t is dotted and i is crossed, though (-:

(+1)

5) 292 to Draft

I think this is premature.

I won't issue the CFE until January

oh yes 292 to Draft is premature, maybe I mentioned it to figure out how we can get it to Draft eventually -- sorry about that

We already have a widely deployed vCard standard. It's icky and may well be Wrong, but I think advancing 292 until there's implementation experience seems premature.

isn't that even implemented somewhere vCard4 over XMPP?

*is

Tobias: not yet, that I'm aware of

Tobias: No, but if Peter says I misread his intention, we can move along :)

Link Mauve has a module for Prosody, but it's experimental at the moment

k

5) 45 1.25.

+1

I'd like to do this next year.

agreed

I need to re-read it again

I read the whole thing last night... :)

yeah it's rather large

As I'm 'on holiday' until then, and would rather not spend my time off reading all of 45.

MattJ: good for you :)

last "morning" night

Kev: fully agree!

Ok. So we're agreed to discuss it next year then, fab.

7) Date of next meeting.

January 4th, 5pm GMT?

+1

-1; other commitments

11th?

+1

+1

I can do 1/3 @ 17:00 UTC

I'll likely be slammed on the 4th with IESG reading

stpeter, the IESG doesn't take a holiday for Christmas? :)

11th is fine with me

MattJ: we do, sort of, but we have a big telechat on the 5th

I'll have to get back to you about the 11th … I have a standing meeting at that time, but my participation is not always mandatory

Wednesdays and Thursdays are very meeting heavy for me

Should we be doing a different day, then?

I would rather neither Monday or Friday, but Tuesday seems generally doable for me.

I was able to do 16:00 UTC … 17:00UTC is 10:00 MST, which is when everyone else schedules their meetings /-:

Tuesday is better than Wednesday for me, at least through the end of March

linuxwolf: Ah, so it's all Tobias's fault. That makes sense.

Tuesdays are better, although I'd likely miss every 3rd meeting

(-:

i could do tuesdays too

Tuesday 3rd January 1700?

wfm

(With a plan to make this the regular slot)

okay

+1

Ok.

/whew

8) Any other business?

Not here

although the 4th would be an appropriate date for a meeting, given that Jer released jabberd on January 4, 1999 ;-)

so we'll celebrate the eve of the release (-:

Right.

no aob from me

Ok, I tihnk we're done.

Thanks all

Consider yourselves gavelbanged.

ouch

(-:

:)

stpeter, btw: do you wheter MSFT's OAuth2 authentication for their XMPP interface is using the new OAuth SASL mechanism http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt ?

i have the feeling not but i thought you might know more

Tobias: I am not sure, but I can inquire

I also want to find out if they have plans for s2s

i mean if they decide on OAuth it'd a nice move of them to go along with that draft or if it's not what they want discuss it with the authors of that draft

MattJ: thanks for the MUC notes

np

Tobias: indeed :)

Tobias: ok I've pinged one of my MS contacts

thx

ok, that's done! :)

IRIs are the bane of my existence

I read "IRS" at first

heh

I haven't had trouble with the IRS in quite some time