XMPP Council - 2011-10-05


  1. Kev

    I'm going to pop out for a couple of minutes. Should be back for the meeting in 40mins, but if I'm a couple of minutes late...apologies.

  2. stpeter

    ok, no worries

  3. linuxwolf

    pong?

  4. linuxwolf

    testing

  5. linuxwolf

    this is going to be interesting …

  6. linuxwolf

    the power is on and off at home today

  7. linuxwolf

    so I might not be able to stay in this meeting

  8. Kev

    pong

  9. linuxwolf

    ping?

  10. Kev

    A neutrino walks into a bar.

  11. linuxwolf

    "No charge"

  12. stpeter

    An infinite number of mathematicians walk into a bar.

  13. linuxwolf

    so, I'm getting solar panels installed today…was supposed to be done yesterday

  14. linuxwolf

    so if I drop, it's because they're switching from evil grid-based electricity to good sun-based electricity

  15. stpeter

    but at least you're saving the planet!

  16. Kev

    Remind me where the energy for the grid-based electricity comes from :)

  17. linuxwolf

    coal

  18. Kev

    It's some big glowing thing somewhere.

  19. Kev

    But I'm sure it must be evil :D

  20. linuxwolf

    mostly I don't want another rate hike

  21. linuxwolf

    "since you're doing such a good job conserving energy, we're rewarding you with a higher rate"

  22. linuxwolf

    ok, quick run for caffeine … should be back in two minutes

  23. stpeter

    Ralph appears to be offline

  24. Kev

    And it's 4pm.

  25. stpeter

    correction, he's just away

  26. Kev

    So let's start.

  27. Kev

    1) Roll call.

  28. Kev

    I'm here.

  29. Kev

    MattJ? linuxwolf?

  30. MattJ

    Present

  31. stpeter

    clearly linuxwolf hasn't found coffee yet

  32. linuxwolf

    ugh

  33. linuxwolf

    now I'm here

  34. Kev

    Righty.

  35. Kev

    2) 296.

  36. Kev

    linuxwolf: do you want to call for a vote on this, or leave it in Last Call for a while?

  37. Kev

    I still think that this breaks caps.

  38. linuxwolf

    it can stay in LC awhile longer

  39. linuxwolf

    can you explain how it break capabilities

  40. Kev

    Whenever you unlock a chat, you no longer have caps available to you for the current chat.

  41. Kev

    So, for example, CSN will stop working every time you unbind the chat.

  42. Kev

    Currently 296 recommends/mandates unlocking in situations where it's completely redundant (only one resource available, but you still unbind because it changed status) - but beyond this all this unbinding means you break caps far more often than you need to.

  43. linuxwolf

    I'll think about language for single resource

  44. linuxwolf

    I will tell you that when multiple clients are in place, this is working very wonderfully

  45. Kev

    I take the point of there being some semi-broken clients out there on board as an argument for always unlocking on presence of anything anywhere, but the consequences of this for well-behaved clients (and this *is* a list of best practise, rather than how to work around dodgy clients and gateways) are negative.

  46. Kev

    *practice

  47. linuxwolf

    you're assuming that a change availability MUST mean a change in <show/>

  48. Kev

    I'm assuming that's the typical case, yes.

  49. Kev

    Without statistics to the contrary, I think it's probably true, too.

  50. linuxwolf

    I don't think that's a vaild assumption

  51. linuxwolf

    it's not a valid assumption on the networks I've worked with … some of them being buggy clients but a lot of them having legitimate reasons for it

  52. stpeter

    it's not infrequent that I change from dnd "in a meeting" to dnd "on a conference call" or whatever

  53. Kev

    linuxwolf: Networks on the Internet?

  54. linuxwolf

    still available but in a meeting

  55. Kev

    stpeter: These are the same status, though - you're still DND.

  56. stpeter

    different status, same show

  57. Kev

    Right, I didn't mean same <status/>

  58. Kev

    You are still saying "Don't disturb me".

  59. Kev

    With the proposed unlocking scheme, you start getting messages because of this change, which doesn't seem right at all.

  60. linuxwolf

    when I had more capable clients, I would switch priorities and statuses, but not <show/>

  61. stpeter

    Kev: clearly I need to review it more closely

  62. linuxwolf

    and there are clients that allow for that, even if the user doesn't really realize it

  63. Kev

    linuxwolf: A switch of priority is a good reason to unlock, I think.

  64. linuxwolf

    it's a crucial reason to unlock

  65. linuxwolf

    I think it's also important to unlock if you get a new caps hash

  66. Kev

    I'll buy that, too.

  67. linuxwolf

    but instead of adding a million special cases, we tried this

  68. linuxwolf

    it seems to be working very well

  69. linuxwolf

    for about 6 years now between all the clients I've had influence with (-:

  70. Kev

    I'm not arguing that there's no deployments, especially when using corporate gateways potentially, where the proposed scheme works well.

  71. Kev

    I don't think it's the right thing for the Internet, though.

  72. linuxwolf

    the internet is not the majority of users

  73. linuxwolf

    not by a long long shot

  74. linuxwolf

    if we're going to write our protocols for a minority, we're going to get into trouble

  75. MattJ

    I wouldn't call the internet a minority either :)

  76. linuxwolf

    of XMPP users, it most certainly is

  77. MattJ

    I'm quiet because I'm not sure what the correct solution is... resource locking in general feels more like a hack to me daily

  78. linuxwolf

    *most* of us are on some sort of private or corporate service

  79. linuxwolf

    MattJ: While I can see that, I'm not sure how else we get there

  80. MattJ

    When I say I'm not sure what the correct solution is, I suggest there might not be one... we need to decide what we're designing for and choose the best option possible

  81. linuxwolf

    SIMPLE+MSRP seems worse to me (-:

  82. MattJ

    Well you're clearly using this in production, and you're saying this logic works

  83. linuxwolf

    yes

  84. Kev

    linuxwolf: If you're writing this XEP for non-federating deployments, then call it Best Practices for Internal Corporate Resource Locking or something, and I don't have issue with it, and we can come up with another one for the public network.

  85. linuxwolf

    Kev: this is federating

  86. MattJ

    I agree with Kev though that e.g. a repeated <presence/> shouldn't really cause an unlock

  87. stpeter

    I think it's difficult to say where the majority of deployment occurs.....

  88. linuxwolf

    for the most part, presence changes don't happen that often for a given indivdual

  89. stpeter

    perhaps do we need to do a bit of research here?

  90. Kev

    Or just listing the assumptions and requirements in the protoXEP as a start.

  91. linuxwolf

    I can add a list of assumptions

  92. Kev

    Ok, moving on then.

  93. Kev

    3) Account management.

  94. Kev

    Are we satisfied with the state of community feedback to the point that we can now reject/accept it?

  95. linuxwolf

    in it's current form, I think so

  96. Kev

    In the weeks the discussion's been open, I've yet to see anyone argue in favour of it, so if we're doing this now I'm -1.

  97. linuxwolf

    although

  98. stpeter will read 296 again

  99. linuxwolf

    Jehan did just state he'd been out of contact, so was not able to respond

  100. Kev

    Yes.

  101. Kev

    Although ideally I'd like to see someone other than the author think it's a good idea to publish it.

  102. Kev

    But I'm happy to put this off for another week.

  103. MattJ

    Yes, I don't see his reply yet

  104. linuxwolf

    so, calling the linuxwolf from a minute ago a moron, we might want to give him a few days to respond

  105. Kev

    4) Server Dialback - the way forward.

  106. MattJ

    I'm in favour of that

  107. MattJ

    Quite an agenda today :)

  108. linuxwolf

    yes

  109. stpeter

    :P

  110. Kev

    stpeter: Over to you.

  111. stpeter

    so I updated XEP-0220 to incorporate a few bug reports

  112. stpeter

    have not heard from fippo since then, although it took me months to reply to him the last time!

  113. stpeter

    it might make sense to hold another Last Call

  114. Kev

    I think the way forward is for Peter to put out a new version 220, start a new LC and go from there. If Fippo, or any other authors, think there are bugs in the spec, they can also propose a new version (or a rollback), and we can compare in LC.

  115. stpeter

    right

  116. linuxwolf

    /nod

  117. stpeter

    WFM

  118. Kev

    Ok.

  119. Kev

    5) 234.

  120. MattJ

    Me too

  121. linuxwolf

    we need to push on that

  122. linuxwolf

    or maybe the next council does (-:

  123. stpeter

    so, about 234, I think the primary thing is the hashes spec http://xmpp.org/extensions/xep-0300.html

  124. stpeter

    Tobias and others might have feedback more directly related to 234

  125. Kev

    I think we can probably LC 300 if we want to.

  126. Kev

    It's fairly simple.

  127. stpeter

    but we can't advance 234 until we advance 300

  128. linuxwolf

    /nod to both

  129. stpeter

    one thought: we might want to look at how 300 would slot into other extensions

  130. Kev

    stpeter: Is that a prerequisite to advancing 300?

  131. stpeter

    so that we can figure out if it's generic enough

  132. stpeter

    Kev: well, I'd hate to advance it while thinking that it solves all problems when it solves only the file transfer problem

  133. Kev

    Ok.

  134. stpeter

    one concern I have is that existing protocols might use hashes as attributes, not elements

  135. MattJ

    I seem to remember a post where you listed the possible other protocols that could use it

  136. stpeter

    so we'd need to see how to retrofit

  137. stpeter

    MattJ: probably, I need need to go back and look at those

  138. stpeter

    but we could do that during LC

  139. linuxwolf

    /nod

  140. stpeter

    I just wanted to raise the issue so we're thinking about it

  141. linuxwolf

    It's hard to apply multiple hashes in an attribute though (-:

  142. stpeter

    that's all from me

  143. stpeter

    linuxwolf: right :)

  144. Kev

    Ok then. So I see this as nothing for Council to do but wait for Peter to look at updating other XEPs for 300.

  145. Kev

    6) -0009

  146. Kev

    Not something I ever expected to discuss in a Council meeting.

  147. stpeter

    Kev: sure

  148. stpeter

    no?

  149. Kev

    I thought it was a) dead and b) ancient :)

  150. stpeter

    it would require a new version to correct that error

  151. linuxwolf

    (-:

  152. stpeter

    oh

  153. stpeter

    heh

  154. stpeter

    well, periodically we receive reports of people using it

  155. MattJ

    Wait, what's up with 0009? Have I missed a mail?

  156. stpeter

    MattJ: yes, you have

  157. Kev

    [Standards] Regarding capitalization of base64 type in Jabber-RPC (XEP-0009)

  158. linuxwolf

    <base64/> vs <Base64/>

  159. MattJ

    Ah, that one!

  160. stpeter

    right

  161. MattJ

    Sorry, I remember now... forgot which spec was under discussion in that thread :)

  162. Kev

    So we should just update -9 to use the right caps, shouldn't we?

  163. stpeter

    I think so

  164. linuxwolf

    yeah

  165. Kev

    Although...

  166. stpeter

    I think the book from which we borrowed the XML schema is simply wrong

  167. Kev

    It's final. This is an incompatible change.

  168. stpeter

    I am happy to check with Dave Winer

  169. Kev

    So I guess we shouldn't and should live with the wart.

  170. linuxwolf

    /sigh

  171. linuxwolf

    probably

  172. MattJ

    Time for XMPP-RPC? :)

  173. linuxwolf

    we have that with XEP-0004 d-:

  174. linuxwolf

    /ducks

  175. Kev

    We *could* update -9 with a new namespace and a note saying that in the new namespace you use the right case but everything else is identical.

  176. linuxwolf

    I'm not convinced we should change −0009, personally

  177. linuxwolf

    if we change it, it's to add language that we acknowledge our fallibilities

  178. stpeter

    we might want to at least document the wart

  179. linuxwolf

    right

  180. Kev

    Yes.

  181. MattJ

    OTOH, it's just a schema issue, right?

  182. linuxwolf

    "just"

  183. MattJ

    Well, we've typically declared our schemas as informational only

  184. Kev

    MattJ: Right, but unfortunately the schema is the only content of xep9.

  185. stpeter

    heh

  186. Kev

    So there's no text that contradicts the schema or anything.

  187. stpeter

    well

  188. MattJ

    So this could be construed as an editorial issue... perhaps ;)

  189. stpeter

    the spec says: There is no official XML schema for XML-RPC. The main body of this schema has been borrowed from an unofficial schema representation contained in the book "Processing XML With Java" by Elliotte Rusty Harold

  190. stpeter

    I would expect existing XML-RPC libraries to use <base64/>

  191. stpeter

    so I think further research might be useful

  192. Kev

    Right.

  193. Kev

    So is the right/easy thing to do to copy/paste xep9 into xep3xx, change that one thing plus the namespace, and obsolete xep9?

  194. MattJ

    +1 to research, what actually breaks if we change it is what counts

  195. stpeter

    nod

  196. linuxwolf

    +1 to research

  197. Kev

    Asking people who've implemented what happens if we change it is fine by me.

  198. Kev

    Ok.

  199. Kev

    7) Next date.

  200. linuxwolf

    SBTSBC works for me

  201. Kev

    Next week's going to be somewhere between impossible and P(0) for me, i think.

  202. stpeter

    http://groovy.codehaus.org/Groovy+Jabber-RPC and all that

  203. linuxwolf

    or not (-:

  204. stpeter

    I will be offline next week

  205. Kev

    Council *can* have a meeting without me if they want, but it's being a bit optimistic expecting quorum :)

  206. MattJ is calculating dates

  207. linuxwolf

    so … is this the last meeting this term?

  208. stpeter

    hmm

  209. stpeter

    possibly, yes

  210. MattJ

    I can do next week, the week after is hard for me

  211. MattJ

    probably

  212. Kev

    Next term starts 25th, IIRC

  213. linuxwolf

    anytime in Oct works for me

  214. stpeter

    October 19 would be within this term

  215. linuxwolf

    10/12 is impossible for Kev, and 10/19 is hard for MattJ

  216. linuxwolf

    assuming elections are the week of 10/23, that would make this meeting the last

  217. Kev

    I'm working, but I'm in the office and there are only a few hours everyone will be there.

  218. MattJ

    Maybe different days for next week could work?

  219. MattJ

    We can always pick one on list if we need to discuss something

  220. linuxwolf

    I'm open to any day but Tuesday

  221. Kev

    Well, I'm in the office all week next week, but can probably sort something out on Tuesday... :)

  222. Kev

    Monday, maybe, at a pinch, but it'd be hard.

  223. linuxwolf

    Tuesday is impossible for me, unless it's after 13:00 MDT

  224. linuxwolf

    I have a sprint planning meeting, and they go about 4 hours

  225. Kev

    We could try Monday or Tuesday of the week of the 25th.

  226. Kev

    Just before term ends.

  227. Kev

    Assuming we have anything to discuss, of course.

  228. stpeter

    http://search.cpan.org/~qmacro/Jabber-RPC-0.01/lib/Jabber/RPC.pm uses http://search.cpan.org/~rtfirefly/Frontier-RPC-0.07b4p1/lib/Frontier/RPC2.pm and that has <base64>

  229. linuxwolf

    let's see where we're at on Friday, and go from there

  230. stpeter

    just FYI :)

  231. MattJ

    Yay

  232. stpeter

    and Fronter::RPC2 is probably the reference implementation

  233. Kev

    stpeter: So maybe no-one implements the XEP and we should fix it.

  234. Kev

    Anyway.

  235. Kev

    We're way gone tolerance now.

  236. stpeter

    right

  237. linuxwolf

    (-:

  238. MattJ

    Heh

  239. stpeter

    I'll do more research

  240. MattJ

    Kev is going to explode

  241. Kev

    Shall we call for a meeting onlist if it turns out we have something to discuss, but otherwise assume this was the last meeting?

  242. linuxwolf

    that's what I was suggesting (-:

  243. stpeter

    yes

  244. MattJ

    +1

  245. Kev

    8) AOB

  246. Kev

    And risk my wrath :p

  247. Kev

    No?

  248. Kev

    Jolly good :)

  249. Kev

    Thanks all.

  250. Kev bangs the gavel.

  251. MattJ

    Wait!

  252. MattJ

    I had an AOB for 17 minutes!

  253. MattJ

    Just to see what would happen

  254. stpeter watches Kev press the Smite button on his keyboard

  255. linuxwolf

    I've already blown off one meeting

  256. linuxwolf considers slapping MattJ with a dead trout

  257. Kev

    I hope they enjoyed that.

  258. linuxwolf

    I'll find out in about 30 seconds (-:

  259. linuxwolf

    it's at 9:30 MDT

  260. Kev

    We seem to be short of a MattJ on the Council applications at the moment.

  261. MattJ

    Yes...

  262. MattJ

    I'll write it

  263. Kev

    Jolly good.

  264. linuxwolf

    you have until Sunday

  265. MattJ

    Oh, that's ok then

  266. MattJ

    I'll write it on Sunday

  267. MattJ

    I'm useless at writing about myself

  268. linuxwolf

    dude

  269. linuxwolf

    1) find last year's page

  270. linuxwolf

    2) copy

  271. MattJ

    :D

  272. linuxwolf

    3) paste

  273. linuxwolf

    (-:

  274. linuxwolf

    4) minor edits for changes in priorities

  275. linuxwolf

    DONE

  276. MattJ

    The wiki looks very smart, I rarely go to the front page

  277. stpeter

    http://svn.python.org/projects/python/trunk/Lib/xmlrpclib.py has <base64>

  278. MattJ

    We're winning

  279. linuxwolf

    no, we're losing (-:

  280. stpeter

    I'll keep pasting data points here

  281. linuxwolf digs up JSO

  282. MattJ

    linuxwolf, I'm still in favour of changing the schema

  283. MattJ

    It's 1 byte!

  284. stpeter is of the opinion that this is a schema correction and the schema was always informative anyway

  285. linuxwolf

    I know there's a few people using it for PRC

  286. linuxwolf

    RPC even

  287. MattJ

    Me too

  288. linuxwolf

    (-:

  289. Kev

    In this situation I'm not opposed to correcting the XEP.

  290. Zash

    case is 1 bit diff in ASCII

  291. MattJ

    Update the schema with a note that the update was made to correct the schema and reflect reality

  292. linuxwolf

    I use UTF-32, you insensitive clods

  293. linuxwolf

    (which is also a 1-bit difference, yes)

  294. linuxwolf

    I starting to accept a schema change, as long as we add some text about what it used to be

  295. linuxwolf

    and that such text is not only found in the Revision History!

  296. stpeter

    for sure

  297. stpeter

    http://ditchnet.org/xmlrpc/ has <base64>

  298. Kev

    Ok, Jury's in, then.

  299. stpeter

    the qxmpp library seems to have <base64>

  300. stpeter

    http://www.ntecs.de/ruby/xmlrpc4r/ has <base64>

  301. MattJ

    http://louizatakk.fedorapeople.org/sleekxmpp-1.0-Beta2-0/sleekxmpp/plugins/xep_0009.py

  302. Lance Stout

    SleekXMPP uses Base64, but I can change that

  303. MattJ

    Base64

  304. MattJ

    Lance Stout, nice :)

  305. stpeter

    http://hg.python.org/cpython/file/2.7/Lib/xmlrpclib.py has <base64>

  306. stpeter

    I might be finding repeats at this point....

  307. stpeter

    all this because someone pressed the shift key a little too long

  308. MattJ

    Heh

  309. linuxwolf

    and it's the only one that's capitalized, too

  310. linuxwolf

    that's even funnier

  311. stpeter

    which one?

  312. linuxwolf

    Base64

  313. stpeter

    oh

  314. stpeter

    yeah

  315. stpeter

    the xmppframework libraryhas <base64> .... http://code.google.com/p/xmppframework/source/browse/Extensions/XEP-0009/XMPPIQ%2BJabberRPC.m?spec=svnb6dfb5e2b007bb59043f82a7156a3710e4bbcb13&r=b6dfb5e2b007bb59043f82a7156a3710e4bbcb13