Tobiasgot till 3.12 but could tell you my comments so far
KevGo for it.
KevI'm at the not-blocking-but-bits-of-it-are-a-bit-weird stage.
- images in-line as SVG or Base64ed PNG
- glossary could use definition list syntax instead of table
- 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.
- Out of scope probably: Are the sensor nodes use standard XMPP C2S connections over TCP/IP + TLS?
KevI was quite uneasy about building a new layer of identity over the top of XMPP, personally.
Tobiasyou mean their authentication part?
MattJI need to read it more thorougly and post on-list, I have only been able to skim it
KevI found it very very hard going.
MattJThe question is whether it needs to be
KevBut in any case - Tobias: Was that an opinion expressed, or going to be on list?
MattJI suspect not
KevMattJ: Yes, lots seems like it should be simplifiable.
KevOr more XMPPish.
TobiasKev, i'll probably reply on list when i've read it completely...seems more sensible at least
Kev3) Date of next meeting?
Peter Waherhas joined
jabberjockepermission to speak?
Tobiashi Peter Waher
KevYeah, go for it.
jabberjockethe work is very ongoing and we would
jabberjockelike to have thorough discussions on the lists
jabberjockepeters had alot of experiens in the sensor field
jabberjockeso the provisioning "third party"
Tobiasthat's good...because we probably have not so much :)
jabberjockeis needed when using sensors from different suppliers and defineing who should
jabberjockedescide ion the access
jabberjockesimplification is most welcome
MattJI'll read it with that in mind when I read it, then :)
KevI 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).
jabberjockethrow questions any time
KevIt's where the XMPP experts live :)
KevSo, I think we're on to
3) Next date?
KevI'll take that as a no :)
KevRight, so I think we're done.
Kevbangs the gavel.
m&mok, I'll review the notes, and respond accordingly
stpeter(sorry that I have been in a Cisco meeting this morning)
stpeterpeople are expecting me to do internal work these days... ;-)
MattJstpeter, we need the apology from Cisco :)
Tobiasand a signed letter from your mom
m&m2) no objections
m&m3) I am on holiday next week, so will not be able to make it
m&m4) irrelevant at this point
KevWould you like us to delay (3)?
m&mI can respond on the list, if anything comes up next week
m&mso, no, you don't need to delay on my part
stpeterI'll review the log when I'm done here in ~15 minutes (I hope)
Kev(I note that with the DST change, SBTSBC is different in UTC)
KevAnd that's super-efficient Council minutes out.