XMPP Council - 2011-03-16


  1. 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

  2. Kanchil+

    Kev: Done.

  3. Kev

    !agendaup -6

  4. Kanchil+

    Kev: 0) Fini.

  5. Kev

    !agendaup

  6. Kanchil+

    Kev: 1) Roll call

  7. Kev

    !agendaup -1

  8. Kanchil+

    Kev: 0) Fini.

  9. dwd

    !agenda

  10. dwd

    Oh. It's not here.

  11. dwd gives up and reads the scrollback instead.

  12. Kev

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

  13. Kev

    !agenda

  14. 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

  15. dwd

    Interesting. I don't see it...

  16. Kev

    Are you looking at the moderators?

  17. dwd

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

  18. dwd

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

  19. Kev

    Could be.

  20. stpeter

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

  21. Kev

    Sounds right for the UK.

  22. stpeter

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

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

  24. stpeter

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

  25. stpeter

    ah, the glamour of international travel

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

  27. Kev

    Enjoy :)

  28. 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/

  29. stpeter set the topic to

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

  30. Kev

    One hour.

  31. Kev

    For those wondering about timezones :)

  32. linuxwolf

    (-:

  33. stpeter

    hi Ralph and Fritzy!

  34. Fritzy

    howdy

  35. Kev

    Right, enough time to graba sammich :)

  36. linuxwolf

    !agenda

  37. linuxwolf

    Kanchil+ is so capricious

  38. stpeter

    maybe Kanchil ain't feeling so plus today

  39. Kev

    !agenda

  40. 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

  41. Kev

    Seems good to me :)

  42. stpeter

    :P

  43. Kev

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

  44. Kev

    Anyway, it is time.

  45. Kev

    Fritzy, linuxwolf, ralphm: PIING :)

  46. Kev

    !agendaup

  47. Kanchil+

    Kev: 1) Roll call

  48. Kev

    I'm here

  49. linuxwolf

    pong

  50. Kev

    MattJ sent apologies.

  51. ralphm

    woot

  52. Kev

    Fritzy: you there?

  53. Fritzy

    yeah

  54. Kev

    Jolly good.

  55. Kev

    !agendaup

  56. Kanchil+

    Kev: 2) Agenda bashing

  57. Fritzy

    I like what we have today

  58. Kev

    No-one, then?

  59. Kev

    Jolly good :)

  60. linuxwolf

    I'd like to talk about..

  61. linuxwolf

    gah…slow down there, Tex

  62. stpeter

    :)

  63. Kev

    :)

  64. linuxwolf

    moving carbons fwd (-:

  65. linuxwolf

    that's it

  66. Kev

    !agendaappend Moving carbons forward.

  67. Kanchil+

    Kev: Done.

  68. Kev

    !agendaup

  69. Kanchil+

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

  70. Kev

    I'm ok with this.

  71. linuxwolf

    +1

  72. Fritzy

    it seems fine to me +1

  73. Kev

    ralphm: ?

  74. ralphm

    I was wondering if sdp is used in combination with jingle

  75. dwd

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

  76. dwd

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

  77. ralphm

    right

  78. Kev

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

  79. linuxwolf

    (-:

  80. stpeter

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

  81. stpeter

    Kev: in meetings, yes

  82. Fritzy

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

  83. linuxwolf

    to the list!

  84. Kev

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

  85. Fritzy

    I mean, it's already there

  86. ralphm

    I'm +1

  87. Kev

    Ta.

  88. Kev

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

  89. Kev

    !agendaup

  90. Kanchil+

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

  91. Kev

    I'm similarly +1 on this.

  92. linuxwolf

    also +1

  93. Fritzy

    yup, along the same lines +1

  94. Kev

    ralphm: ?

  95. dwd

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

  96. dwd

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

  97. stpeter

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

  98. linuxwolf

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

  99. linuxwolf

    gah…beat by the saint

  100. ralphm

    +1

  101. ralphm

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

  102. Kev

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

  103. ralphm

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

  104. ralphm

    is something I found

  105. dwd

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

  106. ralphm

    which looks horrible

  107. Fritzy

    haha, there you go

  108. linuxwolf

    maybe the council can volunteer dwd

  109. linuxwolf

    (-:

  110. dwd

    I can delegate to an underling. :-)

  111. ralphm

    minion, is the term

  112. stpeter

    I didn't realize dwd had minions

  113. stpeter

    heh

  114. Kev

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

  115. linuxwolf

    or peon

  116. dwd

    stpeter, Henchmen.

  117. Fritzy

    I have authenticated linuxwolf's identity by his backwards smile

  118. linuxwolf

    (-;

  119. Kev

    Ok, moving on then.

  120. Kev

    !agendaup

  121. Kanchil+

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

  122. linuxwolf

    oof

  123. Fritzy

    so, I have a concern

  124. linuxwolf

    that was a hard hard read

  125. Kev

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

  126. dwd

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

  127. Kev

    Let me find them.

  128. Fritzy

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

  129. linuxwolf

    agreed

  130. Kev

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

  131. linuxwolf

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

  132. dwd

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

  133. Kev

    The semantics seem to fit.

  134. ralphm

    I never considered solving this problem domain so generically

  135. stpeter

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

  136. Fritzy

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

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

  138. Kev

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

  139. Kev

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

  140. Kev

    Wondering why it advertises iPhones particularly.

  141. dwd

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

  142. stpeter

    Kev: right, and the timestamp stuff etc.

  143. Fritzy

    dwd: subtle

  144. Kev

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

  145. ralphm

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

  146. dwd

    Fritzy, In a brickesque manner.

  147. Kev

    Fritzy: From the department of redundancy department.

  148. linuxwolf

    it seems like something that could be split up

  149. Kev

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

  150. dwd

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

  151. Kev

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

  152. Fritzy

    there is almost no protocol here

  153. Fritzy

    it is just a payload schema

  154. Fritzy

    with some naming convention advice

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

  156. ralphm

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

  157. 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.

  158. Kev

    IMHO.

  159. Fritzy

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

  160. stpeter

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

  161. linuxwolf

    the few examples I think I see are partial protocol

  162. Kev

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

  163. linuxwolf

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

  164. Kev

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

  165. linuxwolf

    definitely not namespaces

  166. linuxwolf

    s/namespaces/namespaced/

  167. Kev

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

  168. ralphm

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

  169. stpeter

    ralphm: right

  170. ralphm

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

  171. Fritzy

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

  172. ralphm

    and defined mappings, where needed

  173. Kev

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

  174. 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.

  175. Kev

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

  176. Fritzy

    They should use ad-hoc commands for commands.

  177. linuxwolf

    heh

  178. Kev

    So I'm +/-0

  179. Fritzy

    and Matt earns another $.25

  180. ralphm

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

  181. 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)

  182. linuxwolf

    Fritzy: tell hildjj he owes me $0.25

  183. Kev

    stpeter: Excellent.

  184. Fritzy

    ralphm: agreed

  185. Fritzy

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

  186. linuxwolf

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

  187. ralphm

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

  188. stpeter

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

  189. Kev

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

  190. linuxwolf

    -0

  191. stpeter

    hey, no +/- voting :P

  192. Kev

    -0 then :p

  193. linuxwolf

    that's the ticket!

  194. Fritzy

    sqrt(-1)

  195. linuxwolf

    Fritzy has to be irrational

  196. Fritzy

    I think this should be redrafted as an informational spec.

  197. Fritzy

    but perhaps...

  198. Kev

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

  199. Fritzy

    thinking... give me a second

  200. ralphm

    -0

  201. Fritzy

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

  202. Fritzy

    I don't think this should go into experimental.

  203. Fritzy

    not in the standards track

  204. Kev

    So that's a veto, then?

  205. linuxwolf

    so that's -1?

  206. Fritzy

    yeah, -1

  207. Kev

    Ok, ta.

  208. stpeter

    units="celcius"?

  209. ralphm

    oh, -1 then

  210. ralphm

    :-D

  211. Fritzy

    units=votes

  212. ralphm

    obviously that should be Kelvin

  213. Kev

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

  214. ralphm

    Kev: yeah

  215. Kev

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

  216. Kev

    !agendaup

  217. 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

  218. Kev

    +1

  219. linuxwolf

    +1

  220. Fritzy

    Kev, will do

  221. MattJ

    +1 :)

  222. linuxwolf

    whoa

  223. Kev

    He's there!

  224. Kev

    Kinda.

  225. ralphm

    +1

  226. MattJ

    Yeah, kinda

  227. Fritzy

    +1

  228. MattJ

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

  229. Kev

    !agendaup

  230. Kanchil+

    Kev: 7) Moving carbons forward.

  231. Fritzy

    I'm in a castle.

  232. linuxwolf

    heh

  233. linuxwolf

    ok, so

  234. linuxwolf

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

  235. Kev

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

  236. linuxwolf

    Kev: right

  237. Kev

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

  238. linuxwolf

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

  239. Fritzy looks up Modicum.

  240. Kev

    I update Carbons.

  241. Kev

    Or you do :)

  242. Kev

    Then we can advance it :)

  243. MattJ

    Sure

  244. linuxwolf

    I'm happy to update it

  245. linuxwolf

    it == message carbons

  246. ralphm

    so what is that the council needs to do now?

  247. Kev

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

  248. linuxwolf

    cajole Matthew into submitting forwarding (-:

  249. Kev

    With MattJ first.

  250. MattJ

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

  251. MattJ

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

  252. linuxwolf

    /nod

  253. Kev

    MattJ: Oh, changes to this?

  254. linuxwolf

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

  255. MattJ reads Kev's changes to recall

  256. linuxwolf

    s/with as/with it as/

  257. 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

  258. Kev

    stpeter: Ok, great.

  259. stpeter

    (trying to finish off the file transfer stuff)

  260. linuxwolf

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

  261. linuxwolf

    (finally)

  262. Kev

    Great.

  263. MattJ

    65? I need to update my implementation for that

  264. Kev

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

  265. Kev

    !agendaup

  266. Kanchil+

    Kev: 8) Date of next meeting

  267. Kev

    Next Wednesday 1600 GMT?

  268. MattJ

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

  269. Fritzy

    I'm good with that. +1

  270. MattJ

    +1 for next week

  271. linuxwolf

    sure

  272. Kev

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

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

  274. MattJ

    stpeter, thanks

  275. MattJ

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

  276. MattJ

    Currently Verse only does Jingle+proxy65

  277. Kev

    Ok.

  278. Kev

    !agendaup

  279. Kanchil+

    Kev: 9) Any other business

  280. Kev

    Anything else?

  281. MattJ

    Nay

  282. Fritzy

    0

  283. linuxwolf

    world peace?

  284. Kev

    linuxwolf: Thanks for volunteering.

  285. Fritzy

    whirled peas

  286. linuxwolf

    I'd just nuke'em all

  287. ralphm

    Fritzy: peashake?

  288. stpeter

    calendar updated

  289. Kev

    Ok, then I guess we're done.

  290. linuxwolf

    humus?

  291. Kev

    stpeter: Thanks.

  292. MattJ

    Thanks stpeter

  293. Kev

    I'll do minutes tomorrowish.

  294. Kev

    I think we're done then

  295. Fritzy

    rad

  296. Kev

    Thanks all

  297. Fritzy

    thanks

  298. Kev bangs the gavel

  299. linuxwolf waits fwding

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

  301. Kev

    !agendaup -10

  302. Kanchil+

    Kev: -1) Fini.

  303. MattJ

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

  304. linuxwolf

    adios all

  305. Kev

    MattJ: Ok, thanks.

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

  307. MattJ

    :)

  308. stpeter

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

  309. stpeter

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

  310. dwd

    How long has your 48 hours been so far?

  311. stpeter

    about 47 so far

  312. stpeter

    er

  313. stpeter

    no

  314. stpeter

    23

  315. stpeter

    I try to be quick