XSF logo XMPP Council - 2010-03-15

  1. Kev has left
  2. Kev has joined
  3. jkhii has joined
  4. darkrain has joined
  5. stpeter has joined
  6. stpeter I might be a few minutes late for the meeting
  7. stpeter bbiab
  8. stpeter has left
  9. MattJ has joined
  10. MattJ Same here, I've been following a clock that was 5 minutes slow
  11. MattJ brbs
  12. stpeter has joined
  13. stpeter wanders back in
  14. Kev I'm following a clock that's right, and says we have one minute left :)
  15. stpeter $ date -u Mon Mar 15 19:00:10 UTC 2010
  16. Kev Indeed.
  17. Kev So, we have Kev and an afk Matt.
  18. Kev Let's see if this improves.
  19. stpeter Remko appears to be online
  20. stpeter but I don't see Ralph
  21. Kev Yes, just came on this moment.
  22. stpeter ah ok
  23. Kev MUC topics not sticking on jabber.org is quite irritating.
  24. stpeter nice http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=50598&tid=1268679729 -- and the mailing list software didn't correctly render ç :)
  25. Kev (I had a redirect note in the topic for council, but of course that was lost, and Remko was sitting there.
  26. stpeter Kev: ah, indeed
  27. stpeter Kev: I did too :)
  28. remko has joined
  29. remko thank you dave for using my name as an example :)
  30. Kev stpeter: of course Ralph's been online on his new phone pretty much constantly since he got it, so presumably he's turned it off specifically to avoid Council ;)
  31. stpeter remko: :)
  32. Kev So, once Matt returns, I guess we should start.
  33. Tobias has joined
  34. stpeter wonders if he has time to put some lunch together while waiting for Mr. Wild
  35. Tobias stpeter: yeah..quite funny the IETF discussion on document format :)
  36. MattJ Here
  37. Kev Ok.
  38. MattJ If I die from eating undercooked food then I want this council meeting mentioned on my death certificate
  39. Kev 1) Roll call.
  40. remko :)
  41. Kev Kev, Matt, Remko here, Ralph absent.
  42. Kev 2) Agenda bashing.
  43. Kev Peter noted onlist that he'd like another discussion of voting periods.
  44. Kev I'll take that as 'none'
  45. Florob has joined
  46. Kev 3) XEP-0136: Message Archiving version 1.2rc1 http://xmpp.org/extensions/tmp/xep-0136-1.2.html Diff: http://xmpp.org/extensions/diff/api/xep/0136/diff/1.1/vs/1.2rc1 Accept changes?
  47. remko is there an implementation for these changes?
  48. Kev I have no idea.
  49. stpeter it's on the way in ejabberd AFAIK
  50. stpeter maybe even checked in
  51. stpeter perhaps also in Gajim
  52. remko sessionremove -> session-remove ?
  53. stpeter we can ask on the standards@ list if it's been implemented fully
  54. Kev I have this open here, but haven't gotten to the end of the diff yet, so I need to vote onlist.
  55. stpeter it was a joint project between Gajim and ejabberd, in essence
  56. remko i have the tendency to ask for implementations if we change specs post-draft
  57. MattJ I went over the changes, but would be happier to give it another run-through and vote on-list
  58. remko unless they're clarifying or bugfixing
  59. stpeter feedback welcome on the standards@ list
  60. stpeter remko: in this case the changes were a result of implementation experience
  61. Kev Ok, votes to follow onlist, then.
  62. Kev 4) XEP Notes. Should we have some comments attached to XEPs and proto-XEPs by Council? Cases in point: server ip check, Software information.
  63. stpeter yep
  64. Kev This was my question
  65. remko stpeter: that's what i expected, it's good to have that information explicit
  66. remko having the comments close to the XEPs doesn't sound like a bad idea. It would take some infrastructure, though, no?
  67. MattJ What kind of comments/notes are we talking about?
  68. Kev There've been a few times where I think it would have been helpful to have annotated XEPs or protoXEPs with a summary of Council's thoughts (particularly I think this is useful for protoXEPs when they come back around for votes after being rejected), although attaching notes to e.g. IP check saying "Look, it's not Stun, and it has no purpose, but we'll let it die on the vine rather than blocking it" would be useful.
  69. MattJ Heh
  70. stpeter like an IESG note in an RFC, I suppose
  71. Kev stpeter: as I understand it.
  72. stpeter well
  73. Kev We don't even have to render it in the XEP if we don't want to, but I think having it in the source would be useful.
  74. Kev Thoughts.
  75. remko is there a reason not to have them in the XEP?
  76. stpeter I think that might be appropriate if a XEP is rejected by the Council after being proposed for advancement to Draft
  77. MattJ That's what I was about to say
  78. MattJ For Server IP Check for example, I think the actual text needs changing
  79. remko not that i have a problem with making them hidden
  80. stpeter for a 0.1 spec? I don't see a good reason for that
  81. Kev remko: not that I can think of, but I was putting it out in case people thought there was.
  82. MattJ So is there an example of something that we would attach that wouldn't go in the text of the XEP itself?
  83. Kev stpeter: well, for example, Jingle nodes had lots of comments from Council, but got let through on the understanding that they get fixed before Draft. I think that's useful to record.
  84. stpeter for a Rejected spec, I think a Council note would be helpful
  85. stpeter Kev: I assume that the spec author could consult the meeting log :)
  86. Tobias but then again rejected specs aren't published are they?
  87. stpeter Tobias: Rejected XEPs
  88. stpeter Tobias: not ProtoXEPs that are never accepted for publication
  89. Kev stpeter: yes, and when Council come to vote to Draft, they can look up the old room logs, and see what was discussed etc., but I think a note is much more convenient.
  90. Tobias stpeter: you mean a XEP being rejected?
  91. Kev stpeter: I was proposing this for protoXEPs that aren't accepted, too.
  92. Kev Just some repository of comments, however that's done, so people don't have to trawl Council logs.
  93. stpeter still favors being liberal in publication and conservative in advancement
  94. MattJ Ok, yes, I think this would be useful
  95. Tobias i see...quite some time since something has been rejected, that councils just have been too kind :D
  96. stpeter Tobias: or bad stuff simply gets deferred
  97. stpeter but if the Council wishes to take on more work by publishing official Council notes, go for it :)
  98. Tobias stpeter: or that, so it would only be rejected if the author of the bad XEP keeps sending in bad updates on it
  99. Kev stpeter: I think it's a net reduction in effort, when faced with agenda items like:
  100. Kev 5) XEP-0232 / software information: this was recently deferred for inactivity but there is still interest in moving this forward. Can the Council review it again and more clearly specify its objections?
  101. stpeter Kev: sure
  102. MattJ How about we just: 1) Make sure to clearly document thoughts, comments and objection reasons in the council minutes
  103. stpeter and composing a note would force the Council to be more explicit about its reasons
  104. MattJ Have some metadata in XEPs to link up to minutes where the XEP was on the agenda
  105. Kev MattJ: that's still referenced by the wrong thing (date instead of xep)
  106. MattJ 2) ^
  107. stpeter naturally the old Council might have no members in common with the new Council :)
  108. Kev MattJ: but if you'd like to come up with some cross-referencing system, go for it.
  109. stpeter heh
  110. Kev I don't care how it's done as long as it's easy for the chair to update.
  111. stpeter probably easier to copy the notes from the minutes to the XEP and be done with it
  112. Kev I would have thought so.
  113. Kev So,
  114. Kev 5) XEP-0232 / software information: this was recently deferred for inactivity but there is still interest in moving this forward. Can the Council review it again and more clearly specify its objections?
  115. Kev I have no memory of this at all.
  116. MattJ Me neither, so I reviewed it - and it looks fine
  117. MattJ Though I'm still partial to jabber:iq:version :)
  118. niekie has joined
  119. stpeter (BTW this also ties in with my point about objection periods and clear objections to XEPs when a Council member votes -1....)
  120. Kev I'll have a read through and post to list if I remember anything I may have once complained about.
  121. remko i have some vague memory
  122. Kev stpeter: Right, I'm all in favour of a -1 report.
  123. darkrain I might be mistaken, but wasn't some of the concern that it has an adverse impact on the number of entires in an entity caps cache?
  124. Kev Albeit where 'report' is pretty much a one-sentence in some cases.
  125. Kev darkrain: that's negligible though, I rather imagen.
  126. Kev *imagine.
  127. Kev That could well have been the complaint, though :)
  128. stpeter there's a longish thread starting here: http://mail.jabber.org/pipermail/standards/2009-January/020909.html
  129. stpeter Remko wanted to know why we were not using data forms
  130. darkrain http://logs.jabber.org/council@conference.jabber.org/2009-04-22.html, too
  131. stpeter s/not//
  132. remko right, that sounds more like me :)
  133. remko that was a void statement though
  134. remko 'because it's disco' was the answer
  135. Kev In any case, can people do this and get back to the XEP Editor, please? :)
  136. stpeter nice summary at http://mail.jabber.org/pipermail/standards/2009-February/020972.html
  137. stpeter This was my understanding of the opinions on this XEP: - Showing the different type of icons per-status is not something people want to implement in clients. The only use I see is for this might be transports, although I still think most clients even want this to be implemented on their side, for better consistency with the rest of the UI look. - Some clients implement the per-client logo avatar, so the logo sounds useful to at least these clients. - There's a security issue with OOB images that at least needs to be documented. Documenting is probably not enough, because I don't see a client displaying client icons asking the user for every type of client whether he wants to fetch the icon (which is different than with 'occasional' OOB requests that need to be acknowledged). There was a suggestion of mediated BoB solutions, which IMO makes sense because it removes the burden of security checks off the clients, and most clients will request the same images anyway.
  138. stpeter as a result we removed these: icon_available icon_away icon_chat icon_dnd icon_xa
  139. stpeter etc.
  140. stpeter anyway
  141. stpeter I can post to the standards@ list :)
  142. Kev 2 minutes left on my meeting tolerance gauge :)
  143. Kev 6) XEP-0193 / multiple resources per stream: several people have expressed an interest in bring back this feature (which was removed from rfc3920bis). Is the Council receptive to taking this on?
  144. MattJ Council meeting 2009-01-21: 5) XEP-0232: Software Information Last call for moving to Draft? No objections.
  145. stpeter MattJ: sure but then we had a second last call
  146. stpeter etc.
  147. Kev I wasn't at all clear what you were asking here.
  148. MattJ Ok
  149. stpeter Kev: we'd have a new XEP with a new namespace, or 193 with a changed namespace
  150. stpeter does the Council have a preference?
  151. stpeter I slightly favor a new XEP
  152. MattJ Why so?
  153. stpeter because 193 was input to the rfc3920bis process
  154. stpeter and we might want to document that for the ages
  155. stpeter shrugs
  156. stpeter either way is fine, really
  157. MattJ Same here :)
  158. MattJ So I was curious why you wanted a new XEP
  159. MattJ If we need to keep 193 around, new XEP is fine with me
  160. Kev I'm happy with a new XEP if that's what you'd like, *shrug*
  161. MattJ Back when I was starting Prosody I asked around as to whether people actually wanted multiple resource binding
  162. MattJ I ended up not implementing it, because I couldn't find anyone with valid use-cases that couldn't be solved otherwise
  163. MattJ Implementing it now would be tricky, and probably not worth the effort
  164. MattJ But since it seems quite a few people do want this, I'm happy to not block it
  165. stpeter MattJ: it remains to be seen whether those who say they want it really do (to the extent of the small amount of work needed to write a new XEP)
  166. MattJ :)
  167. MattJ Cunning
  168. stpeter ok moving on
  169. stpeter I'll work with those who want to do this, if they really do
  170. Kev 7) http://mail.jabber.org/pipermail/council/2010-March/002783.html
  171. Kev Review periods.
  172. stpeter ah
  173. stpeter hmm
  174. stpeter I think I referenced the wrong mailing list post :)
  175. Kev Or I misclicked
  176. Kev Anyway.
  177. stpeter at http://mail.jabber.org/pipermail/council/2010-March/002798.html I said: I think we might also need to specify objection periods. For example: you have two weeks to vote on a XEP and if you vote -1 you have two weeks after the end of the voting period to clearly specify your objections, preferably with suggested fixes. If you don't do that within two weeks, your vote is automatically changed to 0. Currently, a -1 vote can be used as a permanent block, and that's just wrong.
  178. Kev Having the review periods at a fortnight seems fine.
  179. Kev I disagree that -1 being a permanent block is wrong.
  180. stpeter Kev: yes, I already updated XEP-0001 with 14 days
  181. MattJ Ah, hmm
  182. Kev I do agree with having to justify a -1
  183. stpeter Kev: I agree that -1 being a permanent block if fine, but not if you never say why you voted -1
  184. stpeter right
  185. MattJ I've voted too many +1s this year, time for a change
  186. stpeter to vote -1 and say "I'll post to the list about it" and then never post to the list -- I have a problem with that
  187. Kev So you say -1, you've got a fortnight after the fortnight you've got for voting in which to summarise the -1, and hopefully give suggestions for how it can be fixed, if it can.
  188. stpeter right
  189. stpeter that's my proposal
  190. stpeter now, perhaps it can't be fixed
  191. stpeter or the authors never address the clearly stated concern
  192. MattJ stpeter, how does it work at the IETF?
  193. stpeter so it goes to Experimental while the token lives with the authors -- if they never update the spec then it goes to Deferred eventually
  194. stpeter MattJ: the IETF has an elaborate state chart :)
  195. stpeter e.g., "revised I-D needed"
  196. MattJ Ok, forget I asked :)
  197. stpeter if the revised I-D is never submitted, it expires after six months and *poof*
  198. stpeter I just want clear reasons for -1 so that the authors know what they need to change
  199. stpeter e.g., I don't know what to change in XEP-0060 right now
  200. stpeter so good fixes are being held up
  201. MattJ This ties in nicely with the XEP notes :)
  202. Kev MattJ: indeed.
  203. Kev Ok, so, enough on this?
  204. stpeter but I'll poke Ralph again :)
  205. stpeter Kev: yep, enough
  206. Kev 8 ) Peter would like feedback on filetransfer things.
  207. Kev Please do on-list or on-XMPP :)
  208. Kev 9) Date of next meeting.
  209. Kev Same bat time, same bat channel?
  210. MattJ +1
  211. Kev 10) AOB.
  212. MattJ Not from me
  213. stpeter I won't be available next week, but the Council is free to meet without me :)
  214. MattJ Though I'm working on some notes about 198 which I'll post to standards@ soon
  215. remko ok
  216. Kev MattJ: excellent.
  217. remko none from me
  218. stpeter Kev: any progress on #5?
  219. Kev No-one's shown any interest to me in filling the space.
  220. waqas has joined
  221. Kev So we may end up limping along with four.
  222. stpeter could be
  223. MattJ They've got another week :)
  224. stpeter we rarely need the tie-break anyway
  225. stpeter perhaps I'll poke some folks in private :)
  226. MattJ They'll all contact you on the last day, mark my words
  227. stpeter :)
  228. Kev There's only ever a tie-break involved with voting off Council members, in Council, of course.
  229. Kev As everything we do is veto-based.
  230. stpeter nod
  231. Kev In any case, I think we're done.
  232. stpeter who's writing the minutes this time?
  233. MattJ Kev, you manage to slip that factoid into every meeting :)
  234. stpeter MattJ: :)
  235. Kev stpeter: I can do it, probably tomorrow morning.
  236. Kev MattJ: not every meeting, and it's not always me.
  237. stpeter Kev: ok thanks
  238. Kev Thanks all
  239. Kev bangs the gavel.
  240. stpeter this week is crazy for me
  241. MattJ Kev, true, it used to be the other one
  242. stpeter yay
  243. stpeter updates /council/events.xml
  244. MattJ stpeter, that's my job :)
  245. MattJ But you keep doing it for me
  246. stpeter oh is it?
  247. MattJ Which is just as well, because I often forget
  248. MattJ e.g. I went to update it this morning
  249. MattJ Since you actually have a calendar tied into it, if you think you'll notice more when it needs updating, feel free
  250. stpeter it's a task of less than one minute, so easy enough to do :)
  251. stpeter needs to get back to GTD
  252. stpeter anyway
  253. stpeter gotta run
  254. stpeter bbiab
  255. MattJ My calendar is still telling me about 20 board meetings on the same date in January
  256. darkrain has left
  257. stpeter has left
  258. remko has left
  259. jkhii has left
  260. Florob has left
  261. MattJ has left
  262. MattJ has joined
  263. MattJ has left
  264. waqas has left