XMPP Council - 2012-07-11

  1. m&m has left

  2. m&m has joined

  3. m&m has left

  4. Tobias has joined

  5. Tobias has left

  6. Tobias has joined

  7. Tobias has left

  8. Tobias has joined

  9. Tobias has left

  10. Tobias has joined

  11. m&m has joined

  12. stpeter has joined

  13. Kev

    T-12 or so.

  14. Tobias

    yup..anything on the agenda?

  15. Tobias

    didn't sound like it in your recent mail

  16. Kev

    Not formally, but it might be worth discussing XEP-specific discovery and negotiation methods.

  17. stpeter nods

  18. Tobias

    ah...the 301 fallback discussion?

  19. Tobias

    ah...the 301 disco fallback discussion?

  20. m&m


  21. m&m


  22. Tobias


  23. stpeter still thinks we need an XMPP extension called "hustle"

  24. m&m


  25. m&m

    not posh enough

  26. stpeter


  27. stpeter continues keying in his edits to XEP-0220

  28. m&m puts aside e2e, grabs more caffeine

  29. MattJ has joined

  30. Kev

    It is time.

  31. Kev pokes Ralph.

  32. Kev

    1) Roll call.

  33. Kev

    I'm here.

  34. m&m


  35. Tobias


  36. Kev


  37. MattJ


  38. stpeter wonders when he and fippo will complete work on XEP-0220 v0.13

  39. Kev

    Ralph responded, but I don't know that he has a machine capable of joining (I think he's on his phone).

  40. m&m

    stpeter: sometime after Hades actually freezes solid?

  41. m&m

    he's enjoying too much sourdough

  42. Kev


  43. Kev

    Assuming no-one has anything formal to discuss.

  44. Kev

    2) Date of next meeting.

  45. Kev

    As usual?

  46. m&m


  47. Tobias


  48. ralphm has joined

  49. m&m double-checks calendar

  50. ralphm has left

  51. stpeter thinks m&m will be busy

  52. m&m

    I will be busy

  53. Kev

    OK. Week after?

  54. m&m

    that should work

  55. Kev

    OK then.

  56. ralphm has joined

  57. stpeter

    I know, because I'll be busy too in the same meeting as m&m

  58. m&m


  59. Kev

    3) Any other business.

  60. Tobias

    that'd work too

  61. Kev

    ralphm: Welcome.

  62. ralphm


  63. Kev

    ralphm: :)

  64. ralphm

    +1 on LC 186

  65. Kev

    I have two things here - one is LC and Council, the other is designing spec-unique discovery.

  66. ralphm has left

  67. stpeter updates the calendar for a meeting on the 25th

  68. Kev


  69. Kev

    So, for whether it matters particularly that Council don't block an LC I have mixed feelings.

  70. Kev

    On the one hand, having it held up for a fortnight while Council vote on it may be a fortnight it doesn't need to be held up, and largely for the sake of it.

  71. m&m

    I'd rather have the XEP Editor issue LC at authors' or coucil's request

  72. Kev

    On the other hand, it's difficult getting LC feedback at the best of times - if we end up calling them multiple times on specs that aren't ready but the author thinks they are I'm worried it will reduce the quality or quantity of LC feedback we get.

  73. m&m

    then we can put our objections on the list

  74. Kev

    Whereas Council are pretty much guaranteed to at least check it's in a sensible state to LC.

  75. Tobias

    Kev, +1 on that

  76. m&m

    well, does it need to be the entire council that has to approve LC?

  77. ralphm has joined

  78. Tobias

    Last Call is for getting wider attention for a broader review

  79. m&m

    could it be a single council member

  80. ralphm

    bah crappy connection

  81. MattJ

    > [16:07:40] m&m: I'd rather have the XEP Editor issue LC at authors' or coucil's request

  82. Kev

    m&m: That probably works for me.

  83. MattJ

    I'm with this I think

  84. stpeter

    I don't have a strong preference, although holding it up for 2 weeks seems a bit silly -- I'd prefer if the majority of the Council can say yes or no in its meeting

  85. ralphm has left

  86. stpeter

    and not wait for two weeks

  87. Tobias

    MattJ, so each time an author request a LC the XEP Editor issues one?

  88. Kev

    I'd have thought just going with majority of Council present with no-one objecting would be fine.

  89. ralphm has joined

  90. stpeter

    poor Ralph :(

  91. ralphm has left

  92. m&m

    either would work for me … as long as it's not a fortnight hold on

  93. m&m

    up rather

  94. Kev

    The interesting side effect is that if the author requests an LC too early, and Council then doesn't advance it to Draft, it doesn't go back to Experimental, it gets Rejected, yay!

  95. Kev

    We should probably change that at some point.

  96. stpeter


  97. ralphm has joined

  98. Kev

    I'd be happy with just 'no objections at the next Council meeting'.

  99. ralphm

    +1 on lc by editor

  100. ralphm has left

  101. stpeter

    Kev: although I think the Council could say "you're too early, keep working on this and it will stay at Experimental for a while longer"

  102. Kev

    I don't feel /hugely/ opposed to it just being as soon as the author wants it, but I do have this concern on what it'll do to LC feedback.

  103. MattJ


  104. Kev

    stpeter: Well, that's what the pre-LC check does at the moment, but if we follow the rules to the letter once it's in LC it has to either go to Draft or Rejected. If I remember correctly.

  105. Kev

    Anyway, this is largely pointless and we wouldn't actually do this. Probably.

  106. m&m

    I think the XEP Editor can function as a reasonable wall against obvious flaws

  107. stpeter

    naturally, the XEP Editor might tell the author that they're too early and to keep polishing it further, gathering implementation feedback, etc. -- which I already do :)

  108. ralphm has joined

  109. Kev

    m&m: Ah, so it's not "XEP Editor does it at author's request" but "XEP Editor decides when".

  110. Kev

    Which is somewhat different, and probably fine.

  111. ralphm has left

  112. m&m

    yes … prompted by author or council, but yes

  113. Tobias

    stpeter, that'd work :)

  114. stpeter

    realistically I do interact with authors a bit on that point sometimes

  115. m&m


  116. stpeter

    in any case, I think the sanity check by the Council is fine, it puts the Council on notice too etc., I just think holding it up for another 2 weeks is a bit silly :)

  117. Kev

    OK, if we're saying that Peter will issue LCs and it's his responsibility to not issue them until the XEP's ready, that's OK with me, I think.

  118. m&m

    not St. Peter … the XEP Editor (-:

  119. ralphm has joined

  120. stpeter corrects an egregious instance of British spelling in XEP-0220 :P

  121. Kev

    Although it's not clear to me if the XEP Editor should have a stronger veto position than Council, which this effectively gives him.

  122. stpeter

    Kev: I think it's better for this to be the Council's responsibility, my only complaint was the two-week holdup

  123. Kev


  124. m&m

    I'm fine with that too

  125. Kev

    So, anyone got objections to a policy of "no objections at next meeting of Council", then?

  126. stpeter

    make it majority rules without veto in the meeting and off we go

  127. Kev

    It can't be a meeting without a majority anyway, so that seems OK to me.

  128. stpeter


  129. stpeter

    it's a quick sanity check, not a formal vote

  130. m&m

    as long as there's quorum, and the quorum does not object, it goes LC

  131. Kev

    Tobias / ralphm / MattJ?

  132. ralphm has left

  133. m&m

    works for me

  134. stpeter

    y'all have an opportunity for a formal vote anyway :)

  135. ralphm has joined

  136. m&m


  137. MattJ

    Yeah, it's fine

  138. Tobias


  139. Kev

    stpeter: Yes, but the formal vote comes after we've asked the community to review stuff. I'd rather keep asking that until we're prepared to accept it. If we already know we're going to reject it, LC just wastes everyone's time :)

  140. ralphm

    There, now via t-mobile

  141. stpeter nods to Kev

  142. Kev

    OK. Given that Ralph's wet string seems to be broken, I'll assume he's happy too.

  143. Kev

    ralphm: Oooh, stable? :)

  144. ralphm


  145. Kev

    Great. I don't think this needs any formal procedural changes, we'll just Do It.

  146. m&m

    ralphm: it's the 4th carrier, so no one's on it (-:

  147. Kev

    So, second point. Ad-Hoc discovery mechanisms in XEPs.

  148. ralphm

    m&m: I was on the hotel network before

  149. Kev

    Triggered by the 301 discussions, of course.

  150. ralphm

    m&m: and it appears particularly bad

  151. m&m

    ralphm: 4th carrier

  152. m&m

    so, ad-hoc discovery

  153. Kev

    So. My thought on this is that we should not, every time we have a new XEP that needs discovery, invent a new way of dealing with the 'we haven't got presence so can't use caps' case.

  154. Kev

    And when we have presence we just listen to caps to signal availability, and when we don't we do presence uncloaking and then use caps.

  155. m&m


  156. Kev

    (This isn't the same as negotiation, I realise - for which we have Jingle)

  157. ralphm

    Oh, I thought this was implied

  158. ralphm

    so yeah, maybe we need to spell this out

  159. m&m

    I still see some value in "I don't know if you can actually do this, so I'm going to just try"

  160. m&m

    just because I send presence to you does not mean you'll automatically send presence to me

  161. Kev

    301, though, I don't think needs negotiation in that way. If Peter's client does 301 I think it's fine for me to send him 301 until he says "Wait, stop!", and when he receives it his client may prompt him to ask if he wants to start sending, but there isn't a need for explicit negotiation.

  162. Kev

    m&m: Well, that's what the presence uncloaking does.

  163. ralphm

    m&m: that kinda depends on the application, of course

  164. stpeter

    uncloaking = http://xmpp.org/extensions/xep-0276.html

  165. Kev

    m&m: It's saying "Yes, I'm prepared to share capabilities so we can do stuff". It's not like /really/ sending presence (i.e. no roster sub).

  166. Tobias

    doesn't using direct-presence in those cases fixes the problem?

  167. stpeter

    although I'd like to change the name and namespace of 276 :)

  168. Kev

    Tobias: Yes, that's what presence uncloaking is.

  169. Tobias

    Kev, ah..k

  170. m&m

    well, as soon as everyone (clients and servers) implement it

  171. stpeter


  172. Kev

    m&m: Servers don't need to.

  173. Kev

    It's end to end.

  174. stpeter

    m&m: well, almost all clients support direct presence, I'd imagine -- the uncloak stuff is just some niceties on top of directed presence

  175. m&m

    1) yes, I need to re-read -276

  176. m&m

    yes, I understand how directed presence works d-:

  177. ralphm

    stpeter: I mean explicit in our specs, just changing the boilerplate

  178. Kev

    Note that I'm not suggesting we retrofit FINAL XEPs with this - but I think we need a coherent story going forwards, and neither "Send stuff without bothering to do discovery" nor "Make something up for each XEP" seems to be a good policy.

  179. stpeter

    ralphm: yes

  180. ralphm

    (to include a reference to 276)

  181. m&m

    note that 276 is deferred

  182. Kev

    m&m: Yes. That's not much of a barrier though :)

  183. ralphm

    Kev: Even without explicit support of the namespace in 276, I don't think you actually change the workings of current FINAL XEPs with sending directed presence.

  184. stpeter ponders 'decloak' vs 'uncloak' :)

  185. m&m


  186. ralphm

    Kev: do we have such custom discoveries in those XEPS?

  187. ralphm

    stpeter: decloaking on port bow!

  188. stpeter

    yeah, I like the Trek overtones of decloak :)

  189. Kev

    ralphm: Well, -85 has custom discovery (albeit this is a legacy mostly superceded by caps) and -301 is now proposing custom discovery (and even at times advocating dropping disco altogether in favour of blindly sending), and I don't think we have a coherent story for what the Right Thing is - although lots of things are obviously wrong when we see them.

  190. m&m

    I still don't see how −276 fixes everything

  191. ralphm

    301 isn't final

  192. Kev

    ralphm: Oh, I see what you meant.

  193. Kev

    No, I don't think we have Final XEPs doing custom discovery.

  194. Tobias

    Kev, does doing the protocol anyway so the other side can dectect it count as custom discovery too?

  195. Kev

    m&m: It means you always know the caps of the person you're trying to talk to, and therefore know what they support.

  196. Kev

    Tobias: No, that counts as horrible :)

  197. ralphm

    m&m: so maybe you can find a good counter example to discuss next meeting?

  198. m&m

    I will not have time to find such a counter example

  199. ralphm


  200. m&m


  201. Kev

    I don't think we're going to solve anything right now by the sound of it anyway, so let's call it a day.

  202. Kev

    Any other any other business for this non-meeting?

  203. ralphm

    I call this a day.

  204. m&m

    I don't at this time

  205. stpeter


  206. Kev

    OK, I'll take that as done.

  207. Kev

    Thanks all.

  208. Tobias


  209. Kev bangs the gavel.

  210. stpeter

    yep, good discussion

  211. stpeter updates XEP-0276 so it's undeferred

  212. ralphm

    Now breakfast!

  213. Kev

    Does anyone feel that I should write minutes for the non-meeting?

  214. m&m


  215. ralphm

    It was a meeting

  216. ralphm

    with good stuff to note

  217. m&m

    I think any discussion should result in minutes

  218. Kev


  219. m&m

    just because it was all AOB doesn't mean it was not a meeting (-:

  220. Kev

    m&m: I think when there's no agenda, it pretty much does mean it's not a formal meeting, but I'm OK with producing minutes if people think it's worthwhile.

  221. Kev

    (And they do, so OK)

  222. ralphm

    I move we retroactively call it a formal meeting.

  223. ralphm


  224. ralphm

    see what I did!

  225. m&m


  226. m&m


  227. stpeter

    Kev: I think it would indeed be helpful to summarize the discovery discussion, and perhaps the process discussion as well

  228. ralphm has left

  229. ralphm has joined

  230. ralphm has left

  231. ralphm has joined

  232. ralphm has left

  233. ralphm has joined

  234. ralphm has left

  235. ralphm has joined

  236. ralphm has left

  237. ralphm has joined

  238. ralphm has left

  239. ralphm has joined

  240. ralphm has left

  241. Tobias has joined

  242. ralphm has joined

  243. ralphm has left

  244. ralphm has joined

  245. ralphm has left

  246. ralphm has joined

  247. ralphm has left

  248. ralphm has joined

  249. m&m has left

  250. m&m has joined

  251. Kev has left

  252. Kev has joined

  253. Neustradamus has left

  254. Tobias has joined

  255. Neustradamus has joined

  256. m&m has left

  257. m&m has joined

  258. m&m has left

  259. m&m has joined

  260. Tobias has joined

  261. Tobias has joined

  262. m&m has left