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


  14. Kev


  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


  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


  29. linuxwolf adds Fifth Element to the queue

  30. Kev


  31. Kev

    Dingding etc.

  32. stpeter wonders if http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/ is up to date

  33. linuxwolf


  34. Kev

    1) Roll Call

  35. Kev

    MattJ has been poked.

  36. Fritzy


  37. linuxwolf


  38. Dave Cridland has joined

  39. Kev

    Ralph here?

  40. stpeter


  41. Kev

    Oh, sorry, didn't recognise the new nick.

  42. Kev

    stpeter: Hi Ralph.

  43. stpeter


  44. Kev

    2) Agenda bashing.

  45. Fritzy


  46. linuxwolf


  47. ralphm

    new nick?

  48. Kev

    ralphm: stpeter replied on your behalf.

  49. Kev

    3) XEP-0220 (Server Dialback), advance to Draft?

  50. Fritzy


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  171. linuxwolf


  172. Dave Cridland

    Is Jitsi SIP Communicator as-was?

  173. stpeter

    Kev: pokage in progress

  174. ralphm


  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


  185. linuxwolf


  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


  192. stpeter

    any further votes on 178?

  193. ralphm


  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


  207. stpeter

    so meeting next Wed?

  208. Kev


  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


  216. stpeter

    BTW if folks want to look at my i18n stuff it'd be cool

  217. MattJ

    stpeter, where is that?

  218. stpeter


  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


  226. stpeter

    thanks even

  227. Fritzy


  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


  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


  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


  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


  263. linuxwolf

    and I'm 10 minutes late to a 15-minute meeting (-:

  264. linuxwolf


  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


  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


  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