XMPP Council - 2012-07-11


  1. Kev

    T-12 or so.

  2. Tobias

    yup..anything on the agenda?

  3. Tobias

    didn't sound like it in your recent mail

  4. Kev

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

  5. stpeter nods

  6. Tobias

    ah...the 301 fallback discussion?

  7. Tobias

    ah...the 301 disco fallback discussion?

  8. m&m

    yes

  9. m&m

    yes

  10. Tobias

    k

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

  12. m&m

    heh

  13. m&m

    not posh enough

  14. stpeter

    heehee

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

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

  17. Kev

    It is time.

  18. Kev pokes Ralph.

  19. Kev

    1) Roll call.

  20. Kev

    I'm here.

  21. m&m

    presente

  22. Tobias

    here

  23. Kev

    MattJ?

  24. MattJ

    Present

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

  26. Kev

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

  27. m&m

    stpeter: sometime after Hades actually freezes solid?

  28. m&m

    he's enjoying too much sourdough

  29. Kev

    Anyway.

  30. Kev

    Assuming no-one has anything formal to discuss.

  31. Kev

    2) Date of next meeting.

  32. Kev

    As usual?

  33. m&m

    uhm

  34. Tobias

    wfm

  35. m&m double-checks calendar

  36. stpeter thinks m&m will be busy

  37. m&m

    I will be busy

  38. Kev

    OK. Week after?

  39. m&m

    that should work

  40. Kev

    OK then.

  41. stpeter

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

  42. m&m

    (-:

  43. Kev

    3) Any other business.

  44. Tobias

    that'd work too

  45. Kev

    ralphm: Welcome.

  46. ralphm

    present

  47. Kev

    ralphm: :)

  48. ralphm

    +1 on LC 186

  49. Kev

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

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

  51. Kev

    Thanks.

  52. Kev

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

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

  54. m&m

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

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

  56. m&m

    then we can put our objections on the list

  57. Kev

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

  58. Tobias

    Kev, +1 on that

  59. m&m

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

  60. Tobias

    Last Call is for getting wider attention for a broader review

  61. m&m

    could it be a single council member

  62. ralphm

    bah crappy connection

  63. MattJ

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

  64. Kev

    m&m: That probably works for me.

  65. MattJ

    I'm with this I think

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

  67. stpeter

    and not wait for two weeks

  68. Tobias

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

  69. Kev

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

  70. stpeter

    poor Ralph :(

  71. m&m

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

  72. m&m

    up rather

  73. 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!

  74. Kev

    We should probably change that at some point.

  75. stpeter

    heh

  76. Kev

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

  77. ralphm

    +1 on lc by editor

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

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

  80. MattJ

    Mmm

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

  82. Kev

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

  83. m&m

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

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

  85. Kev

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

  86. Kev

    Which is somewhat different, and probably fine.

  87. m&m

    yes … prompted by author or council, but yes

  88. Tobias

    stpeter, that'd work :)

  89. stpeter

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

  90. m&m

    /nod

  91. 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 :)

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

  93. m&m

    not St. Peter … the XEP Editor (-:

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

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

  96. stpeter

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

  97. Kev

    OK.

  98. m&m

    I'm fine with that too

  99. Kev

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

  100. stpeter

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

  101. Kev

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

  102. stpeter

    right

  103. stpeter

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

  104. m&m

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

  105. Kev

    Tobias / ralphm / MattJ?

  106. m&m

    works for me

  107. stpeter

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

  108. m&m

    exactly

  109. MattJ

    Yeah, it's fine

  110. Tobias

    wfm

  111. 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 :)

  112. ralphm

    There, now via t-mobile

  113. stpeter nods to Kev

  114. Kev

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

  115. Kev

    ralphm: Oooh, stable? :)

  116. ralphm

    +1

  117. Kev

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

  118. m&m

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

  119. Kev

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

  120. ralphm

    m&m: I was on the hotel network before

  121. Kev

    Triggered by the 301 discussions, of course.

  122. ralphm

    m&m: and it appears particularly bad

  123. m&m

    ralphm: 4th carrier

  124. m&m

    so, ad-hoc discovery

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

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

  127. m&m

    ok

  128. Kev

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

  129. ralphm

    Oh, I thought this was implied

  130. ralphm

    so yeah, maybe we need to spell this out

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

  132. m&m

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

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

  134. Kev

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

  135. ralphm

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

  136. stpeter

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

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

  138. Tobias

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

  139. stpeter

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

  140. Kev

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

  141. Tobias

    Kev, ah..k

  142. m&m

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

  143. stpeter

    heh

  144. Kev

    m&m: Servers don't need to.

  145. Kev

    It's end to end.

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

  147. m&m

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

  148. m&m

    yes, I understand how directed presence works d-:

  149. ralphm

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

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

  151. stpeter

    ralphm: yes

  152. ralphm

    (to include a reference to 276)

  153. m&m

    note that 276 is deferred

  154. Kev

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

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

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

  157. m&m

    right

  158. ralphm

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

  159. ralphm

    stpeter: decloaking on port bow!

  160. stpeter

    yeah, I like the Trek overtones of decloak :)

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

  162. m&m

    I still don't see how −276 fixes everything

  163. ralphm

    301 isn't final

  164. Kev

    ralphm: Oh, I see what you meant.

  165. Kev

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

  166. Tobias

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

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

  168. Kev

    Tobias: No, that counts as horrible :)

  169. ralphm

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

  170. m&m

    I will not have time to find such a counter example

  171. ralphm

    what!

  172. m&m

    IETF

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

  174. Kev

    Any other any other business for this non-meeting?

  175. ralphm

    I call this a day.

  176. m&m

    I don't at this time

  177. stpeter

    :)

  178. Kev

    OK, I'll take that as done.

  179. Kev

    Thanks all.

  180. Tobias

    thanks

  181. Kev bangs the gavel.

  182. stpeter

    yep, good discussion

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

  184. ralphm

    Now breakfast!

  185. Kev

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

  186. m&m

    (-:

  187. ralphm

    It was a meeting

  188. ralphm

    with good stuff to note

  189. m&m

    I think any discussion should result in minutes

  190. Kev

    OK.

  191. m&m

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

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

  193. Kev

    (And they do, so OK)

  194. ralphm

    I move we retroactively call it a formal meeting.

  195. ralphm

    there

  196. ralphm

    see what I did!

  197. m&m

    seconded

  198. m&m

    (=

  199. stpeter

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