XMPP Council - 2012-02-15

  1. Kev

    I'm having a somewhat distracted day. I'm not intending going anywhere, but in case I fail to notice the time later, could someone please send me a message when the time comes.

  2. Tobias


  3. Kev


  4. linuxwolf goes looking for his graphite-powered legacy input device

  5. Kev


  6. stpeter dents and tweets

  7. linuxwolf

    this is going to bug me all day

  8. Kev

    On a yoghurt I'm about to eat (although it's a "0% fat" one, which seems to mean "tastes icky"): "suitable for vegetarians".

  9. Kev

    One assumes this is contrary to the usual bacon yoghurts, which aren't.

  10. linuxwolf

    well, there's vegetarians and there's Vegerians

  11. linuxwolf

    or vegans

  12. linuxwolf

    which wouldn't eat yogurt if any part came from an animal is some form … such as milk

  13. stpeter

    don't forget the fruitarians!

  14. linuxwolf

    vegitarivores and meatarians

  15. Kev

    linuxwolf: It doesn't claim to be suitable for vegans (which, given it's made from milk, would probably be difficult).

  16. linuxwolf

    very true

  17. linuxwolf

    I wonder if they removed all the bacteria … which wouldn't make it yogurt

  18. Kev

    They certainly removed all the nice.

  19. Kev

    I'm sure that when I was (much) younger, fruit yoghurts used to taste of fruit. Sometimes even the one advertised on the packaging.

  20. linuxwolf

    0% fat is almost never a good idea

  21. Kev

    I didn't notice any fruit yoghurts that weren't fun-free :/

  22. linuxwolf

    when we were younger, fruit yogurts actually contained fruit

  23. linuxwolf

    now they have "natural and artificial flavors"

  24. Kev

    I *like* cherries.

  25. Kev

    I'm sure I do.

  26. Kev

    They taste fruity and nice.

  27. linuxwolf

    you're best bet is to get plain yogurt, add fruit, and blend

  28. stpeter prefers plain, high-fat yoghurt

  29. linuxwolf

    maybe some honey too

  30. stpeter

    and how did we get on this topic? ;-)

  31. Kev

    Also: Bacon.

  32. Kev

    stpeter: I'm whining about eating a fun-free yoghurt.

  33. linuxwolf

    now I'm hugry

  34. guusdk

    hungry within a minute joining the xmpp council muc.

  35. linuxwolf

    let's get this over with so I can address that hunger thing

  36. Kev

    Yeah, I was until I tasted this yoghurt, too!

  37. linuxwolf

    I think I'll have a ham-and-cheese panini

  38. stpeter

    have we pinged Ralph and Matthew?

  39. Kev

    I have (just)

  40. linuxwolf

    just pinged Ralph

  41. linuxwolf


  42. stpeter

    oh shoot, gotta join the IETF Tools Team call

  43. Tobias

    pinged matt

  44. Kev


  45. Kev

    1) Roll call

  46. Kev

    I'm here!

  47. ralphm


  48. linuxwolf


  49. MattJ


  50. Tobias


  51. Kev


  52. Kev

    2) Spec length

  53. Kev

    What to do about -45 and -60?

  54. MattJ

    Too long.

  55. Kev

    XEP-0312: TL;DR

  56. linuxwolf

    I doubt anyone will argue too short

  57. MattJ

    Well there are obviously only two things we can do: split or remove

  58. ralphm


  59. Kev

    Right, so, I don't argue with splitting MUC into essentially two - Administration and Usage or something.

  60. MattJ

    Makes sense

  61. Kev

    Although I'm not sure what it buys us, really, other than two shorter specs.

  62. Kev

    We want servers to implement all of it, regardless.

  63. Kev

    I suppose clients could just implement the non-admin bits (as Swift did for a while).

  64. linuxwolf

    I think we'd end up with some duplication, with regards to join/create

  65. MattJ

    Well splitting MUC makes less sense for others, I think

  66. MattJ

    *less sense than for others

  67. ralphm

    I haven't really considered splitting MUC

  68. MattJ

    OTOH I have a growing list of things I'd like to see removed from XEP-0060

  69. ralphm

    For XEP-0060 there are a lot of optional features

  70. ralphm

    that could be moved to their own spec

  71. linuxwolf

    yeah, XEP-0060 could benefit from breakup

  72. linuxwolf

    not sure about MUC right now

  73. Kev

    Ok, so is it fair to say that rough consensus is that -45 should be left alone, wrt. splitting it?

  74. MattJ

    I'm convinced there are a whole bunch of features in XEP-0060 that *nobody* is using

  75. ralphm

    there you have some very basic use cases that you can build upon

  76. Kev

    Splitting -60 seems fine to me, although I don't know it in enough depth to suggest where.

  77. MattJ

    I think MUC isn't too bad

  78. stpeter

    for MUC, I do think we could fairly easily split the dumb-client parts from the moderator/admin/owner use cases -- and *most* clients don't support any of the latter

  79. MattJ

    We just need to be sure not to add to it

  80. Tobias

    do you think the duplication would be much when splitting basic chat features and complex admin stuff for MUC?

  81. MattJ

    I wouldn't be opposed to an admin/user split of the spec

  82. Kev

    Tobias: Well, you've got room creation, kicking and things.

  83. linuxwolf

    stpeter: probably, although some discussion in the "dumb-client" spec would need to talk about create in some referential manner

  84. stpeter

    linuxwolf: for sure

  85. Kev

    So a dumb client may not be able to kick, but should still know what being kicked looks like.

  86. stpeter


  87. linuxwolf


  88. Tobias

    Kev, but these would only be added by the admin spec, wouldn't they...basic clients would still understand normal errors and such

  89. ralphm

    sure, you need to discuss roles etc in the core spec

  90. stpeter

    ralphm: true

  91. Kev

    So, my rough stance on this is that I'm not opposed to a sensible split for -45 into dumb client and admin, but that I think getting such a split would be hard work that I'm not looking forward to having to review, and very much want to not have to do.

  92. MattJ

    In fact the main advantage I see of splitting 45 as it stands is that we can experiment with e.g. defining other protocols for admin of a room/service

  93. stpeter

    so I think it might be useful to take a look at 45 and see what it would look like with the moderator/admin/owner stuff moved to a separate spec

  94. ralphm


  95. linuxwolf


  96. stpeter

    MattJ: yes, ad-hoc commands in MUC is on my list :)

  97. MattJ

    Mine too

  98. MattJ

    Below MAM :)

  99. stpeter


  100. linuxwolf changes 0.25USD to hildjj

  101. stpeter

    my workflow is slowing down with the impending end of my IESG term, so I'll have more time soon

  102. Kev

    Ok, so, pubsub everyone's happy with being split.

  103. linuxwolf


  104. linuxwolf

    Kev: definitely

  105. Kev

    I don't think we need to discuss this further then, do we?

  106. linuxwolf

    not presently

  107. stpeter

    Kev: I can take a quick/rough pass at 45

  108. Kev

    I'll take -45 changes as they come, but I have assorted reservations that I'm happy to have removed by seeing something that works.

  109. stpeter

    Kev: I think it would be worth discussing 60

  110. stpeter

    clearly there's a lot in 60

  111. Kev

    stpeter: Now, or when we have some sort of split pencilled up so we can discuss it?

  112. stpeter

    well, have people looked at 60 and thought about how we might split it up?

  113. stpeter

    same kind of thing?

  114. linuxwolf

    how about we start with everyone's list of "please remove"

  115. ralphm

    a bit

  116. ralphm

    most of the configuration bits could be moved out

  117. MattJ

    I'm still in the process of XEP-0060 review

  118. stpeter

    i.e., admin/owner/etc. vs mere publish and subscribe?

  119. linuxwolf

    I've thought about it, but haven't gone into much detail

  120. Kev

    I haven't, I think everyone else here has a better grasp of pubsub than I do.

  121. ralphm

    for nodes, subscriptions and pre-conditions

  122. stpeter

    I think that pub and sub are pretty simple, really

  123. MattJ

    so I'll probably have a better list when I submit my feedback to the list

  124. ralphm

    stpeter: yeah

  125. stpeter


  126. stpeter

    so it sounds like we can circle back on this topic in a few weeks

  127. linuxwolf


  128. stpeter

    and perhaps start a thread on the pubsub@ list?

  129. linuxwolf


  130. stpeter

    I can start a thread on muc@ when I take a rough pass at the split

  131. Kev

    3) Last call on XEP-0267

  132. MattJ

    even for subscriptions... I think things like "multiple subscriptions" should be (re)moved (or at least fixed)

  133. ralphm

    I'd very much like to see XEP-0060 be a very stripped down spec that explains the core use case, with references to other specs for enhanced behaviour

  134. MattJ


  135. Tobias


  136. ralphm

    I'll have a pass at XEP-0060 and make a list

  137. stpeter

    ralphm: super

  138. Kev

    Do we have implementations of 267 deployed/used now?

  139. linuxwolf


  140. linuxwolf

    grazie even

  141. linuxwolf


  142. linuxwolf

    Kev: I don't know

  143. stpeter

    Kev: there's an implementation in Prosody (experimental) but I've not yet had time to deploy it at xmpp.net

  144. stpeter

    I'd be happy to wait

  145. Kev

    I'm not opposed to Last Calling it I guess, but I'm unlikely to want to push it to Draft.

  146. MattJ

    and I haven't looked at it or tested it yet

  147. stpeter


  148. ralphm

    two would be nice

  149. stpeter

    how about I test it out at xmpp.net first

  150. MattJ


  151. linuxwolf


  152. Tobias

    sounds like a plan

  153. stpeter notes that we might need to think about this non-requirement requirement for multiple implementations and deployment experience before pushing something to Draft

  154. Kev

    Ok. I may even have comments about it, I think.

  155. ralphm

    stpeter: I think multiple implementations is still a great thing to have

  156. Kev

    I treat Experimental as "Not obivously broken" and Draft as "The way we have consensus on solving this", mostly (and Final as "done deal").

  157. stpeter

    ralphm: always, the question is: is that a requirement for advancement? XEP-0001 doesn't say that

  158. Kev

    I think the current state of 267 is that we don't know that this is the right way to do this as we've not tried it.

  159. stpeter

    but that's a topic for a future meeting

  160. stpeter

    Kev: probably

  161. Kev

    Or, to phrase it slightly better, it can't stop being Experimental until there's been an experiment.

  162. linuxwolf

    thought experiments can go far, but maybe not far enough

  163. ralphm

    right, so the non-requirement kinda makes it easier to assert if it is the right way to do a thing

  164. stpeter


  165. stpeter

    I think we have a path for 267

  166. Kev

    We've explicitly made the bar to Experimental very low in recentish meetings.

  167. stpeter

    more experimentation on the way :)

  168. linuxwolf

    the bar as been lower (-:

  169. MattJ

    Kev, *ahem* :)

  170. ralphm

    Kev: I've never lowered the bar, I don't think it should be very high at all

  171. ralphm

    but draft should be

  172. linuxwolf

    I'm with ralphm

  173. Kev

    Right, that's what I said, isn't it?

  174. Kev

    We've discussed this recently and agreed that the bar to Experimental should be very low.

  175. ralphm


  176. Kev

    It doesn't imply that Draft should be that low.

  177. linuxwolf

    yes, but some of us started very low, and others needed to move (-:

  178. ralphm

    so I am again arguing for actual implementations (plural) to move forward

  179. linuxwolf

    anyway, we're in general agreement, so let's move on (-:

  180. Kev

    I don't need multiple implementations to persuade me it's Draft ready - but it's the easiest way to persuade me.

  181. Kev

    linuxwolf: right.

  182. Kev

    4) Last call on XEP-0297

  183. MattJ


  184. linuxwolf

    are there multiple implementations?

  185. stpeter

    (BTW, a quick visual comparison of http://xmpp.org/extensions/xep-0045.html#moderator and http://xmpp.org/extensions/xep-0045.html#statuscodes indicates that we'd cut about 40% of XEP-0045 by moving the moderator/admin/owner use cases)

  186. Tobias

    i don't know of a single implementation

  187. Kev

    linuxwolf: I think there are, actually, aren't there?

  188. stpeter

    (but I'll post to muc@ about that....)

  189. linuxwolf

    MattJ has one for Prosody

  190. linuxwolf


  191. MattJ

    and a client one in Verse

  192. Tobias


  193. Kev

    As the BC guys are using MAM, which uses it.

  194. MattJ

    Zash wrote both

  195. linuxwolf


  196. Tobias


  197. MattJ

    and yes, BuddyCloud

  198. linuxwolf

    ok then

  199. linuxwolf

    +1 for last call

  200. stpeter notes that we'll need 297 for Carbons

  201. Kev


  202. linuxwolf

    I'll make my comments during LC

  203. Kev

    I'm ok with Last Calling this.

  204. stpeter

    that's why I'm interested in seeing this done

  205. linuxwolf

    which are related to Carbons

  206. ralphm


  207. Tobias

    i gave it a read earlier and it made sense and sounds logical...so +1 for this

  208. ralphm

    was wat it reminds me off, and XEP-0033's claim that it supersedes that

  209. MattJ gives ralphm bonus points for citing archive.jabber.org

  210. ralphm


  211. ralphm

    I've been around for a bit I suppose

  212. linuxwolf


  213. linuxwolf

    I think I actually tried to implement that, too

  214. Kev

    I think we need -297 LC votes from Ralph and Tobias?

  215. ralphm

    I think, contrairy to its claim, that jabber:x:envelope might actually have implementation

  216. ralphm

    that said, I'm +1 on LC

  217. Tobias

    i'Ve only implemented / used XEP-0033 some years ago

  218. Tobias

    Kev, see 16:22

  219. Tobias


  220. ralphm

    this spec is richer and more well defined

  221. Kev

    Tobias: Ta.

  222. Kev

    Ok, moving ever onwarsd.

  223. ralphm

    especially the security considerations

  224. Kev

    Also, onwards.

  225. Kev

    5) http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1399

  226. linuxwolf

    ralphm: envelope was only meant to be the addressing bits, −297 really does wrap another (message) stanza

  227. Kev

    Is that line redundant?

  228. Kev

    It looks it to me.

  229. ralphm

    linuxwolf: yeah, I suppose. It's just juggling elements :-)

  230. Tobias

    Kev, where is the same already said? or is the behavior described common sense?

  231. ralphm

    linuxwolf: one might argue that embedding a message in another element makes backwards compatibility harder

  232. Kev

    Tobias: There was a thread about this on the mailing list.

  233. MattJ

    I missed the thread

  234. Kev

    I wonder if I can find it.

  235. Kev

    But the summary was that the error it refers to doesn't exist.

  236. linuxwolf

    ralphm: that's what explicit namespace declarations are for (-:

  237. MattJ

    so am lacking any context or opinion (it seems sensible)

  238. linuxwolf

    I don't recall that jingle thread

  239. stpeter

    MattJ: we discussed this on the jingle@ list

  240. ralphm

    linuxwolf: as an aside, Blain Cook asserted the same thing about Atom payloads and pubsub events.

  241. Kev

    Nor is there anything in 166 that talks about encrypted streams to use this on.

  242. stpeter

    and on standards@

  243. linuxwolf checks his subscriptions

  244. stpeter


  245. ralphm

    linuxwolf: in that he'd like it better if the payload was outside the pubsub element

  246. stpeter


  247. stpeter


  248. stpeter

    that's the start of the thread

  249. stpeter

    so I only forwarded my conclusions to the jingle@ list

  250. Kev

    That's the one, thanks Peter.

  251. stpeter

    anyway, no hurry

  252. stpeter

    we can discuss next week

  253. stpeter

    or on the list

  254. linuxwolf


  255. linuxwolf

    I need to rebuild my context

  256. Kev


  257. Kev

    6) Date of next meeting.

  258. linuxwolf

    it was sent on my b-day … I ignored a lot of email that day (-:

  259. Kev


  260. linuxwolf


  261. MattJ


  262. stpeter


  263. Tobias

    looks up what it means

  264. stpeter


  265. linuxwolf

    Same Bat Time Same Bat Channel

  266. stpeter

    I assume it's same bat time, same bat channel

  267. Kev

    Tobias: I don't *think* it's an established acronym, just one I use.

  268. Kev

    linuxwolf: Right.

  269. ralphm

    I should be

  270. ralphm


  271. linuxwolf

    Kev likes to channel Adam West

  272. Tobias


  273. Tobias

    +1 then

  274. Kev

    Tobias: We went through a period where I'd say "same bat time same bat channel" for this agenda item. So I started abbreviating.

  275. Kev

    7) AOB?

  276. linuxwolf

    s/Adam West/William Dozier/

  277. linuxwolf

    no AOB from me

  278. MattJ


  279. Kev

    Nor anyone else, it seems.

  280. Kev

    Ok then.

  281. ralphm


  282. Kev

    Thanks all :)

  283. MattJ


  284. Kev gavels the hammer. Or something.

  285. linuxwolf goes back to lamenting the loss of his pencil

  286. linuxwolf

    now I don't know what to do when I'm pondering

  287. Kev

    I have some almost-yoghurt you could eat!

  288. stpeter


  289. linuxwolf

    I think I might have a fancy wood pencil

  290. linuxwolf


  291. linuxwolf

    found my pencil bag

  292. stpeter

    linuxwolf: now that I'm using PGP more often, you and I might want to do a keysigning sometime ;-)

  293. linuxwolf

    that would require me to use PGP d-:

  294. stpeter

    linuxwolf: you usually sign your @cisco mail, don't you?

  295. linuxwolf

    I do

  296. linuxwolf


  297. stpeter


  298. stpeter sees his inbox bump up over 30 messages and starts to scrub it

  299. linuxwolf


  300. Astro

    did I read channels? buddycloud channels?

  301. ralphm

    Astro: bat channels

  302. stpeter


  303. linuxwolf looks at using PGP

  304. linuxwolf

    I can get my PGP key printed on my business cards, but not my cert

  305. stpeter

    linuxwolf: I go back and forth between PGP, S/MIME, and nothing

  306. stpeter

    linuxwolf: however, in my experience very very few people us S/MIME, whereas PGP is mildly useful for sending messages encrypted

  307. stpeter

    I even use openpgp for IM messages at times (at least with migri, who helps out with xmpp.org list administration)

  308. stpeter tests out the beta version of the IETF datatracker