XMPP Council - 2011-03-16


  1. Kev has left

  2. Kev has joined

  3. Kev

    !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

  4. Kanchil+

    Kev: Done.

  5. Kev

    !agendaup -6

  6. Kanchil+

    Kev: 0) Fini.

  7. Kev

    !agendaup

  8. Kanchil+

    Kev: 1) Roll call

  9. Kev

    !agendaup -1

  10. Kanchil+

    Kev: 0) Fini.

  11. Tobias has joined

  12. Tobias has left

  13. Tobias has joined

  14. dwd

    !agenda

  15. dwd

    Oh. It's not here.

  16. dwd gives up and reads the scrollback instead.

  17. Kev

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

  18. Kev

    !agenda

  19. Kanchil+

    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

  20. dwd

    Interesting. I don't see it...

  21. Kev

    Are you looking at the moderators?

  22. dwd

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

  23. dwd

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

  24. Kev

    Could be.

  25. Tobias has left

  26. Tobias has joined

  27. Tobias has left

  28. Tobias has joined

  29. Tobias has left

  30. Tobias has joined

  31. Tobias has joined

  32. Tobias has joined

  33. stpeter has joined

  34. bear has joined

  35. stpeter

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

  36. Kev

    Sounds right for the UK.

  37. stpeter

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

  38. Kev

    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 :)

  39. stpeter

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

  40. stpeter

    ah, the glamour of international travel

  41. stpeter crawls back under his rock to concentrate on document reviews for tomorrow's IESG telechat

  42. Kev

    Enjoy :)

  43. stpeter

    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/

  44. stpeter set the topic to

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

  45. linuxwolf has joined

  46. Kev

    One hour.

  47. Tobias has left

  48. Kev

    For those wondering about timezones :)

  49. linuxwolf

    (-:

  50. Tobias has joined

  51. Fritzy has joined

  52. ralphm has joined

  53. stpeter

    hi Ralph and Fritzy!

  54. Fritzy

    howdy

  55. Kev

    Right, enough time to graba sammich :)

  56. linuxwolf

    !agenda

  57. linuxwolf

    Kanchil+ is so capricious

  58. stpeter

    maybe Kanchil ain't feeling so plus today

  59. Kev

    !agenda

  60. Kanchil+

    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

  61. Kev

    Seems good to me :)

  62. stpeter

    :P

  63. Kev

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

  64. Kev

    Anyway, it is time.

  65. Astro has joined

  66. Kev

    Fritzy, linuxwolf, ralphm: PIING :)

  67. Kev

    !agendaup

  68. Kanchil+

    Kev: 1) Roll call

  69. Kev

    I'm here

  70. linuxwolf

    pong

  71. Kev

    MattJ sent apologies.

  72. ralphm

    woot

  73. Kev

    Fritzy: you there?

  74. Fritzy

    yeah

  75. Kev

    Jolly good.

  76. Kev

    !agendaup

  77. Kanchil+

    Kev: 2) Agenda bashing

  78. Fritzy

    I like what we have today

  79. Kev

    No-one, then?

  80. Kev

    Jolly good :)

  81. linuxwolf

    I'd like to talk about..

  82. linuxwolf

    gah…slow down there, Tex

  83. stpeter

    :)

  84. Kev

    :)

  85. linuxwolf

    moving carbons fwd (-:

  86. linuxwolf

    that's it

  87. Kev

    !agendaappend Moving carbons forward.

  88. Kanchil+

    Kev: Done.

  89. Kev

    !agendaup

  90. Kanchil+

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

  91. Kev

    I'm ok with this.

  92. linuxwolf

    +1

  93. Fritzy

    it seems fine to me +1

  94. Kev

    ralphm: ?

  95. ralphm

    I was wondering if sdp is used in combination with jingle

  96. dwd

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

  97. dwd

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

  98. ralphm

    right

  99. Kev

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

  100. linuxwolf

    (-:

  101. stpeter

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

  102. stpeter

    Kev: in meetings, yes

  103. Fritzy

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

  104. linuxwolf

    to the list!

  105. Kev

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

  106. Fritzy

    I mean, it's already there

  107. ralphm

    I'm +1

  108. Kev

    Ta.

  109. Kev

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

  110. Kev

    !agendaup

  111. Kanchil+

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

  112. Kev

    I'm similarly +1 on this.

  113. linuxwolf

    also +1

  114. Fritzy

    yup, along the same lines +1

  115. Kev

    ralphm: ?

  116. dwd

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

  117. dwd

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

  118. stpeter

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

  119. linuxwolf

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

  120. linuxwolf

    gah…beat by the saint

  121. ralphm

    +1

  122. ralphm

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

  123. Kev

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

  124. ralphm

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

  125. ralphm

    is something I found

  126. dwd

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

  127. MattJ has joined

  128. ralphm

    which looks horrible

  129. Fritzy

    haha, there you go

  130. linuxwolf

    maybe the council can volunteer dwd

  131. linuxwolf

    (-:

  132. dwd

    I can delegate to an underling. :-)

  133. ralphm

    minion, is the term

  134. stpeter

    I didn't realize dwd had minions

  135. stpeter

    heh

  136. Kev

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

  137. linuxwolf

    or peon

  138. dwd

    stpeter, Henchmen.

  139. Fritzy

    I have authenticated linuxwolf's identity by his backwards smile

  140. linuxwolf

    (-;

  141. Kev

    Ok, moving on then.

  142. Kev

    !agendaup

  143. Kanchil+

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

  144. linuxwolf

    oof

  145. Fritzy

    so, I have a concern

  146. linuxwolf

    that was a hard hard read

  147. Kev

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

  148. dwd

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

  149. Kev

    Let me find them.

  150. Fritzy

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

  151. MattJ has left

  152. linuxwolf

    agreed

  153. Kev

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

  154. linuxwolf

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

  155. dwd

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

  156. Kev

    The semantics seem to fit.

  157. ralphm

    I never considered solving this problem domain so generically

  158. stpeter

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

  159. Fritzy

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

  160. linuxwolf is surprised stpeter's desk has not collapsed from the weight of printed I-Ds

  161. Kev

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

  162. Kev

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

  163. Kev

    Wondering why it advertises iPhones particularly.

  164. dwd

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

  165. stpeter

    Kev: right, and the timestamp stuff etc.

  166. Fritzy

    dwd: subtle

  167. Kev

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

  168. ralphm

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

  169. dwd

    Fritzy, In a brickesque manner.

  170. Kev

    Fritzy: From the department of redundancy department.

  171. linuxwolf

    it seems like something that could be split up

  172. Kev

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

  173. dwd

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

  174. Kev

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

  175. Fritzy

    there is almost no protocol here

  176. Fritzy

    it is just a payload schema

  177. Fritzy

    with some naming convention advice

  178. stpeter

    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?)

  179. ralphm

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

  180. Kev

    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.

  181. Kev

    IMHO.

  182. Fritzy

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

  183. stpeter

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

  184. linuxwolf

    the few examples I think I see are partial protocol

  185. Kev

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

  186. linuxwolf

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

  187. Kev

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

  188. linuxwolf

    definitely not namespaces

  189. linuxwolf

    s/namespaces/namespaced/

  190. Kev

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

  191. ralphm

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

  192. stpeter

    ralphm: right

  193. ralphm

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

  194. Fritzy

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

  195. ralphm

    and defined mappings, where needed

  196. Kev

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

  197. dwd

    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.

  198. Kev

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

  199. Fritzy

    They should use ad-hoc commands for commands.

  200. linuxwolf

    heh

  201. Kev

    So I'm +/-0

  202. Fritzy

    and Matt earns another $.25

  203. ralphm

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

  204. stpeter

    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)

  205. linuxwolf

    Fritzy: tell hildjj he owes me $0.25

  206. MattJ has joined

  207. Kev

    stpeter: Excellent.

  208. Fritzy

    ralphm: agreed

  209. Fritzy

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

  210. linuxwolf

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

  211. ralphm

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

  212. stpeter

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

  213. Kev

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

  214. linuxwolf

    -0

  215. stpeter

    hey, no +/- voting :P

  216. Kev

    -0 then :p

  217. linuxwolf

    that's the ticket!

  218. Fritzy

    sqrt(-1)

  219. linuxwolf

    Fritzy has to be irrational

  220. Fritzy

    I think this should be redrafted as an informational spec.

  221. Fritzy

    but perhaps...

  222. Kev

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

  223. Fritzy

    thinking... give me a second

  224. ralphm

    -0

  225. Fritzy

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

  226. Fritzy

    I don't think this should go into experimental.

  227. Fritzy

    not in the standards track

  228. Kev

    So that's a veto, then?

  229. linuxwolf

    so that's -1?

  230. Fritzy

    yeah, -1

  231. Kev

    Ok, ta.

  232. stpeter

    units="celcius"?

  233. ralphm

    oh, -1 then

  234. ralphm

    :-D

  235. Fritzy

    units=votes

  236. ralphm

    obviously that should be Kelvin

  237. Kev

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

  238. ralphm

    Kev: yeah

  239. Kev

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

  240. Kev

    !agendaup

  241. Kanchil+

    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

  242. Kev

    +1

  243. linuxwolf

    +1

  244. Fritzy

    Kev, will do

  245. MattJ

    +1 :)

  246. linuxwolf

    whoa

  247. Kev

    He's there!

  248. Kev

    Kinda.

  249. ralphm

    +1

  250. MattJ

    Yeah, kinda

  251. Fritzy

    +1

  252. MattJ

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

  253. Kev

    !agendaup

  254. Kanchil+

    Kev: 7) Moving carbons forward.

  255. Fritzy

    I'm in a castle.

  256. linuxwolf

    heh

  257. linuxwolf

    ok, so

  258. linuxwolf

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

  259. Kev

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

  260. linuxwolf

    Kev: right

  261. Kev

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

  262. linuxwolf

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

  263. Fritzy looks up Modicum.

  264. Kev

    I update Carbons.

  265. Kev

    Or you do :)

  266. Kev

    Then we can advance it :)

  267. MattJ

    Sure

  268. linuxwolf

    I'm happy to update it

  269. linuxwolf

    it == message carbons

  270. ralphm

    so what is that the council needs to do now?

  271. Kev

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

  272. linuxwolf

    cajole Matthew into submitting forwarding (-:

  273. Kev

    With MattJ first.

  274. MattJ

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

  275. MattJ

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

  276. linuxwolf

    /nod

  277. Kev

    MattJ: Oh, changes to this?

  278. linuxwolf

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

  279. MattJ reads Kev's changes to recall

  280. linuxwolf

    s/with as/with it as/

  281. stpeter

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

  282. Kev

    stpeter: Ok, great.

  283. stpeter

    (trying to finish off the file transfer stuff)

  284. linuxwolf

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

  285. linuxwolf

    (finally)

  286. Kev

    Great.

  287. MattJ

    65? I need to update my implementation for that

  288. Kev

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

  289. Kev

    !agendaup

  290. Kanchil+

    Kev: 8) Date of next meeting

  291. Kev

    Next Wednesday 1600 GMT?

  292. MattJ

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

  293. Fritzy

    I'm good with that. +1

  294. MattJ

    +1 for next week

  295. linuxwolf

    sure

  296. Kev

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

  297. stpeter

    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 :)

  298. MattJ

    stpeter, thanks

  299. MattJ

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

  300. MattJ

    Currently Verse only does Jingle+proxy65

  301. Kev

    Ok.

  302. Kev

    !agendaup

  303. Kanchil+

    Kev: 9) Any other business

  304. Kev

    Anything else?

  305. MattJ

    Nay

  306. Fritzy

    0

  307. linuxwolf

    world peace?

  308. Kev

    linuxwolf: Thanks for volunteering.

  309. Fritzy

    whirled peas

  310. linuxwolf

    I'd just nuke'em all

  311. ralphm

    Fritzy: peashake?

  312. stpeter

    calendar updated

  313. Kev

    Ok, then I guess we're done.

  314. linuxwolf

    humus?

  315. Kev

    stpeter: Thanks.

  316. MattJ

    Thanks stpeter

  317. Kev

    I'll do minutes tomorrowish.

  318. Kev

    I think we're done then

  319. Fritzy

    rad

  320. Kev

    Thanks all

  321. Fritzy

    thanks

  322. Kev bangs the gavel

  323. linuxwolf waits fwding

  324. stpeter has had no time to work on an April 1 spec, maybe next year...

  325. Kev

    !agendaup -10

  326. Kanchil+

    Kev: -1) Fini.

  327. MattJ

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

  328. linuxwolf

    adios all

  329. Kev

    MattJ: Ok, thanks.

  330. linuxwolf has left

  331. Fritzy has left

  332. stpeter likes Kev's 30-minute meeting philosophy

  333. MattJ

    :)

  334. Kev has left

  335. stpeter

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

  336. stpeter

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

  337. dwd

    How long has your 48 hours been so far?

  338. stpeter

    about 47 so far

  339. stpeter

    er

  340. stpeter

    no

  341. stpeter

    23

  342. stpeter

    I try to be quick

  343. ralphm has left

  344. Kev has left

  345. Kev has joined

  346. bear has left

  347. Tobias has left

  348. Astro has left

  349. Tobias has joined

  350. Florob has joined

  351. Florob has left

  352. MattJ has left

  353. bear has joined

  354. Tobias has left