XMPP Council - 2011-07-13

  1. bear has joined

  2. bear has left

  3. mlundblad has joined

  4. Neustradamus has joined

  5. linuxwolf has joined

  6. stpeter has joined

  7. linuxwolf has left

  8. linuxwolf has joined

  9. linuxwolf has left

  10. linuxwolf has joined

  11. linuxwolf has left

  12. linuxwolf has joined

  13. linuxwolf has left

  14. linuxwolf has joined

  15. stpeter

    T-12 minutes?

  16. Kev


  17. linuxwolf goes to renew client cert

  18. stpeter stopped signing his email

  19. linuxwolf

    then who have I been talking to all this time?!?!!!111!!!eleventy11!! (-:

  20. Kev

    I sign my mail either Best, /K or /K

  21. stpeter


  22. Kev

    Does that count?

  23. linuxwolf


  24. Wojtek has joined

  25. ralphm has joined

  26. ralphm


  27. stpeter

    hi Ralph!

  28. Kev

    Hi Ralph.

  29. linuxwolf waves

  30. erik has joined

  31. MattJ has joined

  32. MattJ waves

  33. Kev

    Hi Matt.

  34. MattJ

    This meeting can't go past 11:30, or I have to run :)

  35. Kev

    Damn, it's alread 15:54 now.

  36. stpeter

    Mr. EDT!

  37. MattJ

    Oh well

  38. MattJ

    stpeter, my watch is still in GMT :)

  39. stpeter


  40. MattJ

    But my schedule isn't

  41. linuxwolf


  42. Astro has joined

  43. Kev


  44. Kev

    So, onwards.

  45. Kev

    1) Roll call.

  46. Kev

    I'm free!

  47. linuxwolf


  48. MattJ


  49. ralphm


  50. Kev

    2) Agenda Ba^w^whttp://www.xmpp.org/extensions/inbox/compliance2012.html Accept as XEP?

  51. linuxwolf


  52. MattJ


  53. stpeter

    needs some work, clearly

  54. Kev

    stpeter: Yes, but that can be done in place.

  55. stpeter


  56. stpeter

    right even

  57. ralphm


  58. Kev

    I think the 198 discussion is interesting. I'm actually in favour of that, despite it making neither M-Link nor Swift compliant (neither do Resume).

  59. Kev

    (I'm +1, to be clear)

  60. Kev

    3) http://www.xmpp.org/extensions/inbox/commenting.html Accept as XEP?

  61. ralphm

    Kev: agreed on 198

  62. Kev

    I've asked the BuddyCloud guys to comment on this on list, because it seems like their area of expertise; I have no objection to publication at the moment.

  63. MattJ

    I haven't read it in detail, but it seems sane, I'm +1

  64. linuxwolf

    +1 also

  65. ralphm

    +1 on commenting. Very interesting, although I want to go through it a with a fine comb

  66. stpeter

    (we did have discussion about splitting 198 into two pieces, but Matthew convinced me that acking and resuming belong together)

  67. ralphm

    stpeter: nod

  68. Kev

    I think they do.

  69. MattJ

    stpeter, +1

  70. Kev

    You really want both features.

  71. MattJ

    I started the discussion :)

  72. stpeter


  73. stpeter

    MattJ: faulty memory

  74. Kev

    4) LC on XEP-0296?

  75. Kev

    I think I'll have comments on this on-list, but I'm happy to LC it.

  76. MattJ

    +1 for LC

  77. linuxwolf

    obvious +1 from me (-:

  78. ralphm


  79. Kev

    5) Date of next meeting.

  80. ralphm

    should it also be in compliance?

  81. Kev


  82. MattJ


  83. Astro prepares a comment on the Commenting XEP...

  84. linuxwolf

    ralphm: that's my thought…and why I'd like LC to be sooner rather than later

  85. linuxwolf

    Kev: WFM

  86. Kev

    ralphm: Well, there's a discussion. I think it'd be worth seeing how the LC goes.

  87. Kev

    Astro: Thanks.

  88. ralphm

    Kev: agreed

  89. Kev

    I think that's everyone agreed on date.

  90. Kev

    6) Any other business.

  91. stpeter

    I like "Users leave comments on just about anything" :)

  92. Kev

    I liked the opening sentence.

  93. stpeter

    hmm, AOB

  94. stpeter

    are we closer to done on dialback?

  95. stpeter

    I can incorporate the one fix from fippo and push out a new version

  96. stpeter

    seems like we'd want a second LC

  97. Kev

    It's not clear to me whether fippo is now happy with it (with his fix pushed).

  98. linuxwolf

    stpeter: /nod … unless you want to act unilaterally (-: /ducks

  99. MattJ

    He's happy with little at the moment :)

  100. stpeter

    it's not clear to me if fippo is ever happy ;-)

  101. Neustradamus has left

  102. Kev

    Not that this is necessarily a requirement, but I think knowing is a requirement :)

  103. stpeter

    I have a broader question about dialback, though

  104. stpeter

    if we have a few minutes

  105. MattJ is all ears

  106. Kev

    I don't think we've had the situation before where authors have been is such disagreement.

  107. Kev

    So how to resolve it is a little new to me.

  108. linuxwolf

    there was one time in the distant past...

  109. stpeter

    Kev: new for me, too

  110. ralphm

    happiness is overrated?

  111. ralphm


  112. linuxwolf


  113. stpeter


  114. Kev

    linuxwolf: Oh. A memory stirs. XHTML-IM?

  115. stpeter

    the broader issue is: does this belong in the XMPP WG?

  116. stpeter

    I think it might

  117. stpeter

    because of the DNA/DNSSEC work

  118. Wojtek has left

  119. Kev

    stpeter: I think that's a credible argument, at least.

  120. ralphm

    good point

  121. linuxwolf


  122. ralphm

    kinda funny that we pulled it out of an RFC

  123. stpeter

    so I think it might make sense to fold DNA/DNSSEC in with the dialback spec and the bidi extension

  124. stpeter

    and publish it all as an RFC on XMPP S2S

  125. stpeter

    ralphm: right :)

  126. MattJ

    That would actually be nice

  127. Kev

    stpeter: I can see drawbacks to this.

  128. stpeter

    the IETF security mafia objected to dialback years ago because "it's not secure" -- but if we use DNSSEC then in fact dialback has useful security properties

  129. Kev

    Largely that you're pushing the experimental in with the established, and it risks how you judge that implementations are compliant.

  130. stpeter

    Kev: right

  131. stpeter


  132. Kev

    I would be a little reluctant to make a move that would mean we have a sum total of zero servers that implement S2S.

  133. MattJ

    Nothing on the internet is "secure" :)

  134. ralphm

    Kev: nod

  135. ralphm

    Yeah, I don't care for the non-secure argument, we all know the trade-offs

  136. stpeter

    Kev: another approach would be to do all this work at the XSF, and then eventually publish an RFC when we publish 6120 bis a few years from now

  137. Kev

    So, if the RFC route is taken, I think it's probably better to publish two - one with what we have, and one with what we want.

  138. stpeter

    but splitting things across IETF and XSF feels a bit odd here

  139. stpeter


  140. stpeter

    I just wanted to raise the issue

  141. Kev

    ralphm: Well, the IETF security guys *have* to complain that it's not secure, that's their purpose. What then happens is a matter for pragmatism.

  142. stpeter

    there will be discussions in Quebec City about DNA/DNSSEC

  143. linuxwolf

    it also matters what your definition of "secure" is

  144. Kev

    stpeter: I'm not opposed to the idea, at least at first glance, - just the implementation of rolling everything into one RFC.

  145. linuxwolf

    which is hard to get them to nail down sometimes (-:

  146. ralphm

    Haven't we earlier taken initial work as XEPs to then incorporate them into an RFC?

  147. stpeter

    ralphm: yes indeed

  148. linuxwolf

    ralphm: yes, privacy

  149. ralphm

    I don't see how it hurts to first have a few XEPs, worked on by the same people as in the WG

  150. linuxwolf

    the DNSSEC/DNA stuff will happen the IETF with or without us

  151. ralphm

    unless there are legal issues around this

  152. stpeter

    and roster versioning and so on

  153. stpeter

    well, the XMPP WG is just the folks who participate

  154. ralphm

    my point

  155. stpeter

    the IETF is not some monolithic entity

  156. linuxwolf


  157. linuxwolf

    well, it's not a 1:1 mapping of standard@ and xmppwg@ commenters

  158. stpeter

    Kev: your point about two documents is well taken

  159. Kev

    So, what do we need to discuss about this here? Anything, or was it an airing?

  160. stpeter

    Kev: as in, publish dialback-core and dna-using-dialback with a reference to dialback-core

  161. linuxwolf

    two documents actually sounds like a good way to go…whether they're XEPs or RFCs

  162. ralphm

    Can't we just have the discussion on the xmppwg mailinglist and defere standards@ to that? We have multiple different lists for specific interest areas

  163. Kev

    stpeter: Yes, with bibi probably belonging in the latter, because that's also new and exciting.

  164. stpeter

    so for now I think it's fine to proceed with XEP-0220, but it would be nice to get it done

  165. stpeter

    Kev: yes

  166. linuxwolf

    and you want some level of assurance above "(non SEC) DNS lookups worked"

  167. linuxwolf

    (for bidi)

  168. stpeter

    and eventually I think we might republish 220 back at the IETF, but there's no hurry about it (could be done when we do the great republish of 6120bis, 6121bis, 6122bis, etc.)

  169. stpeter

    (if we do :)

  170. ralphm

    I have to cut out the meeting now to catch my train. Thanks all.

  171. linuxwolf


  172. stpeter


  173. stpeter


  174. stpeter

    that's all from me

  175. stpeter

    no action required

  176. Kev

    Thanks Ralph.

  177. stpeter

    just an airing

  178. Kev

    I think we're done anyway :)

  179. linuxwolf

    nice and short

  180. Kev

    So, any other any other business?

  181. stpeter

    any other AOB? ;-)

  182. MattJ

    No AOB

  183. stpeter

    none here

  184. linuxwolf

    not directly council related, per se (-:

  185. Kev


  186. Kev

    In that case, thanks all!

  187. Kev gabs the bangle.

  188. linuxwolf

    need to add my comments to the "Great XSF Reset" discussion

  189. linuxwolf


  190. stpeter loves the word "fab" and needs to use it more often but can't quite bring it off with that British panache

  191. Kev

    linuxwolf: I think there we may have a gift that keeps on giving.

  192. stpeter

    I haven't yet read any of the messages that came in on that thread overnight

  193. Kev

    Most were me.

  194. linuxwolf

    Kev: as long as it's not "We need a better name than XSF" again…and again…and again...

  195. Kev

    linuxwolf: Those Jabber guys are evil.

  196. linuxwolf


  197. Kev

    I was there, I remember :)

  198. linuxwolf

    they should be hoisted by their own petards

  199. linuxwolf


  200. stpeter

    Those Jabber guys *were* evil.

  201. stpeter

    not sure if they've reformed since then

  202. linuxwolf

    at least one hasn't...apparently

  203. Kev

    I think at least one raised issue is important.

  204. linuxwolf goes to read and comment on emails

  205. ralphm has left

  206. Kev

    There is a perception, at least from some, that Council and Board aren't doing their jobs, and we clearly need to address this.

  207. Kev

    Or, well, I assert that we need to address this.

  208. linuxwolf


  209. stpeter

    Kev: I'll wait for your minutes before issuing a LC on 296, and I think we might need to clarify the basis for such actions, but in general I think it is acceptable for a simple majority of Council members present to make a decision to issue a Last Call (i.e., no need to wait for Fritzy to weigh in)

  210. stpeter

    actually I think the Council is doing a fine job

  211. Kev

    Given that LC isn't an advancement action, per se, I think I'd buy that.

  212. stpeter


  213. stpeter

    I think http://xmpp.org/about-xmpp/xsf/xmpp-council/policies-and-procedures/ is not quite clear on the matter

  214. Kev

    I think Council is, in some ways, doing better than it did at one point.

  215. stpeter


  216. Kev

    I feel it's taken how ever many years it is to start to work out what the Chair should be doing, and try to start doing it.

  217. Kev

    I think if the outcome of this debate is that Board and Council become more accountable, this is a good thing.

  218. stpeter

    well the Board's mandate is not as clear as the Council's, which is part of the challenge

  219. stpeter

    and, for the record, I think Kev does an excellent job as Council Chair

  220. Kev

    stpeter: It's true, but it also makes it hard to not wonder if they're pulling their weight. Their mandate to be doing stuff may not be clear, but the perception that unless stuff is being done they're not meeting their mandate seems hard to counter.

  221. Kev

    Aww, thanks.

  222. Kev

    Council is almost as simple as "Are there being votes on XEPs? Please tick as appropriate".

  223. Kev

    (To judge whether the job is being done)

  224. stpeter


  225. stpeter

    I do think it would help to clarify what a council "vote" is

  226. stpeter

    and when the two-week period applies

  227. Kev


  228. stpeter

    e.g., perhaps that applies only to advancement, not to acceptance (0.1) or last calls

  229. stpeter

    that's how I'd think of it

  230. Kev

    I would be happy with something like: Acceptance you have until the meeting to complain. Advancement you have a fortnight after the meeting.

  231. Kev

    Or something.

  232. Kev

    Although as I noted on list, if we were to do the former we'd need to not count submissions made 30seconds before the meeting.

  233. stpeter


  234. stpeter

    we'd need all submissions to happen a week before

  235. Kev

    I do like the idea of people being able to autosubmit their stuff, and authors being able to autoupdate their Experimentals, and things.

  236. Kev

    I realise I have commit access to the repository, but I don't have access (or have access but not authority) to publish a new version.

  237. stpeter

    not sure we have enough publication activity to warrant work on automated tools, although I have no objection to doing so

  238. Kev

    Setting up an email address to which you can send new versions, or a web form through which you can upload, or whatever, and have everything happen automagically sounds terribly swish.

  239. Kev

    I accept there may well be an issue of perception rather than efficacy here.

  240. stpeter


  241. stpeter

    the IETF has tools for that

  242. stpeter


  243. Kev

    Right, I'm aware of it, although haven't used it.

  244. stpeter

    Kev: I'd be happy to work with you, via the list or not, on revisions to http://xmpp.org/about-xmpp/xsf/xmpp-council/policies-and-procedures/

  245. stpeter

    proposed revisions for review and approval by the rest of the Council, that is

  246. Kev

    Thanks. I think the best thing is probably to wait a short while for the list discussion to die down (maybe it already has, or maybe it'll errupt now those Merkin types have worken up) and see what seems prudent from that.

  247. stpeter


  248. stpeter

    speaking of which, I need to catch up :)

  249. stpeter

    but first I need to wash my breakfast dishes, brb

  250. Kev


  251. Kev

    I'm looking forward to dinner right now ;)

  252. bear has joined

  253. stpeter

    OT: it's starnge that there's no equivalent for "bon appetit" in English... http://www.omniglot.com/language/phrases/bonappetit.htm

  254. stpeter

    strange, even

  255. stpeter goes back to his email client

  256. Kev

    Oh, there is, isn't there?

  257. Kev


  258. stpeter


  259. stpeter

    there must be some old English phrase to bring back

  260. bear has left

  261. Kev

    Right, let's see if I can get those minutes out quickly.

  262. Kev

    stpeter: Sorry, I realise I wasn't clear earlier in AOB. I'm happy with the namespacing for 220, as I said on list at the time, I'm not blocking on that.

  263. stpeter

    right, I understood

  264. Kev

    I think there were no actions arising from that AOB. Is that your understanding?

  265. stpeter


  266. stpeter


  267. erik has left

  268. mlundblad has left

  269. linuxwolf has left

  270. bear has joined

  271. bear has left