XMPP Council - 2010-08-16

  1. mlundblad

    is there a meeting today?

  2. stpeter

    as I understand it, yes

  3. stpeter

    and hi :)

  4. mlundblad

    hi :)

  5. mlundblad

    Olivier CrĂȘte spoke about someone formalising the psuedo-udp ft stuff from google as a "standard" jingle spec. is this in the XSF's inbox?

  6. stpeter

    not in the inbox yet

  7. stpeter


  8. mlundblad

    I have somewhat mixed feelings about that...

  9. stpeter

    there is http://xmpp.org/extensions/inbox/jingle-httpft.html

  10. mlundblad


  11. mlundblad

    I was under the impression that this would meerly be a jingle transport spec.

  12. stpeter


  13. mlundblad

    not sure, though...

  14. stpeter

    that one

  15. stpeter

    yeah, there's been talk about documenting that, but no action

  16. mlundblad

    maybe I'm slanting towards thinking that might be a good idea, compared to ice-tcp

  17. mlundblad

    but maybe not...

  18. stpeter

    the http-over-pseudo-tcp-over-udp stuff is kind of crazy, but that doesn't mean it's bad :)

  19. mlundblad

    I think maybe the http stuff is overkill, though

  20. mlundblad

    another crazy thing though, psuedo-tcp-over-udp-over-a-tcp-relayed-turn-candidate...

  21. mlundblad


  22. stpeter


  23. ralphm


  24. Kev

    Evening Ralph.

  25. stpeter


  26. stpeter


  27. ralphm

    warming up my foods

  28. stpeter

    me too :)

  29. Kev

    Right, Hello meetingtime

  30. ralphm


  31. Kev

    Matt and Remko are both online, just getting them to join.

  32. stpeter

    gosh I love these people who go on vacation for a month -- how is that possible?

  33. Kev

    Sounds nice doesn't it? :)

  34. ralphm

    stpeter: come live in europe

  35. stpeter

    I did take a two-week vacation back in 1994, that was quite relaxing :P

  36. Kev


  37. Kev


  38. Kev

    Stop. Meeting time.

  39. Kev

    1) Roll call.

  40. Kev

    Fritzy, Kev, MattJ, ralphm, remko.

  41. ralphm goes dmm, dm, dm, dm

  42. Kev

    2) Agenda bashing anyone?

  43. MattJ

    Not here

  44. remko


  45. Kev

    Ok then.

  46. Kev

    3) ProtoXEP - XMPP on Mobile Devices http://www.xmpp.org/extensions/inbox/mobile.html Accept as Experimental?

  47. ralphm

    yes, interesting matter

  48. remko


  49. Kev

    I'm not objecting.

  50. Kev

    Fritzy / Matt?

  51. Kev

    Commenting on list's fine if you've not read it.

  52. MattJ

    No objection here, I'm glad someone finally wrote it up :)

  53. stpeter

    yep, that looks helpful

  54. stpeter

    plus I love it when someone other than me writes specs :)

  55. MattJ


  56. Kev

    stpeter: Well, Matt and I have a big stack waiting for limelight :)

  57. ralphm

    MattJ: how's that my-client-doesn't-support-SIFT-but-I-still-want-it feature?

  58. MattJ

    ralphm, which was that?

  59. MattJ

    or you mean the intelligent presence buffering?

  60. ralphm

    yeah, but such that I can tell my server to do it for a particular resource. Like 'Maemo'

  61. MattJ

    or a given disco identity? :)

  62. ralphm


  63. Kev

    Ok, I think Fritzy's gone AFK, so moving on.

  64. Kev

    4) ProtoXEP - Digital Signatures in XMPP http://www.xmpp.org/extensions/inbox/dsig.html Accept as Experimental?

  65. ralphm

    +1, I'm curious about the TBDs

  66. remko

    no objection

  67. Kev

    Heh, you like it more than I do.

  68. MattJ

    Why is it necessary to encode the contents like that?

  69. Kev

    I'm not convinced about signed messages being illegible to non-signing clients - i.e. you could never send signed messages to a MUC.

  70. MattJ

    Even e2e had some normalization routines, presumably for the same reasons

  71. stpeter

    I wonder if anyone will sign their XMPP stanzas, given that precious few seem to sign their email messages and that technology has been around for a long time

  72. Kev

    stpeter: Well, in email I can still read your mails.

  73. Kev

    Even though I don't process and verify the signatures.

  74. ralphm

    MattJ: from what I've been told, normalization like in XMLSig is quite horrible

  75. Kev

    That's not true here.

  76. remko

    kev: indeed

  77. remko

    kev: that doesn't really sound very good

  78. stpeter nods

  79. remko

    it's probably a workaround for the whitespace etc.

  80. remko

    but still, there shoudl be a better one

  81. MattJ

    ralphm, e2e did seem to manage, minus one case in the XEP that suggested stripping whitespace in a given instance was enough normalization

  82. Kev

    Well, I quite like the copy-and-sign approach, where you encode, like this, what you signed so it's there for verifying clients, and other clients get it in plaintext.

  83. Kev

    But I'm not winning this argument with Kurt, so I'm abstaining on this non-vote.

  84. stpeter

    IMHO it's early days for signing

  85. stpeter

    heck, it's still early days for encryption!

  86. remko

    stpeter: true

  87. Kev

    So, where are we?

  88. ralphm

    Well, I'm ok with it being a XEP, not necessarily thinking this is the best approach.

  89. Kev

    Remko and Ralph are +1, Matt was ...?

  90. Kev

    and Fritzy's AFK :)

  91. MattJ

    +1 to publishing

  92. Kev

    That actually raises an interesting question - if a Council member is in the room, but AFK, for a meeting, does that count as present?

  93. MattJ

    But I 1) think it needs some discussion going forward 2) don't think it's going to see implementations like this

  94. remko

    i agree with matt

  95. stpeter

    if a tree falls in the forest...

  96. ralphm

    Kev: does that actually matter?

  97. stpeter nods to MattJ

  98. Kev

    ralphm: Well, stats are kept on people's voting and attendance history, so people can do sensible things with voting in Sept/Oct.

  99. Kev

    Whether people use them is another matter, but they're there.

  100. Kev


  101. MattJ

    I could easily leave my client idle here 24/7 then :)

  102. Kev

    MattJ: Right.

  103. Kev

    5) Winding down Council. Anything we want/need to do before the end of term?

  104. Kev

    Peter'd like us to get some file transfer headway made.

  105. MattJ

    I've nothing to say that we didn't discuss on list

  106. MattJ

    Archiving, etc.

  107. Kev

    Yes, well, I'm happy to push my specs out if you are yours :)

  108. ralphm

    file transfer would be nice indeed

  109. MattJ

    FWIW I have some comments on Jingle (it's a pain to implement)

  110. ralphm

    MattJ: in general?

  111. stpeter

    Kev: well, given that I promised to review the reviews of file transfer, I have action items I can take

  112. Kev

    stpeter: Jolly good, nothing for me to do yet, then.

  113. Kev

    7) Date of next meeting.

  114. Kev

    Next Monday, assuming we have things to discuss?

  115. ralphm


  116. stpeter


  117. MattJ

    ralphm, well I'm implementing Jingle File Transfer, the main Jingle spec defines a lot of things vaguely that aren't followed up on in JFT

  118. remko


  119. Kev

    8) Any other business?

  120. MattJ

    The spec was clearly split into signalling/RTP at some point, the split wasn't quite right IMHO

  121. stpeter

    MattJ: "the spec" = 166?

  122. ralphm

    MattJ: ah, so the specs are unclear? Not necessarily bad?

  123. MattJ

    stpeter, yes

  124. MattJ

    ralphm, I think (hope) mostly just unclear

  125. stpeter

    Kev: Council members need to decide if they are going to stand for consideration again, I suppose

  126. MattJ

    For example...

  127. MattJ


  128. MattJ

    This section has no protocol description at all

  129. Kev

    stpeter: I'll be seeing if there are enough sensible candidates other than me, and deciding then.

  130. MattJ

    Yet negotiation is surely the most significant part of Jingle :)

  131. stpeter

    MattJ: heh

  132. Kev

    I do think I've been on Council a while, and people should step down after that long if there are sensible replacements.

  133. stpeter

    MattJ: in general, I think we've been defining Jingle via examples such as XEP-0167

  134. Kev

    Ok, I'm taking this as no more other more business.

  135. MattJ

    Kev, turning that around... isn't that up to the members to decide?

  136. stpeter

    MattJ: I "discovered" some things about Jingle by writing the file transfer specs

  137. remko

    i'm steppnig down, because of lack of time to focus appropriately

  138. MattJ

    stpeter, as one of the few developers that doesn't develop implementations purely by reading examples, that's awkward :)

  139. Kev

    MattJ: possibly.

  140. Kev

    Right, I'll write up some minutes, probably tomorrow.

  141. Kev

    Thanks all.

  142. MattJ

    Thanks Kev

  143. Kev bangs the gavel.

  144. ralphm

    MattJ: hehe. Maybe you can provide some examples to be added to the spec?

  145. stpeter

    MattJ: by examples I meant "RTP is one example of how we'd use Jingle, but file transfer is another example / use case"

  146. MattJ

    ralphm, I wish I could, but I literally have no idea what that part of the protocol is meant to be like

  147. stpeter

    MattJ: the same is true on the transport side (UDP, TCP, etc.)

  148. ralphm

    MattJ: I actually think this part is intentionally vague

  149. MattJ

    166 describes all these commands, content-add, content-replace, etc... without saying how to use them or what they mean

  150. MattJ

    Ok, if it's intentionally vague then it should say so

  151. stpeter

    it is intentionally vague, but as we have more applications we could strengthen the core spec

  152. MattJ

    and the file transfer XEP should explicitly say what each command means

  153. MattJ

    But it doesn't

  154. MattJ

    Meaning at the moment I am basically implementing by 1) example 2) interop with Gajim's new code

  155. mlundblad

    two-week vacation?

  156. mlundblad

    I had a short vacation this year, only four weeks :D

  157. ralphm

    stpeter: for most of these things, doesn't the actual profile decide the protocol bits going in these actions?

  158. stpeter

    ralphm: yes

  159. stpeter

    ralphm: although I agree with Matthew that we could be clearer in 166

  160. stpeter

    mlundblad: :P

  161. ralphm

    stpeter: I'm unsure how to then make it more clear except by writing a fictional profil

  162. ralphm


  163. stpeter


  164. stpeter

    that's how I learned :)

  165. ralphm

    didn't we try that?

  166. stpeter

    it's like writing a novel, the characters take on a life of their own :)

  167. MattJ

    http://xmpp.org/extensions/xep-0234.html doesn't mention any of the Jingle commands

  168. ralphm

    XEP-0208, I think

  169. MattJ

    I take it back... it mentions transport-info

  170. MattJ

    and then links to an example that uses session-info

  171. stpeter

    ok those are all good points

  172. MattJ

    The box under example 1

  173. stpeter

    in part file transfer is much simpler than voice and video, so it has no need for many of the Jingle commands

  174. stpeter


  175. mlundblad


  176. stpeter

    I think it would be good to say that

  177. mlundblad

    but that is in s5b, I think

  178. stpeter

    Kev: do we have definitive feedback on the message threads XEP?

  179. MattJ

    stpeter, I agree... which is why I suggested the split in the XEPs was in the wrong place

  180. stpeter

    Kev: perhaps we need to chat about that and figure out what changes are needed

  181. Kev

    We've got feedback from Matt, does that count?

  182. ralphm

    sure it does

  183. Kev

    MattJ: You're the definitive voice of XMPP. Congratulations :)

  184. MattJ


  185. stpeter


  186. stpeter

    the other point about file transfer was that we want to get feedback from the GSoC implementers

  187. MattJ

    Now if only I could finish this overdue work so I can catch up with other spec reviews

  188. stpeter

    MattJ: yeah, understood

  189. stpeter

    oh and I have more XMPP WG feedback to address, too

  190. stpeter


  191. Kev

    stpeter: I'm happy to have a work through threads with you if you like, but not tonight.

  192. stpeter

    at least I'm adding acknowledgements so that all you helpful reviewers receive some credit

  193. Kev

    Ta muchly.

  194. Kev

    My name in lights :)

  195. stpeter

    Kev: sure, perhaps tomorrow or Wednesday or whatever

  196. Kev

    Right, AFK.

  197. stpeter

    Mondays can be crazy, I know :)

  198. Fritzy

    Mondays suck.

  199. stpeter


  200. stpeter

    MattJ: thanks for your helpful feedback -- I sense some revisions on the way

  201. MattJ

    You're welcome :)