XMPP Council - 2011-05-18


  1. stpeter has joined
  2. stpeter has left
  3. Tobias has joined
  4. Tobias has left
  5. Tobias has joined
  6. Kev has left
  7. Kev has joined
  8. Tobias has left
  9. Tobias has joined
  10. stpeter has joined
  11. Fritzy has joined
  12. Fritzy Kev: I have given my feedback and reasons for vetoing Sensors over XMPP
  13. Kev Evening.
  14. Kev Thanks.
  15. stpeter thanks, Fritzy!
  16. Fritzy *nod* -- sorry it's so late.
  17. linuxwolf has joined
  18. linuxwolf /sigh … one of my network drops is dead
  19. linuxwolf that's going to make today interesting
  20. stpeter heh
  21. linuxwolf if only I worked for a company that knew something about networking...
  22. stpeter :)
  23. linuxwolf on the plus side, I have no phone, since it's the one plugged into the dead drop (-:
  24. Fritzy You find good in bad. I like!
  25. stpeter every silver lining has a cloud!
  26. ralphm has joined
  27. linuxwolf and a nice movie reference, fritzy!
  28. ralphm hi
  29. linuxwolf adds Fifth Element to the queue
  30. Kev Right.
  31. Kev Dingding etc.
  32. stpeter wonders if http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/ is up to date
  33. linuxwolf !agendaup
  34. Kev 1) Roll Call
  35. Kev MattJ has been poked.
  36. Fritzy here
  37. linuxwolf presente
  38. Dave Cridland has joined
  39. Kev Ralph here?
  40. stpeter yes
  41. Kev Oh, sorry, didn't recognise the new nick.
  42. Kev stpeter: Hi Ralph.
  43. stpeter :)
  44. Kev 2) Agenda bashing.
  45. Fritzy None
  46. linuxwolf nay
  47. ralphm new nick?
  48. Kev ralphm: stpeter replied on your behalf.
  49. Kev 3) XEP-0220 (Server Dialback), advance to Draft?
  50. Fritzy +1
  51. ralphm
  52. stpeter ooh nice
  53. linuxwolf there's still some discussion on how to advertise db+errors, correct?
  54. stpeter linuxwolf: yes
  55. Kev I'd rather hold off on Drafting this until there's at least some agreement amongst the authors :)
  56. Fritzy ah, ok
  57. linuxwolf Kev: I don't think that will happen
  58. MattJ has joined
  59. Kev The namespace versioning issue needs resolution, too.
  60. MattJ enters quietly
  61. stpeter Kev: I think that's the same issue, no?
  62. Kev stpeter: Is it? I thought he was complaining about a bug in Example 7.
  63. Kev Ah.
  64. Kev Which is, indeed, error handling.
  65. Fritzy sounds like I should retract my vote.
  66. Fritzy If things are still up in the air
  67. linuxwolf s/to=sender.tld/to=target.tld/
  68. MattJ I think they are
  69. Kev stpeter: Do you have comment on this?
  70. Dave Cridland FWIW, i think the existing errors feature advertising has been about long enough that even if the implementations *could* be changed, I suspect there'll be confusion if it were changed in the spec.
  71. MattJ Prosody doesn't implement it, I'm not sure ejabberd does - M-Link and PSYC? :)
  72. ralphm I'm not sure why this would impede advancement, as this was already in the spec and people apparently have implemented and it is seems backwards compatible
  73. linuxwolf also, technically, XEP-0220 is experimental
  74. Dave Cridland MattJ, I thought someone else mentioned doing so, as well.
  75. Dave Cridland linuxwolf, That's not an argument *for* changing it.
  76. Kev ralphm: No-one has implemented the spec as it stands, because it's just had the namespace changed.
  77. stpeter do we agree that this is a poor design? <stream:features> <dialback xmlns='urn:xmpp:features:dialback'> <errors/> </dialback> </stream:features>
  78. linuxwolf heh
  79. Kev That is - all existing implementations are incompatible with the current revision.
  80. linuxwolf I think it is
  81. MattJ stpeter, I think so, yes
  82. linuxwolf (a bad design)
  83. Kev stpeter: Poor design? Yes. What's already in the wild? Probably.
  84. ralphm Kev: oh, right
  85. stpeter because if we keep that, then we need to add a note to the spec saying "this is a bad design, if you design your own stream features in the future then don't do it this way"
  86. linuxwolf dwd: a bad design is a good reason to change it
  87. Dave Cridland linuxwolf, Cool. Can we change self-framing XML, too, then?
  88. Fritzy haha
  89. ralphm gets popcorn
  90. linuxwolf is self-framing XML an experimental XEP?
  91. stpeter and we need to say "if we add new dialback-related features in the future, then they MUST NOT be added as new child elements like <errors/>"
  92. Kev stpeter: That is one of the two options, yes.
  93. Dave Cridland linuxwolf, Proposed Standard, so technically still subject to change.
  94. stpeter how many beers do I need to buy for the M-Links developers to change their minds?
  95. stpeter s/Links/Link/
  96. Dave Cridland (I'm not even sure it is bad design - at best it's inconsistent with Disco)
  97. Kev stpeter: I'm not firmly in one camp or the other. I'd just like to see something approaching agreement.
  98. Kev (Well, I'm firmly in the 'we should not go with the current XEP approach' camp, but not firmly in either of the other two)
  99. linuxwolf I think it's a bad design…and would require the spec to be updated (and the namespace to be changed) if we added more later
  100. Kev linuxwolf: No, that's not true.
  101. linuxwolf it's a schema change
  102. Dave Cridland linuxwolf, I don't see how you arrive at that conclusion.
  103. stpeter I note that http://xmpp.org/extensions/xep-0288.html has: <stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <bidi xmlns='urn:xmpp:features:bidi'/> </stream:features>
  104. stpeter not: <stream:features> <dialback xmlns='urn:xmpp:features:dialback'> <bidi/> </dialback> </stream:features>
  105. Kev linuxwolf: Adding more *the wrong way* later would lead to a schema change.
  106. stpeter although bidi is not strictly a dialback thing
  107. linuxwolf Kev: that's what I'm saying
  108. Kev I'm assuming if we add more features in the future, we'll do it right.
  109. linuxwolf So #1 is out
  110. Kev No.
  111. Kev We've done it the wrong way once, they question is whether to live with it or not.
  112. Kev There's no cause and effect between letting the (previous version) current way stand and having to do it wrong again in the future.
  113. linuxwolf ok, then my vote is to not live with it
  114. Dave Cridland I'd be fine with <errors/> being the last thing added to dialback's stream feature.
  115. linuxwolf but, IMO, we have time to change this
  116. MattJ So is mine, but only if we can track down existing implementations (I'm not sure there are many in reality)
  117. linuxwolf I'm −1 on keeping it, unless there's a plethora of implementation that will break
  118. Kev My preference is that we should only break namespaces when there's an incompatible change being made, really.
  119. linuxwolf then I'll re-evaluate (-:
  120. ralphm we /could/ define a real stream feature and deprecate <errors/> but I'm unsure about the actual impact
  121. Dave Cridland ralphm, Same issue.
  122. ralphm of course
  123. MattJ Dave Cridland, are you saying you're absolutely against switching to a <dialback-errors> feature?
  124. stpeter it's not a hill for me to die on, but it's ugly and the wrong way to do it and sets a bad precedent -- people look at the XEPs for examples of what to do in their own extensions and someone will say "oh they did it in XEP-0220 so it's fine in this extension" (and realize that people might never even look at the spec, they'll just see the XML go across the wire)
  125. linuxwolf we're still advertising support of dialback (sans error-handling) via a namespace declaration, no?
  126. Kev I am, in any case, -1 on advancing 220 as it currently stands, so this discussion can take place on list :)
  127. stpeter linuxwolf: no
  128. MattJ stpeter, I agree it seems bad to have backwards-compatibility cruft in such a "recent" feature
  129. stpeter linuxwolf: advertisment is just via namespace on the stream header
  130. Kev (Which, given that we've not changed 0001 yet means that -0220 has just died. Yay!).
  131. ralphm so discussion ensues and we -1 it for now
  132. ralphm Kev: hehehe
  133. Kev 4) XEP-0262 (Use of ZRTP in Jingle RTP Sessions), advance to Draft?
  134. ralphm
  135. Dave Cridland MattJ, I am generally against changing deployed specs incompatibly for aesthetic reasons, yes.
  136. stpeter I suppose we could say that <dialback xmlns='urn:xmpp:features:dialback'/> means you support dialback with errors and get rid of the child element
  137. stpeter I'd be fine with that
  138. linuxwolf stpeter: I would be ok with that
  139. ralphm stpeter: and if you don't actually do it it doesn't break stuff
  140. stpeter ralphm: right
  141. ralphm and the <errors/> is merely informational no-op
  142. Dave Cridland stpeter, I've a nagging feeling that there exist implementation advertising dialback like that but without supporting errors.
  143. MattJ Is it?
  144. ralphm that'd work for me
  145. Kev Folks, this discussion doesn't need to happen now.
  146. ralphm right
  147. Kev Can we move onto (4) please.
  148. stpeter Dave Cridland: I don't know of any implementations that do it that way
  149. linuxwolf ok, let's focus!
  150. linuxwolf #4
  151. stpeter Kev: trying to use the high bandwidth connection to reach consensus :)
  152. stpeter bt I'll propose it on the list
  153. Kev Discuss in 10mins once Council's over and I can start ignoring the chat :)
  154. Kev 4) XEP-0262 (Use of ZRTP in Jingle RTP Sessions), advance to Draft?
  155. Kev I haven't looked up the feedback thread yet. Will vote on-list.
  156. linuxwolf was there feedback? I don't remember seeing any
  157. MattJ There wasn't feedback iirc
  158. Kev I don't remember any, but I need to find the thread to be sure :)
  159. stpeter heh
  160. MattJ No feedback and I'm not aware of any implementations
  161. stpeter it is implemented in Jitsi
  162. MattJ Ah good
  163. Kev One reply, from Peter, saying that the date was wrong.
  164. stpeter for voice and video
  165. linuxwolf stpeter: can you ping them to send an "a ok" or something about it, then?
  166. stpeter I've seen it displayed at FOSDEM so it must be true
  167. Fritzy well, that's something!
  168. Fritzy Should we ask them for feedback specifically?
  169. Kev If there are known implementations, and no feedback to the LC, I think it's worth poking, yes.
  170. MattJ +1
  171. linuxwolf definitely
  172. Dave Cridland Is Jitsi SIP Communicator as-was?
  173. stpeter Kev: pokage in progress
  174. ralphm +1
  175. MattJ (to poking)
  176. MattJ Dave Cridland, yes
  177. Kev Dave Cridland: Yes.
  178. linuxwolf +1 to POKE, DNV for now
  179. Dave Cridland Anyone else want to say yes?
  180. MattJ Dave Cridland, no
  181. Kev Dave Cridland: No.
  182. Kev Ok, so who's volunteering to poke them for feedback?
  183. MattJ I just have
  184. Kev Ta.
  185. linuxwolf thanks
  186. Kev 5) Date of next.
  187. MattJ Next week is ok for me as far as I am aware
  188. Kev Jolly good.
  189. Fritzy same here
  190. linuxwolf works for me
  191. Kev ralphm?
  192. stpeter any further votes on 178?
  193. ralphm +1
  194. Kev I think the voting period's expired for that hasn't it? :)
  195. Fritzy very much so
  196. Kev 6) AOB.
  197. linuxwolf +1 on −178
  198. linuxwolf thought I did that on-list
  199. ralphm any news on the summit?
  200. Kev ralphm: I think I saw a mail fly by saying it was cancelled.
  201. stpeter linuxwolf: I missed that
  202. linuxwolf but I'm getting ~200 emails/day, so it's getting lost (-:
  203. Kev Although I don't think I was paying much attention at the time.
  204. stpeter linuxwolf: man up :P
  205. stpeter right, we haven't organized the summer summit so we'll see you all in Brussels again someday
  206. MattJ Yay
  207. stpeter so meeting next Wed?
  208. Kev Yep.
  209. stpeter adding to calendar
  210. Kev And we're done with 3mins to spare.
  211. Kev Thanks Peter.
  212. Kev Thanks all.
  213. linuxwolf and now to the flame war
  214. Kev bangs teh gavel.
  215. MattJ Heh
  216. stpeter BTW if folks want to look at my i18n stuff it'd be cool
  217. MattJ stpeter, where is that?
  218. stpeter xmpp@ietf.org
  219. ralphm the precis draft
  220. stpeter or http://xmpp.org/2011/05/progress-on-internationalization/
  221. MattJ Ah yes, thanks
  222. linuxwolf stpeter: on my /todo
  223. MattJ On mine too
  224. linuxwolf plans on reading it while at Casa Bonita
  225. stpeter thank
  226. stpeter thanks even
  227. Fritzy ciao
  228. Fritzy has left
  229. stpeter we can see that Ralph likes Unicode ;-)
  230. stpeter Unicode Rocks™ and all that
  231. linuxwolf Ralphm: what happened to "if you don't like ASCII…f**k you"? (-:
  232. Tobias has left
  233. stpeter heh
  234. ralphm linuxwolf: did I ever say that?
  235. ralphm linuxwolf: also, I don't see how that's conflicting with liking unicode
  236. stpeter ralphm is a man of contradictions :)
  237. linuxwolf haha
  238. stpeter updates http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/ with linuxwolf's vote
  239. ralphm stpeter: pft! Al
  240. linuxwolf ralphm: well, I said the first part…and beers were involved (-:
  241. ralphm linuxwolf: agreed
  242. MattJ stpeter, hmm, my vote isn't there... I'm +1
  243. stpeter ok
  244. MattJ But I'm working more on Prosody's implementation soon so I may have some feedback
  245. ralphm as ASCII is a strict subset of unicode, I don't see how this is a contradication
  246. stpeter not sure if Fritzy voted
  247. MattJ ralphm, you win :)
  248. linuxwolf ASCII is a strict subset of UTF8, actually
  249. linuxwolf (-:
  250. stpeter I think I missed a meeting while travelling of late
  251. ralphm linuxwolf: hehe
  252. linuxwolf and UTF8 is a particular encoding of Unicode, afterall (-:
  253. ralphm nevertheless a thing to like
  254. linuxwolf I've got a slidedeck I can show you about it (-:
  255. linuxwolf stpeter: I don't think my vote on 0220 is accurate
  256. linuxwolf given the revote and updates and whatnot
  257. Kev Indeed. I'm currently -1.
  258. stpeter pings Fritzy about 178
  259. stpeter Kev: noted
  260. stpeter heh, now I'm receiving password requests for chat.facebook.com at jabber.org
  261. linuxwolf stpeter: I'm "" on XEP-0220 right now, pending further discussion about advertisement
  262. linuxwolf ugh
  263. linuxwolf and I'm 10 minutes late to a 15-minute meeting (-:
  264. linuxwolf adios
  265. linuxwolf has left
  266. stpeter linuxwolf: noted
  267. stpeter I changed ralphm to "" as well
  268. stpeter so the only vote is Kev's -1 :)
  269. Kev Which I'll no doubt be changing shortly.
  270. Dave Cridland stpeter, ralphm may well be “”, in fact.
  271. stpeter heh
  272. ralphm
  273. stpeter :)
  274. Dave Cridland
  275. Dave Cridland I tried a bottom bracket with combining umlaut once, and it actually worked. I was particularly happy.
  276. ralphm ̈̈̈̈‿̈
  277. ralphm ooh
  278. Dave Cridland Unicode Art is so much more experssive than the ASCII kind.
  279. ralphm ‿̈
  280. ralphm I had another combining one in there
  281. Dave Cridland There's actually a smile codepoint that might be better.
  282. ralphm ⁀̤
  283. ralphm ̤⁀⃘̤
  284. Dave Cridland ◡̈
  285. Dave Cridland Many options.
  286. ralphm I just tried a combination that kicked out my connection
  287. ralphm with combining musical symbols
  288. ralphm probably because they are in another plane
  289. Dave Cridland Could be anti-codepoints.
  290. Dave Cridland You can't put those in contact with ordinary codepoints, they'll explode.
  291. ralphm I had a cross-note-head with a combining 1/64 stem
  292. Dave Cridland Yeah, you need to have a special screwdriver for those, though.
  293. ralphm has left
  294. Neustradamus has left
  295. Tobias has joined
  296. Neustradamus has left
  297. stpeter has left
  298. Neustradamus has left
  299. Tobias has left