XSF logo XMPP Council - 2012-06-27


  1. m&m has joined
  2. Tobias has left
  3. m&m has left
  4. m&m has joined
  5. m&m has left
  6. Tobias has left
  7. Tobias has joined
  8. Tobias has left
  9. Tobias has joined
  10. stpeter has joined
  11. Kev has left
  12. Tobias has left
  13. m&m has joined
  14. Tobias has joined
  15. MattJ has joined
  16. m&m T - 10
  17. Kev Thanks.
  18. stpeter T - 0 ? ;-)
  19. MattJ T+1
  20. Kev Yep.
  21. stpeter :)
  22. Kev 1) Roll call.
  23. m&m presente
  24. Kev Ralph sends apologies.
  25. Tobias present
  26. Kev (about 2 minutes ago)
  27. Kev MattJ: .
  28. m&m he indicated last week it was likely he'd miss
  29. stpeter Matthew is around, I think
  30. m&m he == Ralph
  31. Kev m&m: Ta.
  32. MattJ Present
  33. Kev 2) LC http://xmpp.org/extensions/xep-0186.html ?
  34. Kev I've just noticed a somwhat major problem with this.
  35. MattJ Oh?
  36. Kev Which is that if a user goes invisible, joins some MUCs and then goes visible those MUCs will never receive an unavailable.
  37. Kev "When the client becomes visible, the server MUST treat that state as equivalent to an active session before receiving initial presence from the client."
  38. stpeter hmm
  39. Kev So it's a trivial fix, I think, just that sentence needs a reword.
  40. m&m /nod
  41. stpeter if an invisible man enters a room, is he present? ;-)
  42. MattJ Yes and no
  43. m&m Schrodinger's occupant?
  44. stpeter heh
  45. Tobias hehe
  46. Kev So, I don't know if Peter wants to fix that up a bit before we issue Last Call, or after.
  47. Kev I'm easy.
  48. stpeter Kev: won't the MUC room receive unavailable if the now-visible man goes offline?
  49. Kev No, because the server's forgotten about the directed presence.
  50. stpeter oh, I see
  51. stpeter right
  52. m&m active != available
  53. stpeter same is true for all directed presence sent while invisible
  54. stpeter ok
  55. Kev Right. The MUC was an illustration because it's the most likely use of directed presence while invisible (he asserts, boldly).
  56. stpeter yeah, I will clean that up -- I assume we'd prefer to say that the server needs to add any directed presence JIDs to its list of entities it'll send unavail to
  57. Kev Right.
  58. stpeter prepopulate that list -- whatever we call it in RFC 6921
  59. Kev Want to do that pre-or-post-LC?
  60. stpeter er, 6121 ;-)
  61. stpeter no preference
  62. stpeter might as well do it right now
  63. m&m (-:
  64. stpeter or after this meeting :)
  65. Kev I'll +1 the LC in any case.
  66. Kev Everyone else?
  67. Tobias +1
  68. m&m also +1
  69. m&m it's far enough from IETF (-:
  70. Kev MattJ: ?
  71. MattJ Did anyone read my points about probes on the list?
  72. Kev MattJ: I haven't.
  73. MattJ As in, mainly I want them optional
  74. Kev Or, at least, I didn't notice it enough for it to stay in my inbox.
  75. MattJ and an optional flag in the protocol to enable/disable them
  76. m&m I don't recall either
  77. MattJ I can provide text for it, but do we want it pre-draft/LC?
  78. Kev MattJ: I don't think the XEP prohibits probes, does it?
  79. MattJ There are pros/cons each way regarding the sending of probes
  80. MattJ It depends how paranoid you are, and your reasons for invisibility
  81. stpeter I thought we concluded that the flag would make this little extension less simple than desired
  82. MattJ Fair enough if that really is the consensus
  83. MattJ Let's LC it, and I'll post my thoughts to the list
  84. stpeter well, feel free to raise the issue again
  85. stpeter ok
  86. Kev MattJ: I'm not sure it makes a great deal of sense to add that to the XEP, although I'm not dead-set against it.
  87. Kev I note, though, that a server can allow the client to change whether it happens as part of the per-user ad-hoc configuration.
  88. Kev Assuming it has such a thing.
  89. MattJ Kev, if we don't add it, should the server default to sending or not sending probes?
  90. Kev (And the XEP gives leeway either way)
  91. Kev Implementation issue? :)
  92. m&m this sounds like a great discussion for the list, post LC
  93. MattJ Kev, not exactly :)
  94. Kev In any case, that's everyone present +1 on LC.
  95. MattJ Or two differing implementations will give invisible users very different behaviour
  96. MattJ But yes, +1 to LC and we'll discuss on-list
  97. Kev 3) http://xmpp.org/extensions/inbox/xml-media-element.html Accept?
  98. MattJ I need to read it through, and I'll post to the list
  99. m&m I have further objections to publishing
  100. m&m er
  101. m&m no futhre
  102. m&m gah
  103. m&m no further
  104. Kev I've got assorted issues with it, but not enough to prevent it going on the vine.
  105. m&m exactly
  106. Kev Tobias: ?
  107. Tobias +1 for publishing as experimental and fixing remaining issues then
  108. Kev 4) Date of next meeting?
  109. Kev It'd be easier for me for it to not be next week, but I can possibly manage if we need it.
  110. m&m -1 to next week
  111. MattJ +0 to next week
  112. Kev Week after?
  113. m&m Us 'Murricans have a holiday
  114. MattJ Oh good
  115. m&m 7/11 works for me
  116. m&m and not just for Slurpees
  117. Kev Ah, yes, when we good British folks gave the Merkins a kind and thoughtful present of independence.
  118. Tobias that'd work for me
  119. stpeter Kev: When the client becomes visible, the server MUST treat that state as equivalent to an active session before receiving initial presence from the client, with one exception: if the client sent directed presence to any entities while in the invisible state, the server MUST treat those entities as under point 2 of Section 4.6.3 of RFC 6121 (i.e., the server MUST ensure that it sends unavailable presence to those entities if the client subsequently goes offline after becoming visible).
  120. Kev stpeter: +1 on that text.
  121. Kev (Thanks)
  122. stpeter good catch
  123. Kev OK, so we've on for a fortnight ~now.
  124. stpeter I'll 0.11 shortly and then issue the LC
  125. Kev 5) AOB?
  126. m&m none from me
  127. Tobias no AOB from me either
  128. Kev Cool, all done then.
  129. Kev Thanks all
  130. Kev bangs the gavel.
  131. m&m with plenty of time before my next meeting!
  132. Tobias thanks
  133. m&m goes back to upsetting various working groups
  134. m&m oh wow … fippo actually posed to a list!
  135. Tobias has left
  136. Tobias has joined
  137. Tobias has left
  138. Tobias has joined
  139. Zash has joined
  140. Tobias has left
  141. Tobias has joined
  142. m&m has left
  143. m&m has joined
  144. m&m has left
  145. m&m has joined
  146. Zash has left
  147. m&m has left
  148. m&m has joined
  149. m&m has left
  150. m&m has joined
  151. m&m has left
  152. bear has joined
  153. bear has left