XMPP Council - 2012-06-27

  1. m&m

    T - 10

  2. Kev


  3. stpeter

    T - 0 ? ;-)

  4. MattJ


  5. Kev


  6. stpeter


  7. Kev

    1) Roll call.

  8. m&m


  9. Kev

    Ralph sends apologies.

  10. Tobias


  11. Kev

    (about 2 minutes ago)

  12. Kev

    MattJ: .

  13. m&m

    he indicated last week it was likely he'd miss

  14. stpeter

    Matthew is around, I think

  15. m&m

    he == Ralph

  16. Kev

    m&m: Ta.

  17. MattJ


  18. Kev

    2) LC http://xmpp.org/extensions/xep-0186.html ?

  19. Kev

    I've just noticed a somwhat major problem with this.

  20. MattJ


  21. Kev

    Which is that if a user goes invisible, joins some MUCs and then goes visible those MUCs will never receive an unavailable.

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

  23. stpeter


  24. Kev

    So it's a trivial fix, I think, just that sentence needs a reword.

  25. m&m


  26. stpeter

    if an invisible man enters a room, is he present? ;-)

  27. MattJ

    Yes and no

  28. m&m

    Schrodinger's occupant?

  29. stpeter


  30. Tobias


  31. Kev

    So, I don't know if Peter wants to fix that up a bit before we issue Last Call, or after.

  32. Kev

    I'm easy.

  33. stpeter

    Kev: won't the MUC room receive unavailable if the now-visible man goes offline?

  34. Kev

    No, because the server's forgotten about the directed presence.

  35. stpeter

    oh, I see

  36. stpeter


  37. m&m

    active != available

  38. stpeter

    same is true for all directed presence sent while invisible

  39. stpeter


  40. Kev

    Right. The MUC was an illustration because it's the most likely use of directed presence while invisible (he asserts, boldly).

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

  42. Kev


  43. stpeter

    prepopulate that list -- whatever we call it in RFC 6921

  44. Kev

    Want to do that pre-or-post-LC?

  45. stpeter

    er, 6121 ;-)

  46. stpeter

    no preference

  47. stpeter

    might as well do it right now

  48. m&m


  49. stpeter

    or after this meeting :)

  50. Kev

    I'll +1 the LC in any case.

  51. Kev

    Everyone else?

  52. Tobias


  53. m&m

    also +1

  54. m&m

    it's far enough from IETF (-:

  55. Kev

    MattJ: ?

  56. MattJ

    Did anyone read my points about probes on the list?

  57. Kev

    MattJ: I haven't.

  58. MattJ

    As in, mainly I want them optional

  59. Kev

    Or, at least, I didn't notice it enough for it to stay in my inbox.

  60. MattJ

    and an optional flag in the protocol to enable/disable them

  61. m&m

    I don't recall either

  62. MattJ

    I can provide text for it, but do we want it pre-draft/LC?

  63. Kev

    MattJ: I don't think the XEP prohibits probes, does it?

  64. MattJ

    There are pros/cons each way regarding the sending of probes

  65. MattJ

    It depends how paranoid you are, and your reasons for invisibility

  66. stpeter

    I thought we concluded that the flag would make this little extension less simple than desired

  67. MattJ

    Fair enough if that really is the consensus

  68. MattJ

    Let's LC it, and I'll post my thoughts to the list

  69. stpeter

    well, feel free to raise the issue again

  70. stpeter


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

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

  73. Kev

    Assuming it has such a thing.

  74. MattJ

    Kev, if we don't add it, should the server default to sending or not sending probes?

  75. Kev

    (And the XEP gives leeway either way)

  76. Kev

    Implementation issue? :)

  77. m&m

    this sounds like a great discussion for the list, post LC

  78. MattJ

    Kev, not exactly :)

  79. Kev

    In any case, that's everyone present +1 on LC.

  80. MattJ

    Or two differing implementations will give invisible users very different behaviour

  81. MattJ

    But yes, +1 to LC and we'll discuss on-list

  82. Kev

    3) http://xmpp.org/extensions/inbox/xml-media-element.html Accept?

  83. MattJ

    I need to read it through, and I'll post to the list

  84. m&m

    I have further objections to publishing

  85. m&m


  86. m&m

    no futhre

  87. m&m


  88. m&m

    no further

  89. Kev

    I've got assorted issues with it, but not enough to prevent it going on the vine.

  90. m&m


  91. Kev

    Tobias: ?

  92. Tobias

    +1 for publishing as experimental and fixing remaining issues then

  93. Kev

    4) Date of next meeting?

  94. Kev

    It'd be easier for me for it to not be next week, but I can possibly manage if we need it.

  95. m&m

    -1 to next week

  96. MattJ

    +0 to next week

  97. Kev

    Week after?

  98. m&m

    Us 'Murricans have a holiday

  99. MattJ

    Oh good

  100. m&m

    7/11 works for me

  101. m&m

    and not just for Slurpees

  102. Kev

    Ah, yes, when we good British folks gave the Merkins a kind and thoughtful present of independence.

  103. Tobias

    that'd work for me

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

  105. Kev

    stpeter: +1 on that text.

  106. Kev


  107. stpeter

    good catch

  108. Kev

    OK, so we've on for a fortnight ~now.

  109. stpeter

    I'll 0.11 shortly and then issue the LC

  110. Kev

    5) AOB?

  111. m&m

    none from me

  112. Tobias

    no AOB from me either

  113. Kev

    Cool, all done then.

  114. Kev

    Thanks all

  115. Kev bangs the gavel.

  116. m&m

    with plenty of time before my next meeting!

  117. Tobias


  118. m&m goes back to upsetting various working groups

  119. m&m

    oh wow … fippo actually posed to a list!