XMPP Council - 2011-03-16

!agendaappend XEP-0237: Roster Versioning Accept version 1.2? http://xmpp.org/extensions/diff/api/xep/0237/diff/1.1/vs/1.2rc1 http://xmpp.org/extensions/tmp/xep-0237-1.2.html

Kev: Done.

!agendaup -6

Kev: 0) Fini.

!agendaup

Kev: 1) Roll call

!agendaup -1

Kev: 0) Fini.

!agenda

Oh. It's not here.

It is here, it just won't listen to you

!agenda

Kev: 1) Roll call 2) Agenda bashing 3) Proposed XMPP Extension: Jingle RTP Header Extensions Negotiation http://www.xmpp.org/extensions/inbox/rtp-hdrext.html Accept as XEP? 4) Proposed XMPP Extension: Jingle RTP Feedback Negotiation http://www.xmpp.org/extensions/inbox/rtcp-fb.html Accept as XEP? 5) Proposed XMPP Extension: Sensor-Over-XMPP http://www.xmpp.org/extensions/inbox/sensors.html Accept as XEP? 6) XEP-0237: Roster Versioning Accept version 1.2? http://xmpp.org/extensions/diff/api/xep/0237/diff/1.1/vs/1.2rc1 http://xmpp.org/extensions/tmp/xep-0237-1.2.html 7) Date of next meeting 8) Any other business Fini

Interesting. I don't see it...

Are you looking at the moderators?

Yes. Probably it's just that I really need to update my server to a recent build. :-)

Oh, either that or I got desynched at some point.

Could be.

ah, from my perspective today's Council meeting is shifted forward an hour -- I think European countries go forward on March 26, right?

Sounds right for the UK.

great, I get to lose two hours this year because I'll be in Prague then

I was aware the US wasn't in sync with the UK (is it even in sync with itself?), that's why I warned everyone last week :)

plus I lose that hour the night I arrive -- fun :)

ah, the glamour of international travel

Enjoy :)

Kev: BTW I noticed http://wiki.xmpp.org/web/Radar in the room subject -- perhaps I should delete that page or redirect it to http://xmpp.org/about-xmpp/xsf/xmpp-council/

XMPP Council Room | http://xmpp.org/about-xmpp/xsf/xmpp-council/ | Room logs: http://logs.xmpp.org/council/

One hour.

For those wondering about timezones :)

(-:

hi Ralph and Fritzy!

howdy

Right, enough time to graba sammich :)

!agenda

Kanchil+ is so capricious

maybe Kanchil ain't feeling so plus today

!agenda

Kev: 1) Roll call 2) Agenda bashing 3) Proposed XMPP Extension: Jingle RTP Header Extensions Negotiation http://www.xmpp.org/extensions/inbox/rtp-hdrext.html Accept as XEP? 4) Proposed XMPP Extension: Jingle RTP Feedback Negotiation http://www.xmpp.org/extensions/inbox/rtcp-fb.html Accept as XEP? 5) Proposed XMPP Extension: Sensor-Over-XMPP http://www.xmpp.org/extensions/inbox/sensors.html Accept as XEP? 6) XEP-0237: Roster Versioning Accept version 1.2? http://xmpp.org/extensions/diff/api/xep/0237/diff/1.1/vs/1.2rc1 http://xmpp.org/extensions/tmp/xep-0237-1.2.html 7) Date of next meeting 8) Any other business Fini

Seems good to me :)

:P

I do have a patch to make that command "anyone" instead of "owner", but haven't deployed it.

Anyway, it is time.

Fritzy, linuxwolf, ralphm: PIING :)

!agendaup

Kev: 1) Roll call

I'm here

pong

MattJ sent apologies.

woot

Fritzy: you there?

yeah

Jolly good.

!agendaup

Kev: 2) Agenda bashing

I like what we have today

No-one, then?

Jolly good :)

I'd like to talk about..

gah…slow down there, Tex

:)

:)

moving carbons fwd (-:

that's it

!agendaappend Moving carbons forward.

Kev: Done.

!agendaup

Kev: 3) Proposed XMPP Extension: Jingle RTP Header Extensions Negotiation http://www.xmpp.org/extensions/inbox/rtp-hdrext.html Accept as XEP?

I'm ok with this.

+1

it seems fine to me +1

ralphm: ?

I was wondering if sdp is used in combination with jingle

A question - is there any mileage in having entities advertise supported RTP headers via Disco as well?

ralphm, We basically use the same semantics as SDP but within an XML syntax, in Jingle.

right

You know, CSN would be useful in MUCs sometimes...

(-:

dwd: sounds like a good question to ask on the jingle@ list

Kev: in meetings, yes

dwd: I think that could be useful, and could easily be added to the spec... but I don't know the answer.

to the list!

ralphm: Did you have an opinion on it right now?

I mean, it's already there

I'm +1

Ta.

I'm assuming dwd volunteered to mail the list with the question.

!agendaup

Kev: 4) Proposed XMPP Extension: Jingle RTP Feedback Negotiation http://www.xmpp.org/extensions/inbox/rtcp-fb.html Accept as XEP?

I'm similarly +1 on this.

also +1

yup, along the same lines +1

ralphm: ?

So as this is another SDP reframed, is it worth considering making a generic SDP-in-XML specification somewhere instead?

Otherwise someone has to "port" each new SDPism into Jingle, which seems unfortunate.

dwd: I don't think SDP is generically-structured enough for that to be possible

I seem to recall some attempt at that, but SDP isn't generic enough

gah…beat by the saint

+1

dwd: right, that was really my point earlier but I got distracted

dwd: Is that volunteering to bring stuff up on list again?

http://www.scribd.com/doc/95534/Jingle-Multimedia-Description-Using-SDP

is something I found

I never volunteer. I might assign a staff member, though.

which looks horrible

haha, there you go

maybe the council can volunteer dwd

(-:

I can delegate to an underling. :-)

minion, is the term

I didn't realize dwd had minions

heh

Oh, well, that's one way of wrapping SDP, I suppose.

or peon

stpeter, Henchmen.

I have authenticated linuxwolf's identity by his backwards smile

(-;

Ok, moving on then.

!agendaup

Kev: 5) Proposed XMPP Extension: Sensor-Over-XMPP http://www.xmpp.org/extensions/inbox/sensors.html Accept as XEP?

oof

so, I have a concern

that was a hard hard read

This one has enough problems that I'm tempted to -1 it.

I read most of that one. At least the first 270 pages.

Let me find them.

using pubsub to send commands (actuators in this case) is a mis-use.

agreed

Fritzy: Actually, that's one thing that I'm not *too* worried about.

the structuring is awkward…and the differences in timestamping..and ....

Fritzy, Erm... Perhaps. Queueing commands that should be processed by available actuators seems like a non-misuse.

The semantics seem to fit.

I never considered solving this problem domain so generically

dwd: I'll volunteer you for the IESG, then you'll find out about reading long documents...

really, this spec could be watered down to a payload schema and some basic intro.

I had general XEPpish concerns. The XSD should be at the end, not upfront. The use cases shouldn't be duplicated.

Quibbles like SHOULDs for naming, with UUIDs ,and _data/_meta.

Wondering why it advertises iPhones particularly.

Kev, Also there was some redundant text, like the repeated use cases.

Kev: right, and the timestamp stuff etc.

dwd: subtle

Extensibility should probably be through namespaced children, not through generic name/value pairs.

for one thing I'd assume using URIs for defining types

Fritzy, In a brickesque manner.

Fritzy: From the department of redundancy department.

it seems like something that could be split up

The examples aren't actually protocol examples, so there's no easy way of following what actually happens.

Personally I shuddered a bit at the bit where you specify the SI prefix.

I realised after reading that I hadn't noticed a namespace anywhere.

there is almost no protocol here

it is just a payload schema

with some naming convention advice

ralphm's point is a good one -- do we need such a generic approach? (and have other standards groups defined such an approach already so that we can reuse their schema?)

dwd: that too, I'd expect a numeric exponent

Fritzy: Yes, but that's not a good reason not to have a couple of example stanzas, just so you can see what's happening.

IMHO.

but yeah, I really dislike the idea of sending commands over pubsub -- especially the way they are.

on the plus side, it does use "atto", "zepto", and "yocto" ;-)

the few examples I think I see are partial protocol

stpeter: Yes, I was wondering if that was a plus side when I read it :)

stpeter: yeah, I didn't see that as a plus (-:

linuxwolf: Yeah, but not whole stanzas, and not (I think) namespaced.

definitely not namespaces

s/namespaces/namespaced/

Which makes this invalid to implement, even if you read through all the pages.

stpeter: tradionally, we've defined very application specific protocols, formats

ralphm: right

e.g. we used our own geo/address stuff instead of horribly long specs

yeah, I'm not opposed to this being a XEP

and defined mappings, where needed

I don't know, this could be cleaned up, without significant underlying changes probably, so maybe I shouldn't block it.

One thing I did like is that none of the protocol actually defined anything new - this can be done, as I understand things, with a generic XEP-0060 service.

I don't object to the approach, I object to the document.

They should use ad-hoc commands for commands.

heh

So I'm +/-0

and Matt earns another $.25

dwd: we have multiple "payload format" specs, maybe this should be one

BTW, I've been talking of late with a number of "smart grid" / "smart energy" folks and OASIS is defining a whole raft of payload formats, which we could send over XMPP instead of their current default (which is web services)

Fritzy: tell hildjj he owes me $0.25

stpeter: Excellent.

ralphm: agreed

stpeter: I've talked to some of those types too... but it's been about a year.

sounds like we should link this XEP's authors with those folks

I'm still not convinced it should be defined at the XSF, though

(and in fact a number of people in the smart grid space are already using XMPP)

Ok, so, what does everyone think at this stage? I'm +-0

-0

hey, no +/- voting :P

-0 then :p

that's the ticket!

sqrt(-1)

Fritzy has to be irrational

I think this should be redrafted as an informational spec.

but perhaps...

Fritzy: Are you vetoing or not vetoing? (And ralphm the same)

thinking... give me a second

-0

I don't want to discourage them from resubmitting, but I think they should resubmit.

I don't think this should go into experimental.

not in the standards track

So that's a veto, then?

so that's -1?

yeah, -1

Ok, ta.

units="celcius"?

oh, -1 then

:-D

units=votes

obviously that should be Kelvin

ralphm: I'm to assume that's flippant, yes?

Kev: yeah

Fritzy: You'll need to write up an explanation to standards@, with why it's vetod, and what the path forward is then :)

!agendaup

Kev: 6) XEP-0237: Roster Versioning Accept version 1.2? http://xmpp.org/extensions/diff/api/xep/0237/diff/1.1/vs/1.2rc1 http://xmpp.org/extensions/tmp/xep-0237-1.2.html

+1

+1

Kev, will do

+1 :)

whoa

He's there!

Kinda.

+1

Yeah, kinda

+1

In a busy office (that isn't mine), but I managed to get them to set me up with a network connection

!agendaup

Kev: 7) Moving carbons forward.

I'm in a castle.

heh

ok, so

I'm hearing of lots of interest, and we've had a modicum of list discuss

linuxwolf: I have changes I want to make to this, that depend upon MattJ's as-yet-unsubmitted stuff.

Kev: right

So I propose that Matt submits http://doomsong.co.uk/extensions/render/forwarding.html

I'm agreed, and ready to make the edits…once I have something to reference

I update Carbons.

Or you do :)

Then we can advance it :)

Sure

I'm happy to update it

it == message carbons

so what is that the council needs to do now?

ralphm: Council, nothing. Council members (Matt/Matt) need to do stuff :)

cajole Matthew into submitting forwarding (-:

With MattJ first.

Yeah ok... perhaps I can set aside some time on Saturday

I've been having lots of discussions that I need to incorporate

/nod

MattJ: Oh, changes to this?

I have some security concerns with as currently defined, but will wait until you have the update

s/with as/with it as/

in time for next week's meeting I hope to review XEP-0065 one more time and perhaps request a vote on the revisions

stpeter: Ok, great.

(trying to finish off the file transfer stuff)

ooo…I'm just about down with a first draft BCP on resource locking

(finally)

Great.

65? I need to update my implementation for that

So, we're done with this, I think.

!agendaup

Kev: 8) Date of next meeting

Next Wednesday 1600 GMT?

Kev, the lacking thing in MAM/forwarding is specifying an archive-unique id for the message

I'm good with that. +1

+1 for next week

sure

MattJ: I thought that'd go in MAM, but it can go in forwarding I guess. That makes sense.

MattJ: please have a look at http://xmpp.org/extensions/tmp/xep-0065-1.8.html and http://xmpp.org/extensions/diff/api/xep/0065/diff/1.7/vs/1.8rc3 :)

stpeter, thanks

I also wanted to implement the Jingle IBB stuff at the same time

Currently Verse only does Jingle+proxy65

Ok.

!agendaup

Kev: 9) Any other business

Anything else?

Nay

0

world peace?

linuxwolf: Thanks for volunteering.

whirled peas

I'd just nuke'em all

Fritzy: peashake?

calendar updated

Ok, then I guess we're done.

humus?

stpeter: Thanks.

Thanks stpeter

I'll do minutes tomorrowish.

I think we're done then

rad

Thanks all

thanks

!agendaup -10

Kev: -1) Fini.

Kev, FTR I'm happy with the decision on sensor-over-XMPP, but I'll look at the Jingle stuff later

adios all

MattJ: Ok, thanks.

:)

oh yay, another round of AUTH48 review just arrived in my inbox

http://www.rfc-editor.org/authors/rfc6121-diff.html in case you're curious :)

How long has your 48 hours been so far?

about 47 so far

er

no

23

I try to be quick