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