XMPP Council - 2018-02-28

  1. Kev

    I believe I'm now current on all Council votes.

  2. Dave

    Kev, In email?

  3. Kev

    Yes, I owed three weeks ago, which I sent last week, and two weeks ago, which I just sent.

  4. Kev

    Last week had no outstanding votes.

  5. Dave

    Time, gentlemen, please.

  6. Dave

    1) Role Call

  7. Ge0rG


  8. Dave

    daniel, Kev SamWhited ?

  9. daniel


  10. SamWhited

    I'm here

  11. Kev

    I'm here.

  12. Kev

    At least in body, if not in mind.

  13. Ge0rG


  14. Dave

    2) Extrcting chunks of XEPs

  15. Dave

    Actually, no.

  16. Dave

    2) For fork's sake, can somebody else take the minutes?

  17. Dave

    (Found my agenda copy)

  18. Dave

    Anyone want to do the minutes?

  19. Ge0rG


  20. SamWhited

    While I normally would, I have a hard time focusing on minutes and paying attention, so I don't like to do it for meetings I'm participating in

  21. Dave

    Ta. I should try to be more forthright on the list.

  22. Dave

    SamWhited, Me neither.

  23. Kev

    I can only do it if I'm chairing, so the meeting naturally pauses when I need it to.

  24. Ge0rG

    Me neither, but we need a volunteer.

  25. Dave

    SamWhited, I tend to do them afterward then, but they're never quite the same.

  26. Dave


  27. SamWhited

    Yah, I don't like doing it afterwards because I always end up having questions, context goes missing, etc. anyways, thanks Ge0rG

  28. Dave

    3) Good Idea Extraction Kev suggested (on the list I think) that extracting good ideas from otherwise out of date XEPs might be useful, in the context of XEP-0013. I wanted to explore this idea for 5 minutes to see if this seems sensible, and figure out what our next steps might be.

  29. Kev

    In the context of 13 I think the new XEP becomes:

  30. Ge0rG

    I don't actually think that it is a good idea for the specific 0013 case.

  31. Kev

    2.7 Removing All Messages The user removes all message by sending the "purge" command: Example 13. User Requests Removal of Offline Messages <iq type='set' id='purge1'> <offline xmlns='http://jabber.org/protocol/offline'> <purge/> </offline> </iq> If the requester is a JID other than an authorized resource of the user, the server MUST return a <forbidden/> error. If the requester is authorized but the node does not exist, the server MUST return a <item-not-found/> error. Otherwise, the server MUST remove all messages and inform the user: Example 14. Server Informs User of Successful Purge <iq type='result' to='romeo@montague.net/orchard' id='purge1'/>

  32. Dave

    So I spotted another case of this, which is that eSessions has what appears to be a perfectly reasonable full-stanza encryption definition.

  33. Kev

    Job done.

  34. Kev

    (Not quite job done, but bloody close)

  35. Ge0rG

    Kev: but race conditions!

  36. SamWhited

    In this case I don't like the idea very much and still think we just need to deprecate the whole old XEP. However, it would get rid of all the other stuff and possibly reduce confusion, so I'm not against it.

  37. Ge0rG

    I'm in favor of killing 13 once we have a way to properly do MAM without offline.

  38. Dave

    Anyone want to volunteer for the XEP-0013 case?

  39. daniel

    wasn't my idea of putting current mam settings in disco info rejected because people didn't like 13's purge?

  40. Ge0rG

    13 is not a way to properly do it.

  41. Dave

    Ge0rG, Sure. But it's better than nothing, and extracting it means we can ditch the rest (I think).

  42. daniel

    without that i don't see how we can savefly purge anyway

  43. daniel

    no matter if that's actual xep13 or xep405 purge

  44. SamWhited

    Maybe that section could be moved into MAM as a "this XEP is deprecated, but if people are still supporting it you might want to do this to clear" note? That would continue to be useful even if a new mechanism was introduced later.

  45. Dave

    SamWhited, I'd rather a new XEP, to shoehorning things into MAM.

  46. Kev

    Something better than -13's "purge offline" is even better, naturally. Like "Disable offline until this session ends" or something.

  47. Ge0rG

    daniel: I haven't had time to think through the implications of your proposal yet.

  48. SamWhited

    It seems to only affect MAM, no? That's when you're going to need to do this workaround, so it seems worth having it in the thing you're already reading that's going to require this

  49. Ge0rG

    Kev: what about adding to MAM: "if a client performs a MAM query before sending initial presence, no offline messages will be sent"

  50. daniel

    Ge0rG, just not sending them will make them pile up though

  51. Kev

    Ge0rG: That works if it's "and they're purged", I think.

  52. Ge0rG

    daniel: on a MAM server, the offline messages queue should be merely a pointer into the archive

  53. Ge0rG

    MattJ had an interesting idea with maintaining per-client offline-message pointers

  54. daniel

    Ge0rG, should…

  55. Dave

    Not wishing to stop this discussion, but I'd like to bring the discussion around somewhat.

  56. Ge0rG

    Dave: do you have other cased for extracting goo ideas from bad XEPs?

  57. Ge0rG

    Dave: do you have other cases for extracting good ideas from bad XEPs?

  58. Dave

    In principle, if we want to deprecate a XEP which still has a single widely used task within it, is our current recommendation that we extract that useful portion into a new XEP?

  59. Dave

    Ge0rG, eSessions full stanza encryption?

  60. Holger

    Blocking non-contacts from 0016?

  61. Kev

    If it wasn't Draft, I'd suggest cutting the other stuff from the XEP. But I don't think that's appropriate at Draft.

  62. SamWhited

    Depends on the situation, I don't think we can make a general statement here

  63. Ge0rG

    Kev: how is forking a part of a Draft into a new XEP and deprecating the Draft better?

  64. Dave

    OK, I don't think we're coming to a conclusion here.

  65. Kev

    I don't think there's a general conclusion to come to, other than 'it's an option'.

  66. Dave

    Which isn't a bad thing, indeed.

  67. Dave

    So, moving on:

  68. Dave

    4) Dusty Drafts Note thread - Sam wanted to place this on the agenda.

  69. SamWhited

    Can we decide what to do in this specific place before we move on?

  70. Kev

    My preference would be a 'good' fix, and get rid of all of 13.

  71. Ge0rG

    what Kev said

  72. Kev

    If we can't do that, just keeping that one bit of 13 alive through a new XEP would work for me.

  73. Ge0rG

    recycling that bit of 13 is bad.

  74. Ge0rG

    it's a shortcut that's going to bite users.

  75. Dave

    I don't have a strong preference here, though currently we're stuck in Clausevitz's dilemma.

  76. Dave

    Right, I'm going to move on.

  77. Ge0rG

    I don't want to leave something behind where in a decade, people will have to draw complex flow-charts on a huge flipboard to understand how to correctly disable offline messaging for a MAM client

  78. SamWhited

    Proposal: 1. add a note to MAM saying "you might need a workaround from this XEP because some legacy systems are still doing this", 2. deprecate the old XEP, 3. wait for someone to come up with a better solution.

  79. SamWhited

    4. remove the notice from MAM and depend on the new thing.

  80. Kev

    I'm not sure it's a case of legacy systems. Offline messages haven't been deprecated or anything.

  81. SamWhited

    Still doing partial 0016, I mean.

  82. Kev

    But other than working, that seems like a reasonable enough approach to me, I guess. Pointing to a deprecated XEP from a Draft one seems odd, but it's likely to be stable.

  83. Zash

    Offline messages aren't technically a spec, right?

  84. Kev

    *than wording

  85. daniel

    interestingly the request mam purges offline messages still breaks the case where the user has disabled mam for themselves. because we make a request. that request will have an empty result but offline messages will be gona anyway

  86. daniel

    so it doesn't really matter if you purge explictiy or implicitly

  87. Dave

    Really moving on, please.

  88. Dave

    4) Dusty Drafts Note thread - Sam wanted to place this on the agenda.

  89. Dave

    So we've a bunch of Draft XEPs that haven't been touched in years.

  90. Kev

    I think you want each XEP as a Council agendum for CFE.

  91. SamWhited


  92. Kev

    Call For Experience.

  93. Kev

    Last Call, but for Final.

  94. Dave

    That'd be to move to Final. But I'd have thought many of them should be moving to Deprecated.

  95. Kev

    I was thinking we'd discuss CFEing each, and when we decide 'no', we'd then vote on deprecated, but whatever.

  96. Dave

    Oh, I can do that.

  97. Ge0rG

    Sounds good to me. CFE -> deprecated|final

  98. Dave

    If everyone's happy with that concept, we can do that next week?

  99. Kev


  100. SamWhited

    We don't need to actually issue a CFE for some of these do we? I feel like a few of them are obvious

  101. SamWhited


  102. Kev

    SamWhited: For deprecating, or going to Final?

  103. Kev

    We have to CFE if we're going to Final.

  104. SamWhited

    For deprecating

  105. Dave

    SamWhited, We wouldn't be CFEing any we want to deprecate.

  106. Kev

    No, that's what I was (trying to) say.

  107. Ge0rG

    So we need to decide which ones to CFE.

  108. Kev

    We ask "Shall we CFE?" for each one, and when Council says "No", we then say "Shall we deprecate then?" and we say "Yes".

  109. SamWhited

    ahh, I see, we don't actually go to CFE. Yah, that seems sensible.

  110. Dave

    What Kev says seems reasonable to me.

  111. Kev

    Otherwise we have a discussion about which one we should CFE and which we should vote to deprecate, and this just seemed cleaner/quicker.

  112. Dave

    But, we'll all need to be prepared on this one, so please do ensure you're ready to vote in the meeting next week.

  113. Dave

    (Otherwise this could drag on for a month...)

  114. SamWhited

    We could probably vote on at least two of them right now, I suspect.

  115. Dave

    Can everyong commit to that?

  116. daniel


  117. Kev

    I wouldn't want to vote on anything without reading the XEP first, so wouldn't like to vote on anything today.

  118. Dave


  119. Kev

    But yes, my general policy is Wednesday morning I spend reviewing stuff that's on the Agenda before Council.

  120. Ge0rG

    +1 for vote next week

  121. SamWhited

    Really? Because SOAP and Internet Metadata seem like obvious candidates to deprecate, we might as well get those off the table

  122. Dave

    Kev, I'll get the next agenda out in advance properly.

  123. Kev

    SamWhited: Except there's interesting stuff in SHIM :)

  124. Dave

    SamWhited, I'm willing to bet SHIM is used for vital stuff in pubsub. And I dislike the protocol.

  125. Dave


  126. SamWhited

    Just SOAP then

  127. Dave

    5) AOB

  128. Dave

    Anything else?

  129. Ge0rG

    I've got some

  130. Dave

    SamWhited, I've been to FOSDEM, SOAP is very much deprecated already it seems.

  131. SamWhited

    Right, so let's go ahead and formalize that and have less to do next week

  132. Dave

    Ge0rG, Shoot.

  133. Ge0rG

    5.1: I'd like to re-call the MUC rewriting @id's discussion from https://mail.jabber.org/pipermail/standards/2014-July/028988.html

  134. Ge0rG

    Back then, there were voices against doing so, and now we ended up with origin-id, which is supposed to work around broken MUCs, but doesn't work in practice anyway.

  135. Ge0rG

    So I'd like to get the wording (final suggestion at the bottom of https://mail.jabber.org/pipermail/standards/2014-July/028996.html) into 0045.

  136. Ge0rG

    | "The service SHOULD reflect the message with the same 'id' that was | generated by the client. If the client did not provide an 'id', the | server MAY generate one 'id' and use it for all reflections of the | same message (e.g. using a UUID as defined in RFC 4122 [18])."

  137. Dave

    Ge0rG, Can you run up a specific patch to vote on for next week?

  138. Ge0rG

    Dave: I can put the above sentence into a PR, if you wish so.

  139. Ge0rG

    I'm aware that this is changing a Draft, but it's reflecting what most implementations are doing anyway.

  140. Ge0rG

    I've got more AOBs.

  141. Dave

    Ge0rG, Keep going, then. :-)

  142. Ge0rG

    Flow said today that <origin-id/> was supposed as a MUC workaround. With 5.1 addressed, I'd like to remove <origin-id/>

  143. Ge0rG

    (this being 5.2)

  144. Kev

    Ge0rG: If you're proposing text that breaks MUC, please note that in that text.

  145. Kev

    (I actually think a disco feature might be appropriate)

  146. Dave

    Ge0rG, Again, I'd like to see a specific PR to vote on, but given 5.1 I'd see 5.2 as desirable.

  147. Ge0rG

    and 5.3: RFC 6120 does mandate that if a stanza has an ID, it should be unique globally or in the current session. As we are using @ids end-to-end, the session limitation doesn't make sense. And when we send an error, we must return the original ID, for which we can't guarantee anything

  148. Ge0rG

    Kev: that was suggested some months ago as well. Should it be on the MUC service or on the individual MUC JID? What would you like it to be called? <will-not-break-ids>?

  149. Kev

    Ge0rG: We've always assumed that what this really means is that between two JIDs they'll be unique, and glossed over that this also isn't really true.

  150. Kev

    Ge0rG: Can out of band the details, and get something I'm happy with, I think.

  151. Ge0rG

    Kev: I'd be glad to get your input on this, even in short form.

  152. Kev

    Sure, but out of band, so the meeting can stop overrunning :)

  153. Ge0rG

    I'm sure I had another AOB, but I forgot to write about it to standards@

  154. Dave

    Ge0rG, Your 5.3 doesn't seem to be more than a statement. But if you'd like to vote on things, next meeting, I'm entirely happy to have these raised and discussed on the mailing list. :-)

  155. Ge0rG

    maybe it was about more feedback regarding the non-dataforms extension of 401, but Kev made a good point on that on list

  156. Dave

    6) Next Meeting

  157. Dave

    Same Time Next Week?

  158. daniel


  159. Kev


  160. SamWhited


  161. Dave


  162. Ge0rG

    I can't guarantee yet.

  163. Ge0rG

    Will be on mobile probably, but I'll try hard.

  164. Dave

    Ge0rG, If we're going to run through these Draft XEPs, it'd be really useful to have you around.

  165. Ge0rG

    Dave: I know.

  166. Dave


  167. Dave

    7) Ite, Meeting Est.

  168. Dave

    Thanks all.

  169. Kev

    Thanks all.

  170. Ge0rG


  171. Kev

    Ge0rG: I suggest something like urn:...stable-id as the feature, on the MUC itself.

  172. Ge0rG

    Kev: that means we need to disco#info each MUC, as opposed to each MUC domain, right?

  173. Kev

    And then some text that says something like "MUST have a stable id, advertised with ...stable-id.... Previous versions of this spec didn't have this requirement, and so some deploments might not follow this rule".

  174. Ge0rG

    disco#items/disco#info on your own domain's services is free essentially

  175. Ge0rG

    Kev: thanks!

  176. Kev

    The disco feature is kinda assuaging my guilt at making a breaking change to a Draft XEP, as much as anything.

  177. Kev

    I'm not actually sure that it's something people will genuinely use, because what do you do if it's not there? Stuff just breaks.

  178. Ge0rG

    Kev: I can promise I'm not going to use that disco#info feature.

  179. Kev

    But it could be put on the MUC domain and the MUC room, I guess, or just on the domain, or whatever.

  180. Ge0rG

    but then again, just opening tickets with broken implementations won't solve the problem either

  181. Kev

    I doubt it's something we're going to address in M-Link immediately, but we've got a rewrite of the MUC code going on at the moment for assorted reasons, including MIX, and I'm intending that to reflect ids.

  182. jonasw

    as much as I’d like to take minutes, the council meeting is unfortunately exactly during my commute until at least june :(