XMPP Council - 2011-05-18


  1. Fritzy

    Kev: I have given my feedback and reasons for vetoing Sensors over XMPP

  2. Kev

    Evening.

  3. Kev

    Thanks.

  4. stpeter

    thanks, Fritzy!

  5. Fritzy

    *nod* -- sorry it's so late.

  6. linuxwolf

    /sigh … one of my network drops is dead

  7. linuxwolf

    that's going to make today interesting

  8. stpeter

    heh

  9. linuxwolf

    if only I worked for a company that knew something about networking...

  10. stpeter

    :)

  11. linuxwolf

    on the plus side, I have no phone, since it's the one plugged into the dead drop (-:

  12. Fritzy

    You find good in bad. I like!

  13. stpeter

    every silver lining has a cloud!

  14. linuxwolf

    and a nice movie reference, fritzy!

  15. ralphm

    hi

  16. linuxwolf adds Fifth Element to the queue

  17. Kev

    Right.

  18. Kev

    Dingding etc.

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

  20. linuxwolf

    !agendaup

  21. Kev

    1) Roll Call

  22. Kev

    MattJ has been poked.

  23. Fritzy

    here

  24. linuxwolf

    presente

  25. Kev

    Ralph here?

  26. stpeter

    yes

  27. Kev

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

  28. Kev

    stpeter: Hi Ralph.

  29. stpeter

    :)

  30. Kev

    2) Agenda bashing.

  31. Fritzy

    None

  32. linuxwolf

    nay

  33. ralphm

    new nick?

  34. Kev

    ralphm: stpeter replied on your behalf.

  35. Kev

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

  36. Fritzy

    +1

  37. ralphm

  38. stpeter

    ooh nice

  39. linuxwolf

    there's still some discussion on how to advertise db+errors, correct?

  40. stpeter

    linuxwolf: yes

  41. Kev

    I'd rather hold off on Drafting this until there's at least some agreement amongst the authors :)

  42. Fritzy

    ah, ok

  43. linuxwolf

    Kev: I don't think that will happen

  44. Kev

    The namespace versioning issue needs resolution, too.

  45. MattJ enters quietly

  46. stpeter

    Kev: I think that's the same issue, no?

  47. Kev

    stpeter: Is it? I thought he was complaining about a bug in Example 7.

  48. Kev

    Ah.

  49. Kev

    Which is, indeed, error handling.

  50. Fritzy

    sounds like I should retract my vote.

  51. Fritzy

    If things are still up in the air

  52. linuxwolf

    s/to=sender.tld/to=target.tld/

  53. MattJ

    I think they are

  54. Kev

    stpeter: Do you have comment on this?

  55. 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.

  56. MattJ

    Prosody doesn't implement it, I'm not sure ejabberd does - M-Link and PSYC? :)

  57. 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

  58. linuxwolf

    also, technically, XEP-0220 is experimental

  59. Dave Cridland

    MattJ, I thought someone else mentioned doing so, as well.

  60. Dave Cridland

    linuxwolf, That's not an argument *for* changing it.

  61. Kev

    ralphm: No-one has implemented the spec as it stands, because it's just had the namespace changed.

  62. stpeter

    do we agree that this is a poor design? <stream:features> <dialback xmlns='urn:xmpp:features:dialback'> <errors/> </dialback> </stream:features>

  63. linuxwolf

    heh

  64. Kev

    That is - all existing implementations are incompatible with the current revision.

  65. linuxwolf

    I think it is

  66. MattJ

    stpeter, I think so, yes

  67. linuxwolf

    (a bad design)

  68. Kev

    stpeter: Poor design? Yes. What's already in the wild? Probably.

  69. ralphm

    Kev: oh, right

  70. 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"

  71. linuxwolf

    dwd: a bad design is a good reason to change it

  72. Dave Cridland

    linuxwolf, Cool. Can we change self-framing XML, too, then?

  73. Fritzy

    haha

  74. ralphm gets popcorn

  75. linuxwolf

    is self-framing XML an experimental XEP?

  76. 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/>"

  77. Kev

    stpeter: That is one of the two options, yes.

  78. Dave Cridland

    linuxwolf, Proposed Standard, so technically still subject to change.

  79. stpeter

    how many beers do I need to buy for the M-Links developers to change their minds?

  80. stpeter

    s/Links/Link/

  81. Dave Cridland

    (I'm not even sure it is bad design - at best it's inconsistent with Disco)

  82. Kev

    stpeter: I'm not firmly in one camp or the other. I'd just like to see something approaching agreement.

  83. 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)

  84. 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

  85. Kev

    linuxwolf: No, that's not true.

  86. linuxwolf

    it's a schema change

  87. Dave Cridland

    linuxwolf, I don't see how you arrive at that conclusion.

  88. 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>

  89. stpeter

    not: <stream:features> <dialback xmlns='urn:xmpp:features:dialback'> <bidi/> </dialback> </stream:features>

  90. Kev

    linuxwolf: Adding more *the wrong way* later would lead to a schema change.

  91. stpeter

    although bidi is not strictly a dialback thing

  92. linuxwolf

    Kev: that's what I'm saying

  93. Kev

    I'm assuming if we add more features in the future, we'll do it right.

  94. linuxwolf

    So #1 is out

  95. Kev

    No.

  96. Kev

    We've done it the wrong way once, they question is whether to live with it or not.

  97. 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.

  98. linuxwolf

    ok, then my vote is to not live with it

  99. Dave Cridland

    I'd be fine with <errors/> being the last thing added to dialback's stream feature.

  100. linuxwolf

    but, IMO, we have time to change this

  101. MattJ

    So is mine, but only if we can track down existing implementations (I'm not sure there are many in reality)

  102. linuxwolf

    I'm −1 on keeping it, unless there's a plethora of implementation that will break

  103. Kev

    My preference is that we should only break namespaces when there's an incompatible change being made, really.

  104. linuxwolf

    then I'll re-evaluate (-:

  105. ralphm

    we /could/ define a real stream feature and deprecate <errors/> but I'm unsure about the actual impact

  106. Dave Cridland

    ralphm, Same issue.

  107. ralphm

    of course

  108. MattJ

    Dave Cridland, are you saying you're absolutely against switching to a <dialback-errors> feature?

  109. 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)

  110. linuxwolf

    we're still advertising support of dialback (sans error-handling) via a namespace declaration, no?

  111. Kev

    I am, in any case, -1 on advancing 220 as it currently stands, so this discussion can take place on list :)

  112. stpeter

    linuxwolf: no

  113. MattJ

    stpeter, I agree it seems bad to have backwards-compatibility cruft in such a "recent" feature

  114. stpeter

    linuxwolf: advertisment is just via namespace on the stream header

  115. Kev

    (Which, given that we've not changed 0001 yet means that -0220 has just died. Yay!).

  116. ralphm

    so discussion ensues and we -1 it for now

  117. ralphm

    Kev: hehehe

  118. Kev

    4) XEP-0262 (Use of ZRTP in Jingle RTP Sessions), advance to Draft?

  119. ralphm

  120. Dave Cridland

    MattJ, I am generally against changing deployed specs incompatibly for aesthetic reasons, yes.

  121. 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

  122. stpeter

    I'd be fine with that

  123. linuxwolf

    stpeter: I would be ok with that

  124. ralphm

    stpeter: and if you don't actually do it it doesn't break stuff

  125. stpeter

    ralphm: right

  126. ralphm

    and the <errors/> is merely informational no-op

  127. Dave Cridland

    stpeter, I've a nagging feeling that there exist implementation advertising dialback like that but without supporting errors.

  128. MattJ

    Is it?

  129. ralphm

    that'd work for me

  130. Kev

    Folks, this discussion doesn't need to happen now.

  131. ralphm

    right

  132. Kev

    Can we move onto (4) please.

  133. stpeter

    Dave Cridland: I don't know of any implementations that do it that way

  134. linuxwolf

    ok, let's focus!

  135. linuxwolf

    #4

  136. stpeter

    Kev: trying to use the high bandwidth connection to reach consensus :)

  137. stpeter

    bt I'll propose it on the list

  138. Kev

    Discuss in 10mins once Council's over and I can start ignoring the chat :)

  139. Kev

    4) XEP-0262 (Use of ZRTP in Jingle RTP Sessions), advance to Draft?

  140. Kev

    I haven't looked up the feedback thread yet. Will vote on-list.

  141. linuxwolf

    was there feedback? I don't remember seeing any

  142. MattJ

    There wasn't feedback iirc

  143. Kev

    I don't remember any, but I need to find the thread to be sure :)

  144. stpeter

    heh

  145. MattJ

    No feedback and I'm not aware of any implementations

  146. stpeter

    it is implemented in Jitsi

  147. MattJ

    Ah good

  148. Kev

    One reply, from Peter, saying that the date was wrong.

  149. stpeter

    for voice and video

  150. linuxwolf

    stpeter: can you ping them to send an "a ok" or something about it, then?

  151. stpeter

    I've seen it displayed at FOSDEM so it must be true

  152. Fritzy

    well, that's something!

  153. Fritzy

    Should we ask them for feedback specifically?

  154. Kev

    If there are known implementations, and no feedback to the LC, I think it's worth poking, yes.

  155. MattJ

    +1

  156. linuxwolf

    definitely

  157. Dave Cridland

    Is Jitsi SIP Communicator as-was?

  158. stpeter

    Kev: pokage in progress

  159. ralphm

    +1

  160. MattJ

    (to poking)

  161. MattJ

    Dave Cridland, yes

  162. Kev

    Dave Cridland: Yes.

  163. linuxwolf

    +1 to POKE, DNV for now

  164. Dave Cridland

    Anyone else want to say yes?

  165. MattJ

    Dave Cridland, no

  166. Kev

    Dave Cridland: No.

  167. Kev

    Ok, so who's volunteering to poke them for feedback?

  168. MattJ

    I just have

  169. Kev

    Ta.

  170. linuxwolf

    thanks

  171. Kev

    5) Date of next.

  172. MattJ

    Next week is ok for me as far as I am aware

  173. Kev

    Jolly good.

  174. Fritzy

    same here

  175. linuxwolf

    works for me

  176. Kev

    ralphm?

  177. stpeter

    any further votes on 178?

  178. ralphm

    +1

  179. Kev

    I think the voting period's expired for that hasn't it? :)

  180. Fritzy

    very much so

  181. Kev

    6) AOB.

  182. linuxwolf

    +1 on −178

  183. linuxwolf

    thought I did that on-list

  184. ralphm

    any news on the summit?

  185. Kev

    ralphm: I think I saw a mail fly by saying it was cancelled.

  186. stpeter

    linuxwolf: I missed that

  187. linuxwolf

    but I'm getting ~200 emails/day, so it's getting lost (-:

  188. Kev

    Although I don't think I was paying much attention at the time.

  189. stpeter

    linuxwolf: man up :P

  190. stpeter

    right, we haven't organized the summer summit so we'll see you all in Brussels again someday

  191. MattJ

    Yay

  192. stpeter

    so meeting next Wed?

  193. Kev

    Yep.

  194. stpeter

    adding to calendar

  195. Kev

    And we're done with 3mins to spare.

  196. Kev

    Thanks Peter.

  197. Kev

    Thanks all.

  198. linuxwolf

    and now to the flame war

  199. Kev bangs teh gavel.

  200. MattJ

    Heh

  201. stpeter

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

  202. MattJ

    stpeter, where is that?

  203. stpeter

    xmpp@ietf.org

  204. ralphm

    the precis draft

  205. stpeter

    or http://xmpp.org/2011/05/progress-on-internationalization/

  206. MattJ

    Ah yes, thanks

  207. linuxwolf

    stpeter: on my /todo

  208. MattJ

    On mine too

  209. linuxwolf plans on reading it while at Casa Bonita

  210. stpeter

    thank

  211. stpeter

    thanks even

  212. Fritzy

    ciao

  213. stpeter

    we can see that Ralph likes Unicode ;-)

  214. stpeter

    Unicode Rocks™ and all that

  215. linuxwolf

    Ralphm: what happened to "if you don't like ASCII…f**k you"? (-:

  216. stpeter

    heh

  217. ralphm

    linuxwolf: did I ever say that?

  218. ralphm

    linuxwolf: also, I don't see how that's conflicting with liking unicode

  219. stpeter

    ralphm is a man of contradictions :)

  220. linuxwolf

    haha

  221. stpeter updates http://xmpp.org/about-xmpp/xsf/xmpp-council/tenth-council/ with linuxwolf's vote

  222. ralphm

    stpeter: pft! Al

  223. linuxwolf

    ralphm: well, I said the first part…and beers were involved (-:

  224. ralphm

    linuxwolf: agreed

  225. MattJ

    stpeter, hmm, my vote isn't there... I'm +1

  226. stpeter

    ok

  227. MattJ

    But I'm working more on Prosody's implementation soon so I may have some feedback

  228. ralphm

    as ASCII is a strict subset of unicode, I don't see how this is a contradication

  229. stpeter

    not sure if Fritzy voted

  230. MattJ

    ralphm, you win :)

  231. linuxwolf

    ASCII is a strict subset of UTF8, actually

  232. linuxwolf

    (-:

  233. stpeter

    I think I missed a meeting while travelling of late

  234. ralphm

    linuxwolf: hehe

  235. linuxwolf

    and UTF8 is a particular encoding of Unicode, afterall (-:

  236. ralphm

    nevertheless a thing to like

  237. linuxwolf

    I've got a slidedeck I can show you about it (-:

  238. linuxwolf

    stpeter: I don't think my vote on 0220 is accurate

  239. linuxwolf

    given the revote and updates and whatnot

  240. Kev

    Indeed. I'm currently -1.

  241. stpeter pings Fritzy about 178

  242. stpeter

    Kev: noted

  243. stpeter

    heh, now I'm receiving password requests for chat.facebook.com at jabber.org

  244. linuxwolf

    stpeter: I'm "" on XEP-0220 right now, pending further discussion about advertisement

  245. linuxwolf

    ugh

  246. linuxwolf

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

  247. linuxwolf

    adios

  248. stpeter

    linuxwolf: noted

  249. stpeter

    I changed ralphm to "" as well

  250. stpeter

    so the only vote is Kev's -1 :)

  251. Kev

    Which I'll no doubt be changing shortly.

  252. Dave Cridland

    stpeter, ralphm may well be “”, in fact.

  253. stpeter

    heh

  254. ralphm

  255. stpeter

    :)

  256. Dave Cridland

  257. Dave Cridland

    I tried a bottom bracket with combining umlaut once, and it actually worked. I was particularly happy.

  258. ralphm

    ̈̈̈̈‿̈

  259. ralphm

    ooh

  260. Dave Cridland

    Unicode Art is so much more experssive than the ASCII kind.

  261. ralphm

    ‿̈

  262. ralphm

    I had another combining one in there

  263. Dave Cridland

    There's actually a smile codepoint that might be better.

  264. ralphm

    ⁀̤

  265. ralphm

    ̤⁀⃘̤

  266. Dave Cridland

    ◡̈

  267. Dave Cridland

    Many options.

  268. ralphm

    I just tried a combination that kicked out my connection

  269. ralphm

    with combining musical symbols

  270. ralphm

    probably because they are in another plane

  271. Dave Cridland

    Could be anti-codepoints.

  272. Dave Cridland

    You can't put those in contact with ordinary codepoints, they'll explode.

  273. ralphm

    I had a cross-note-head with a combining 1/64 stem

  274. Dave Cridland

    Yeah, you need to have a special screwdriver for those, though.