XMPP Council - 2013-09-25

  1. Tobias

    are there any outstanding votes from me?

  2. Kev

    Not for another 2 minutes :)

  3. Tobias


  4. m&m


  5. Tobias


  6. Tobias

    the witch is dead

  7. m&m

    the witch is dead

  8. m&m


  9. Kev

    Which old witch?

  10. Kev

    1) Roll call!

  11. MattJ


  12. m&m


  13. Tobias


  14. Kev

    Le Ralph?

  15. ralphm


  16. Kev


  17. m&m


  18. Kev

    2) http://xmpp.org/extensions/xep-0297.html Advance to Draft?

  19. Kanchil

    Kev: http://xmpp.org/extensions/xep-0297.html: XEP-0297: Stanza Forwarding

  20. m&m

    +1 from me

  21. MattJ


  22. Tobias


  23. ralphm


  24. Kev

    I'll double check before sending +1 to list.

  25. Kev

    I think that was the only voting action this week.

  26. Kev

    So unless I missed one...

  27. Kev

    3) Date of next meeting

  28. m&m


  29. Tobias


  30. Kev


  31. MattJ


  32. ralphm


  33. Kev


  34. Kev


  35. Kev

    4) AOB.

  36. MattJ

    Yes, my outstanding votes need recording :)

  37. m&m

    I notice the Board and Council nominees are thin

  38. Tobias

    do we already have a new version of RTT to read/vote on or will a last call be reissued?

  39. MattJ

    I'm +1 on 220 and 288

  40. Kev

    The 301 authors have submitted another version to Peter to address m&m's comments, although not my last remaining comment (which I first raised ages ago).

  41. Kev

    Tobias: Was already typing :)

  42. Kev

    FWIW, my remaining comment (which didn't go to list because I was replying to a mail they didn't send to list, accidentally) was:

  43. Kev

    I'm sorry for being a nuisance yet again, but I have one remaining nit. At the end of 6.1 you have the ...MAY implicitly request... e.g. when...invisible/offline. Can you tighten this up just slightly to be clear that implicit discovery is only allowed when normal discovery isn't possible? I suggest this tweak: "While explicit discovery is strongly RECOMMENDED (see Determining Support), the sender client MAY implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation" -> "While explicit discovery is REQUIRED (see Determining Support) where possible, it is not possible to use explicit discovery when the sender does not share a presence subscription with the the contact and knows only their bare JID (e.g. they have yet to receive stanzas from the contact). In this case, the sender client MAY implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation" I think this keeps your ability to discover implicitly when explicit discovery isn't possible, but maintains that in all other cases you need to do explicit discovery.

  44. ralphm

    I'm +1 on 220 and 228 as well

  45. Kev

    I feel fairly strongly that we shouldn't be introducing another pseudo-discovery mess like 85 here. (85 became a mess because 115 didn't exist when it was published, and we needed to maintain backwards compatibility).

  46. m&m

    115 and decloaking

  47. ralphm

    Kev: this came up before, and I agree

  48. Kev

    Having worked on a couple of 85 implementations I don't think that confusion is helpful.

  49. Tobias

    i think discovery should be used where possible...if they don't want expensive discos they can ship their clients with precalculated caps databases

  50. MattJ

    Makes sense to me

  51. Kev

    ralphm: It did, but the authors didn't really address it last time (and haven't this time), claiming they need to be compatible with -85.

  52. Kev

    m&m: I thought about saying they should be using decloaking, but I can also see the argument that decloaking hasn't actually gone anywhere.

  53. ralphm

    How is that even an issue? Clients that implement XEP-0085 will, eh, implement XEP-0085.

  54. Kev

    ralphm: Right, I don't think my proposed text means there's ever a case where you could do -85 but couldn't do -301.

  55. Kev

    I'd like to keep blocking until this is addressed, so I'm presenting it here so the rest of Council can talk me down if they disagree with me.

  56. Kev

    But it doesn't seem like they do :)

  57. Zash

    So, 280 (and 313) could move forward now? (If Kev +1es)

  58. ralphm

    Kev: I support your -1.

  59. m&m

    Zash: in theory

  60. m&m

    Kev: hold the line

  61. Kev

    Zash: I think they can go to LC, if the authors request it, yes.

  62. Kev

    ralphm / m&m: Ta.

  63. MattJ

    313 isn't quite ready yet, I have a new version I need to push

  64. Kev

    OK. I note Ralph and Matt's votes from earlier, will minute.

  65. MattJ

    But then it'll be ready

  66. ralphm

    Kev: that kind of moves this to 'Rejected', right?

  67. Kev

    Anything else for AOB?

  68. Tobias

    could we have the votes on our votes page?

  69. m&m

    I notice the Board and Council nominee list is thin

  70. Kev

    ralphm: If we're following the letter of XEP-0001 (which we never do), it would, yes. But I'm happy with the usual "We'll just keep it in Proposed until all feedback is addressed".

  71. Kev

    ralphm: What are your thoughts?

  72. MattJ

    Does XEP-0001 need updating to reflect this process then?

  73. ralphm

    Kev: practically, how could a spec ever move to rejected?

  74. Kev

    m&m: Yes, seems so. I'll apply to Council again. I'm aware of people being poked for Board behind the scenes.

  75. Tobias

    referring to this page http://xmpp.org/about-xmpp/xsf/xmpp-council/twelfth-council/

  76. Kanchil

    Tobias: http://xmpp.org/about-xmpp/xsf/xmpp-council/twelfth-council/: Twelfth Council &#8211; The XMPP Standards Foundation

  77. Kev

    ralphm: Only if we decided during LC that it wasn't ever going to be appropriate to move to Draft, I think.

  78. ralphm


  79. Kev

    Tobias: I think Peter usually maintains that page. I'm sure he'd appreciate a volunteer, if you are :)

  80. Tobias

    sure...but i have no clue who voted what :)

  81. Kev

    MattJ: I think probably updating XEP-0001 to match reality is desirable. Although given the imminent departure of Board, it might be best to wait for next term.

  82. Kev

    Tobias: The minutes :)

  83. Zash

    m&m: Know of any issues with 280?

  84. Kev

    Tobias: If you want to take this on, I'd suggest poking Peter.

  85. ralphm

    I was planning on running for Council

  86. MattJ

    Zash, m&m: might hate me for this, but it doesn't use hints

  87. stpeter

    (sorry, I got delayed and I'm also on a conference call)

  88. ralphm

    hey stpeter

  89. Kev

    Hi Peter.

  90. m&m

    Zash: I think fippo and cridland (in a previous life) worked out most of the technical hurdles, and the latest draft reflects this

  91. m&m

    I can live without hints (-:

  92. Kev

    I'm not sure where we are meeting-wise, now. I think we've dealt with all official business and can close?

  93. Tobias

    we're at AOB

  94. Kev

    AOB was the last item, yes.

  95. Kev

    It's not clear that we're actually still in it :)

  96. m&m

    so, if you're going to run, get your page up!

  97. Kev

    m&m: Done.

  98. Kev

    Although I should update it to not be a copy of the last eight years :)

  99. m&m jots a note to pester Lance about putting up an actual page

  100. Kev

    OK, I think we're done with AOB and are just chatting here?

  101. m&m

    Kev: you could go the bot route (-:

  102. m&m


  103. Kev

    So, last call for AOB :)

  104. MattJ

    m&m, I heard you may not be in Portland... say it ain't so

  105. m&m

    I will not be in Portland )-:

  106. m&m

    not physically

  107. ralphm

    I'd like to chat a bit about Porland, outside this meeting

  108. m&m

    if there's a remote option, I'll join that

  109. Kev

    OK, let's close up then.

  110. Kev

    Thanks all!

  111. Kev bangs the gavel.

  112. ralphm


  113. ralphm

    So, Summit #14

  114. Tobias


  115. ralphm

    There's been some talk, the number of people signing up is rather low.

  116. ralphm

    Still, I do think it is worth it to meet up.

  117. Kev

    Yeah, I'm afraid we don't really have the cycles to lose anyone for a week at the moment, else I'd be inclined to attend.

  118. ralphm

    Not all talk with a large group like usual, but at least partially do some actual work.

  119. Zash

    m&m: Didn't someone mention that 280 + MUC was an issue? And using hints instead of the 280-only <private> would be nice.

  120. m&m

    Zash: I'm a moron … I see 280 and thought 288

  121. m&m

    I need to go back over 280

  122. m&m

    MUC private messages can be an issue

  123. Zash

    For MAM too

  124. m&m

    Why is the server applying carbons to things that don't come immediately from an active endpoint?

  125. ralphm

    (Summit) For example, our web site needs love, spec pages, splitting up XEP-0060. Maybe something like tutorials for publish-subscribe and other topics.

  126. Kev

    ralphm: On the pubsub topic, did you see Remko's blog post? I thought that was pretty neat.

  127. Kev

    Oh, damn, there was something I wanted to discuss in AOB. Nevermind, can do it out of band.

  128. stpeter is deep in explanations of XMPP and is not paying attention here

  129. m&m


  130. ralphm

    Kev: yeah, stuff like that is great.

  131. Kev

    stpeter: Feel free to report back once you know about it :D

  132. ralphm

    Kev: I was looking at http://www.rabbitmq.com/getstarted.html

  133. Kanchil

    ralphm: http://www.rabbitmq.com/getstarted.html: RabbitMQ - Getting started with RabbitMQ

  134. ralphm

    Kev: and also, I am sensing that we should have an offering for people using XMPP as part of their application, without starting out with a full-fledged XMPP server.

  135. Zash

    m&m: Hm? A PM from a remote MUC looks exactly like a chat message from a s2s connection.

  136. ralphm

    Kev: of course the existing software to support this use case is lacking, so maybe we should try come up with what's needed for something like that

  137. Kev

    ralphm: Hmm. I'm not sure what the value of only having part of a server is. Or did I misunderstand?

  138. ralphm

    Kev: use case is something like Facebook. They started out with ejabberd, needed to replace most of the guts of the thing (like the session manager) and finally started rebuilding it from scratch.

  139. ralphm

    Kev: I did this for just publish-subscribe at Mediamatic

  140. m&m goes back to his day job

  141. ralphm

    Kev: and I am sure that many people trying to use XMPP as part of their application get stuck on this

  142. m&m

    Zash: I'm not understanding your terseness then

  143. m&m really does go back to his day job now

  144. Kev

    Facebook is a somewhat special case, because they were mapping an existing IM implementation onto XMPP at the boundary, most people don't have large internal IM systems. So the Mediamatic case is probably more interesting.

  145. Kev

    So, in what way was what you did there different to e.g. running up M-Link* and only using the pubsub bits.

  146. Kev

    [* Replace with server of choice]

  147. stpeter

    heh, the topic of XMPP compliance testing has arisen on this conference call :-)

  148. ralphm

    Kev: actually, I have exposed a model of a publish-subscribe node as an internal API, not unlike what web frameworks do for building web sites

  149. ralphm

    Kev: and then used that to glue it on top of the (HTTP API) of the website

  150. Kev

    I don't think this is the ideal medium for discussing this, sadly. What you describe sounds naively like putting a relevant API over the top of XMPP, rather than needing to cut bits out of servers.

  151. ralphm

    Kev: it also uses the s2s implementation in Wokkel, but you could also run it as a server-side component and have a (bare) server do that part.

  152. ralphm

    Kev: that might be true.

  153. Kev

    I guess one option would be to register xmppformiddleware.com, and do much like the RabbitMQ thing, with how to do basic stuff in different languages. I would suggest that doing this through the XSF would result in too much need for fairness. e.g. if I was working on it, I'd pick Swiften for C++, and ignore Gloox, Stroke for Java and ignore Smack, etc.

  154. Kev

    I think it would be very unhelpful to have 37 different 'how to do it in Python' examples, for each of the libraries.

  155. ralphm

    Kev: oh, it doesn't really need to be an XSF thing at all

  156. Kev

    But I think it'd be a really interesting project to do outside the XSF.

  157. ralphm

    Kev: but a nice topic for the Summit

  158. Kev

    And I'd be willing and/or keen to work on such things with people (but not alone).

  159. ralphm

    Kev: also, make sure that you block out Summit #15 (Brussels) in your agenda. :-D

  160. Kev


  161. ralphm

    (and those of your minions)

  162. Kev

    Haha. I have no minions, sadly. We're all Kurt's minions.

  163. ralphm

    Kev: all Kurt's minions then. Whatever makes you guys show up.

  164. Kev

    Do we have days for the summit yet?

  165. ralphm

    Kev: not yet

  166. Kev


  167. ralphm

    I do know there is http://cfgmgmtcamp.eu on Monday and Tuesday. Not sure if that's a problem.

  168. Kanchil

    ralphm: http://cfgmgmtcamp.eu: Config Management Camp 2014, Gent

  169. m&m

    I thought the rough consensus was to do the summit before, not after?

  170. m&m

    because people are worn out after FOSDEM (-:

  171. ralphm


  172. ralphm

    30/31 seems fine to me

  173. Kev

    m&m: And because they can head home on the Sunday of FOSDEM, cutting a day off the trip :)

  174. ralphm

    Kev: well yeah, *those* people

  175. Kev

    I see the Sunday of FOSDEM as being by far the least productive of the four days, personally.

  176. m&m

    You mean the LOSERS! (-:

  177. m&m

    and miss out on a prime opportunity for more beer

  178. stpeter

    yay, finished with my conf call

  179. Kev

    m&m: I'm aware my desire to be at home is much stronger than most people's (and my desire for beer much less strong), yes.

  180. ralphm

    Kev: it is what you make of it. I've done some productive stuff by grabbing one or two other people into a hacker room and then do some speccing, in previous years

  181. Kev

    I don't claim it can't be productive, but I find it all exhausting, and I'd rather concentrate my energy on the other days :)

  182. ralphm

    Kev: I say you need more training.

  183. Kev


  184. Kev

    stpeter: The remaining item that I forgot to put into AOB is how we're going to move Reachability forwards.

  185. Kev

    Or upwards, or whatever direction the process goes in.

  186. stpeter


  187. Kev pokes Emil again.

  188. stpeter

    is the meeting still going here or is this post-meeting chat?

  189. Kev

    Post-meeting chat.

  190. m&m

    it's the after-meeting

  191. stpeter


  192. Kev

    Good grief, do you think we've been going for 50 minutes? :)

  193. stpeter

    I doubted it!

  194. Kev

    Who are the people who're building things with the XEP, and how do we get them to confirm/deny that it's doing its job?

  195. stpeter

    I think I'll ping all the folks who provided feedback on the CUSAX spec

  196. Kev


  197. stpeter

    I might have a non-CUSAX use case, too

  198. stpeter pokes the developers he's been working with on the side

  199. Kev

    This feels like it should be part of a vcard spec, rather than independent, but I'm not going to be Mr. Unpopular and do anything because of that. The world is what it is.

  200. stpeter

    sometimes you have more dynamic information that would not go into your vCard

  201. stpeter

    e.g., you walk into a conference room and based on near-field communication or simple old reading you discover the 'tel:' or 'sip:' URI for a video endpoint

  202. Kev

    Marvellous, I feel better about it now, thanks.

  203. stpeter

    once you walk out of the room, you don't want to update your vCard

  204. Kev

    I hadn't quite clicked it was an as-you-walk thing, when it talked about moving buildings.

  205. Kev

    Yeah, that makes sense.

  206. stpeter

    but I am not sure that people are building this into products yet, although I wish they would!

  207. stpeter

    ideally that stuff would be automated

  208. stpeter

    so I walk into a conference room and my XMPP client can push my temporary contact location to you

  209. Kev

    All makes sense, ta.

  210. stpeter

    if I have a more stable contact address (e.g., my configured SIP URI) then yes, that makes sense to put in my vCard for sure

  211. stpeter

    if that's not clear then it needs to be

  212. Zash

    Multiple vCards or vCard items in their own PEP nodes?

  213. stpeter

    Zash: why would I want to have multiple vCards? sounds confusing...

  214. stpeter curses at his inbox

  215. Kev

    stpeter: I'd suggest putting (e.g. changing their addresses as they walk from one room to another) to the bit in section 2 about dynamicness.

  216. stpeter

    Kev: yes

  217. ralphm

    stpeter: Persona. E.g. I have multiple google plus accounts (personal and company)

  218. Zash

    stpeter: Simplified access control, namespace/spec reuse, separation based on TTL

  219. Kev

    Spell it out for stupid people like me :)

  220. ralphm

    Zash: you arguably don't need multiple items for restricted access

  221. ralphm

    (you can serve up different content)

  222. Zash

    ralphm: Do we have anything for only sharing parts of vCards based on who's receiving it?

  223. Zash

    The OneSocialWeb people were working on something to address that, but I don't think it ever got submitted

  224. stpeter

    ralphm: BTW the folks I was chatting with earlier are going to use pubsub for most of their use cases

  225. ralphm

    Zash: you don't need additional protocol for the subscribing/retrieval part

  226. ralphm

    stpeter: cool

  227. Zash

    ralphm, but things like not giving out my private phone numbers to people not in my contact list or limiting it to a specific roster group

  228. ralphm

    Zash: you could do this as part of the implementation. Depending who asks, subscribes, you give a different view on the same data.

  229. Kev

    ralphm: We have no way of defining that though, I think.

  230. ralphm

    Zash: you might want to specify how to make a service do that.

  231. Kev

    So you could patch your server to do these things, but it's specific to your deployment.

  232. ralphm

    Zash: like with node configs

  233. Zash

    ralphm: Yeah

  234. ralphm

    my point was that you don't need additional protocol, per se

  235. ralphm

    My steak is calling. Back in a bit.

  236. Kev

    Mmmm. Steak.

  237. stpeter


  238. stpeter

    at some point I'll need to scroll up and see what all the discussion was about, but first I'm trying to finalize some summit details

  239. stpeter

    hmm, last year we spent quite a bit on room / catering at the Summit, I'm sure I can get that down a bit this time

  240. Tobias

    at both meetings?

  241. stpeter

    no, just in Portland

  242. Tobias


  243. stpeter

    the meeting rooms are free for me at the Cisco office in Diegem ;-)

  244. Tobias

    stpeter, maybe cisco also runs a catering business which needs to produce profits :D

  245. stpeter


  246. stpeter

    pizza boxes? ;-)

  247. Kev

    Mmmmm, pizza.