XMPP Council - 2012-11-21

T-2 hours.

am I early or late?

Early.

32 minutes.

yay

holiday + timezone differences == confusion

Honoured you're taking time out of the holiday to chat to us... :)

well, I suppose we should have a first meeting at some point before 2013 (-:

It does seem desirable.

I've poked Ralph, but he's got another minute anyway :)

Ah, and at that moment his client auto-idles :)

I did check with him last night that he'd be here, so shall we give him a few minutes?

sure

I'm fairly keen that for electing a chair everyone's here, even if for no other votes of the year :)

exacetally

here

Excellent. Just Ralph, then.

hrm

I'm in no hurry, FWIW :)

so for this kev had to wake me up ^^

MattJ: m&m's on holiday, it'd be nice to not keep him indefinitely :)

heh

I didn't say m&m wasn't in a hurry

Obviously the rest of you I don't care about :D

haha

Board had to vote on a Chair yesterday with just 3/5 present.

So we'll beat that with 4/5 even if Ralph doesn't appear :)

I'd suggest if we wait until 15past and then go ahead regardless it'd seem fair - what do others think?

at least it's quorum

that works for me

I'm not in a hurry

\o/

I'm +1 to :15

Ok, for want of something to discuss, and while we're all here...

*mostly all here

I'm mostly all there.

http://matthewwild.co.uk/uploads/xep-json.html

MattJ: http://matthewwild.co.uk/uploads/xep-json.html: XEP-xxxx: JSON container

Shush Kanchil

|-:

Heh

It's quarter past.

let's just do this

I guess we should go ahead, if we want to be sure of finishing on time.

1) Roll call.

I'm here.

presente

Also

Tobias was here 7 minutes ago. I hope he's still here now :)

I guess we'll find out if he's not when we do (2) :)

2) Electing chair.

yup

presente

I'm happy to do it. Would anyone else like to be considered?

*tumbleweed*

I'm fine playing backup (-:

yeah..let's all vote on backup :P

Heh

(-:

Heh.

Should I take that as "no-one else standing", then?

yesh

In which case: Vote for Kev to be chair...

+1

+1 to Kev

+1

+1

Shocking

Marvellous.

Without even resorting to threats of physical violence.

*ouch*

3) Message Forwarding. Last Call?

+1

+1

That's "Stanza Forwarding', actually, isn't it?

It is

297, in any case.

yes

I'm +1 on an LC.

can you also forward IQs?

Tobias: If you want to.

Yes

then +1

I won't pretend that's useful though

there's limited applicability for IQs

I can only come up with contrived examples, at first glance.

such as end-to-end encryptkon

encryption

which I need to add to the draft

I'm +1 too.

4) Date of next meeting

I'm starting to feel obligated to anticipate all the horrible ways people might use XEPs I write and include "Please don't do this" requests

Next Wednesday, 1600UTC?

Kev: +1

wfm

wfm

MattJ: the only solution is to not write XEPs (-:

Marvellous. Board have timed their meetings to be weekly, immediately subsequent to Council this year, which is convenient if anyone wants to drop in and heckle.

Easier said than done

Oh, no, it's quite easy.

Kev, yes, that's a great idea

You just join the MUC and make irrelevant comments.

They're still in xsf@?

...oh, you didn't mean that :D

Yes.

(-:

5) Any other business

I'll do my now traditional "Anything anyone wants to change about the way Council is chaired/run this year?" question.

*crickets*

_̎

It's been pretty ok with me, except when meeting times change, or when I think they have, but they haven't really

I've now, I hope, passed the ludicrously busy spell I had the last couple of months. I've not had to go on site for multiple weeks in a row \o/.

heh

OK.

Any other any other business?

Not here

nay

nope

Marvellous. Despite a delayed start, 4 minutes to spare.

Any informal comments on the jay-son thingie? I fully intend to submit it otherwise :)

Thanks all :)

Thanks Kev

MattJ: I think it's a bit nasty, and likely to cause pain, but it's something there's a (perceived) requirement for, so who am I to judge?

What pain might it cause? and what (if anything) can be done to prevent it?

MattJ: to be frank, I almost no benefit to it … you still need context

I can't be the only person who thinks JSON in <body/> is evil

I think that's evil also, but I also don't see a point to a single wrapper for all cases of JSON

guidelines for how one mixes in JSON to XMPP, sure

a single container … no

MattJ: I don't think that specification for including JSON causes pain, particularly. More that mixing content types like that doesn't seem to buy very much, and JSON isn't all that great for things that need interop and extensibility etc., and ...

m&m: This is true, but at least for the way Swift does parsing/serialising, having all json always in the same wrapper element (which is then within a context element) would be convenient.

*Swiften

So I'm not particularly opposed to saying "If your protocol is shipping JSON, shove it inside <this> element, within your own namespaced element.

As example 2 does in MattJ's spec.

Right

Compare to 297 and xhtml-im

That's pretty much exactly what it's intended for

frankly, I'd only be ok if it always had to be wrapped by something else

MattJ: So I think maybe example 1 should go.

I'm ok with that

in fact, I'm not sure 297 should be present without somehting wrapping it

something even

m&m: 297 does have a use case for this, which is that sometimes you really do just want to forward a message as a real forward.

But many closed "XMPP as middleware" do already do the JSON-in-body hack, I've seen it in multiple places now, and I wince every time

The "context" there is the sender and recipient

MattJ: I'm not saying it won't happen

I agree that's not pretty, but it's reality

MattJ: Where interop isn't required, I don't really much care what people do :)

I do, or they might as well not be using XMPP :)

You can encode stuff in a message body for all I care as long as it doesn't reach anyone else's system :)

and I see this as a step up from what they do now

I've had to interface with such systems :(

As soon as you need to interface with them, interop's required.

And it starts being clearly wrong :)

So, happy with a "SHOULD" be inside another element?

I think that sounds good to me

I'm happy with a MUST

Heh

TBH, I don't see much of an argument to not say MUST, although hills, etc.

In as much as anyone who's going to ignore it is going to ignore the XEP completely.

Right

But they can be coaxed in the right direction

They're not going to say "Oh, well, I'm happy to put it in this wrapper element, but my own namespace? That's just a bridge too far, melad"

That's mostly the intention

They'll either swallow it and do the right thing, or ignore everything the spec says completely :)

So you may as well say MUST do the right thing.

!xep 297

MattJ: XEP-0297(forwarding): http://xmpp.org/extensions/xep-0297.html Stanza Forwarding - Standards Track/Experimental - Updated: 2012-07-05

Ah, are we talking about 297 or JSON now?

I was talking about JSON.

JSON

I thought we were talking about JSON

I'm just cross-referencing language :)

OK.

!xep 231

Zash: XEP-0231(bob): http://xmpp.org/extensions/xep-0231.html Bits of Binary - Standards Track/Draft - Updated: 2008-09-03