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 yes
  21. m&m yes
  22. Tobias k
  23. stpeter still thinks we need an XMPP extension called "hustle"
  24. m&m heh
  25. m&m not posh enough
  26. stpeter heehee
  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 presente
  35. Tobias here
  36. Kev MattJ?
  37. MattJ Present
  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 Anyway.
  43. Kev Assuming no-one has anything formal to discuss.
  44. Kev 2) Date of next meeting.
  45. Kev As usual?
  46. m&m uhm
  47. Tobias wfm
  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 present
  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 Thanks.
  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 heh
  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 Mmm
  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 /nod
  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 OK.
  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 right
  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 exactly
  137. MattJ Yeah, it's fine
  138. Tobias wfm
  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 +1
  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 ok
  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 heh
  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 right
  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 what!
  200. m&m IETF
  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 thanks
  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 OK.
  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 there
  224. ralphm see what I did!
  225. m&m seconded
  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