XMPP Council - 2013-03-27

council metting in 2h?

Yep.

Ding.

Dong.

The witch is dead.

Oh no!

I have poked the Ralph.

ralph seems to be idle

and what time the meeting is

hammer time

Bat time.

Did the clocks change?

1) Roll call.

I am here.

MattJ: Not in Europe yet.

I'm also here

Although they will before the next meeting.

As am I

Ok, so my client is just lying to me

MattJ, the night of this sat/sun

m&m?

Just the three of us then, by the look of it.

2) http://xmpp.org/extensions/inbox/sensor-network-provisioning.html Accept as Experimental?

Kev: http://xmpp.org/extensions/inbox/sensor-network-provisioning.html: XEP-xxxx: XEP - Sensor Networks - Provisioning

got till 3.12 but could tell you my comments so far

Go for it.

I'm at the not-blocking-but-bits-of-it-are-a-bit-weird stage.

Editorial: - images in-line as SVG or Base64ed PNG - glossary could use definition list syntax instead of table Formal: - Example 1: 'get' and 'response' in node names is a bit redundant. The info is already available in the IQ-type. - Example 2..: Similiar redundant info in names. Isn't that important when compressed but still unclean in my opinion. Technical: - Out of scope probably: Are the sensor nodes use standard XMPP C2S connections over TCP/IP + TLS?

I was quite uneasy about building a new layer of identity over the top of XMPP, personally.

you mean their authentication part?

Yeah.

I need to read it more thorougly and post on-list, I have only been able to skim it

I found it very very hard going.

Yes

The question is whether it needs to be

But in any case - Tobias: Was that an opinion expressed, or going to be on list?

I suspect not

MattJ: Yes, lots seems like it should be simplifiable.

Or more XMPPish.

Kev, i'll probably reply on list when i've read it completely...seems more sensible at least

OK.

3) Date of next meeting?

permission to speak?

hi Peter Waher

Yeah, go for it.

the work is very ongoing and we would

like to have thorough discussions on the lists

peters had alot of experiens in the sensor field

so the provisioning "third party"

that's good...because we probably have not so much :)

is needed when using sensors from different suppliers and defineing who should

descide ion the access

simplification is most welcome

OK, thanks.

I'll read it with that in mind when I read it, then :)

(y)

I think there's lots of work that would benefit on the list (ideally in chunks small enough that they can be processed without setting aside hours at a time, as has happened before with big specs).

throw questions any time

It's where the XMPP experts live :)

Ta.

So, I think we're on to 3) Next date?

SBTSBC?

wfm

wfm

4) AOB?

none here

MattJ: ?

I'll take that as a no :)

Right, so I think we're done.

Thanks all

gadammit

ok, I'll review the notes, and respond accordingly

No AOB

Ta.

(sorry that I have been in a Cisco meeting this morning)

people are expecting me to do internal work these days... ;-)

stpeter, we need the apology from Cisco :)

and a signed letter from your mom

heh

2) no objections

3) I am on holiday next week, so will not be able to make it

4) irrelevant at this point

Would you like us to delay (3)?

I can respond on the list, if anything comes up next week

so, no, you don't need to delay on my part

I'll review the log when I'm done here in ~15 minutes (I hope)

(I note that with the DST change, SBTSBC is different in UTC)

And that's super-efficient Council minutes out.

i'll update the entry in the calendar

Ta.

Kev: noted, you are a model for us all ;-)

bbiaf