XMPP Council - 2019-05-08


  1. jonas’

    Kev, IIRC, you wanted amendments to https://github.com/xsf/xeps/pull/784, can you please confirm that the changes Ge0rG made are okay with you?

  2. jonas’

    Kev, and the same for https://github.com/xsf/xeps/pull/778

  3. jonas’

    <nevermind>

  4. dwd

    Afternoon all.

  5. jonas’

    afternoon, dwd

  6. Ge0rG is semi present

  7. dwd

    So:

  8. dwd

    1) Roll Call.

  9. jonas’ is here

  10. Kev

    Here

  11. jonas’

    Link Mauve ?

  12. Link Mauve

    Hi, I’m here.

  13. dwd

    I see Georg's partial presence.

  14. dwd

    Excellent.

  15. dwd

    2) Agenda Bashing

  16. jonas’

    board wants us to talk about https://github.com/xsf/xeps/pull/780

  17. Kev

    Was there an agenda?

  18. dwd

    There was not. So, Kev, you remember that nice little Yaris I used to have before it got hit by an HGV yesterday? Well, something happened to it, see if you can guess why I got distracted. :-/

  19. Kev

    You driving? Ok?

  20. dwd

    My son driving - actually not so much driving, sicne the handbrake was on. No injuries, walking pace collision, but the car has received substantial unexpected remodelling.

  21. jonas’

    oh dear, thank $deity

  22. Kev

    Quite.

  23. Link Mauve

    Ow.

  24. dwd

    But anyway, that's my exciting news. Given the cheapness of my cars, it's probably an insurance write-off.

  25. dwd

    So - #780 - anything else?

  26. jonas’

    not that I knew

  27. Guus

    (that's the same son that is a pilot?)

  28. Ge0rG

    That AOB discussion from two weeks ago? I tried to remind the List, but it failed similarly to what Kev attempted

  29. dwd

    Guus, Yes. Better a minor car crash than a minor aircraft crash. :-)

  30. jonas’

    Ge0rG, what was the AOB again?

  31. dwd

    3) Items Not For A Vote:

  32. dwd

    a) https://github.com/xsf/xeps/pull/780 (Editorial changes and XEP state)

  33. jonas’

    I am +1 on that one for obvious reasons

  34. Ge0rG

    Why are you +1 if it's not for a vote?

  35. jonas’

    I’m not sure if it’s for a vote or not, and this expresses my intent unambigiuously either way :)

  36. Kev

    My comment still stands that we have a definition based on versioning here already, and making that clearer would be good. Instead of the suggested wording.

  37. dwd

    Seve's point is interesting. Are you intending to mean that if a XEP has a substantial edit in (say) April, and a series of edits considered Editorial subsequently, it would still be moved to Deferred in October?

  38. jonas’

    Kev, I’m still not sure we do, technically

  39. jonas’

    dwd, yes

  40. Kev

    jonas’: XEP-0001 is only concerned with substantive edits (x.y), not the x.y.z versions we use for editorial stuff.

  41. Kev

    I'd rather we codified the use of x.y.z in XEP-0001 for Editorial changes.

  42. jonas’

    that’s what I meant by ". So to be able to refer to that, we’d have to go ahead and write that down clearly. Which I’m not opposed to, in general, but time and stuff."

  43. Kev

    dwd: Believe it or not, based on the versioning requirements, that's what XEP-0001 already says.

  44. jonas’

    that’s what I meant by "So to be able to refer to that, we’d have to go ahead and write that down clearly. Which I’m not opposed to, in general, but time and stuff."

  45. jonas’

    if you folks think that needs more explanation and should be made clearer, I can put it on my todo to write that down

  46. dwd

    Kev, I believe you. But Seve's point is that the way that reads is that you can make a substantial edit to a document which causes it to be deferred.

  47. jonas’

    an edit can never cause a document to be deferred

  48. jonas’

    time does

  49. Link Mauve

    Yeah, removing the “or to” part would seem sensible.

  50. dwd

    jonas’, I think I lean toward defining versions properly and unequivocally, and then I think this particular change/clarification falls out of that automatically.

  51. jonas’

    okay

  52. jonas’

    so I’ll go ahead and do that

  53. dwd

    Link Mauve, Except an editorial change is intended to leave the move *to* Deferred unaffected, so ...

  54. dwd

    jonas’, Sorry for making more work for you.

  55. jonas’

    it’s alright

  56. jonas’

    I have been thinking about that one anyways

  57. Ge0rG

    That phrasing is not perfect, I agree with Seve

  58. jonas’

    and yeah, that phrase is a weak spot in the diff

  59. jonas’

    will fix both

  60. Link Mauve

    dwd, “[…] for the purpose of considering moving a XEP back from Deferred state, or keep it there.” maybe?

  61. dwd

    Link Mauve, As I say, once you define versioning clearly, I don't think it matters anymore.

  62. jonas’

    I think it’s more effective when I draft up an alternative wording and we discuss it

  63. dwd

    So:

  64. Link Mauve

    jonas’, agreed.

  65. dwd

    b) That AOB That Georg Raised A Few Weeks Back.

  66. jonas’

    Ge0rG, what was it even about?

  67. Ge0rG

    > Purely editorial changes (e.g. version updates from 0.1.1 to 0.1.2) count as <em>activity</em> (or <em>updates</em>) do not effect the Deferred state or deferral time of an XEP.

  68. Ge0rG

    it was about fixing 0184 properly

  69. jonas’

    ah that

  70. jonas’

    wasn’t that last week?

  71. jonas’

    apparently not, and also it doesn’t matter

  72. Ge0rG

    the other AOB was asking Link Mauve to explain how to do MUC-0313 without exposing a DoS vector

  73. dwd

    Ge0rG, Which first?

  74. Ge0rG

    dwd: in that order please

  75. dwd

    Ge0rG, OK. 5 minutes on each then.

  76. dwd

    b) Fixing XEP-0184 properly.

  77. Link Mauve

    Ge0rG, I have never implemented 0313 in a server, I’m sure there are many better people than me for that.

  78. Ge0rG

    https://mail.jabber.org/pipermail/standards/2019-April/036083.html

  79. Ge0rG

    (Link Mauve: sorry, I meant 0308)

  80. jonas’

    ah, about that

  81. Ge0rG

    That message-type info box in 0184 is a fig-leaf, and Kev asked to do it right in one of the last Council Meetings. Do we want to fix it properly?

  82. jonas’

    I’m all in for fixing things properly

  83. jonas’

    but we need to do it without a namespace bump, because there are other things we should include when we bump 184

  84. dwd

    I'm in favour of fixing things properly as a general rule. What do real implementations actually do?

  85. Ge0rG

    how far can I go with "fixing" it without you requiring a version bump?

  86. Ge0rG

    dwd: it varies wildly

  87. Ge0rG

    some reflect message type, others send normal. Some send to full JID, others to bare JID

  88. dwd

    Ge0rG, You bump a namespace when to implementations using the same namespace would fail to interoperate (or, indeed, already do).

  89. jonas’

    Ge0rG, I’d say we specify that clients SHOULD send the same type, but MUST accept different types, too.

  90. Ge0rG

    dwd: the XEP does not mention message types.

  91. jonas’

    mention why it makes sense to have that (archive stuff)

  92. Ge0rG

    (except when treating MUCs)

  93. dwd

    Ge0rG, I have noticed that some (COnverse, perhaps?) only handle receipts in type='chat'. I'd thought receipts were meant to be in type='normal' myself.

  94. Ge0rG

    dwd: "were meant to" is your reading of the XEP or some background knowledge?

  95. Ge0rG

    type=normal + no body leads to them being ephemeral for MAM and Carbons.

  96. Link Mauve

    Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.

  97. Ge0rG

    Link Mauve: please wait for AOB c.

  98. Link Mauve

    Ack.

  99. dwd

    Ge0rG, I read the XEP and implemented my end, and it failed. But Example 4, for example, shows a normal message.

  100. Ge0rG

    dwd: no, it shows a message with default message type.

  101. jonas’

    which is type normal

  102. Ge0rG

    I claim that this is an oversight of the XEP author and not a deliberate design decision.

  103. Ge0rG

    And it's not normative in any case.

  104. dwd

    Ge0rG, So what does "fixed" look like? Same type? I personally think that 1:1 receipts ought to be in type='normal', and not type='chat' (since they're not chat messages). But I'm not wed to that idea.

  105. Ge0rG

    dwd: the pseudo-quote block in https://mail.jabber.org/pipermail/standards/2019-April/036090.html

  106. jonas’

    The receiving client should consider the following when generating a Receipt, depending on the message type of the message that contained the Receipt Request: - "chat", "normal": the Receipt message SHOULD have the same @type as the Request message. - "groupchat": it is NOT RECOMMENDED to request Receipts in a MUC. A client choosing to respond despite of this SHOULD send the Receipt with type="groupchat" to the bare JID of the room and not to the full JID of the sender. It MAY be useful to limit this feature to private MUCs with a small number of participants, or to instead send the Receipt as a MUC-PM. - "headline": the Receipt message SHOULD have type="normal". - "error": this should not actually be possible, so the client SHOULD NOT (MUST NOT) respond. A client MUST be able to Process a Receipt message with a different type than the original Receipt Request message.

  107. jonas’

    (quoting from Ge0rGs mail)

  108. dwd

    jonas’, Thanks.

  109. Ge0rG

    This is strawman wording, not carved in stone.

  110. jonas’

    I think that’s sane, with the exception of the "headline" rule; I have no opinion on the "headline" rule

  111. dwd

    OK, so it's not clear to me that this is a bad set of words. I'd be happy to see that as a PR and we can vote on it.

  112. jonas’

    I think that’s sane, with the exception of the "headline" rule; I have no opinion on the "headline" rule due to lack of data

  113. Ge0rG

    I wanted to initiate a discussion, specifically about _how_ to treat each of those, and whether this would be a ns-bumping change

  114. dwd

    Ge0rG, I think it's compatible with the existing XEP, and can only improve interop, so seems OK to me without a bump.

  115. Ge0rG

    Maybe what dwd said is the more sensible strategy: have all receipts be type=normal and rather fix MAM and Carbons

  116. Ge0rG

    I think we can all agree that a type=headline receipt doesn't make sense.

  117. dwd

    We're running over on the 5-minute slot here, though - I'll dig out that email and reply to it with some comments.

  118. jonas’

    for some reason that mail was marked as read so I totally forgot about it

  119. Ge0rG

    dwd: awesome. I can't promise any activity in the next three weeks though.

  120. jonas’

    replied, too

  121. dwd

    c) XEP-0308 (Last Message Correction) in MUC

  122. jonas’

    Link Mauve, your slot

  123. jonas’

    I guess this is in context of https://github.com/xsf/xeps/pull/736

  124. Ge0rG

    Link Mauve: the PR was rejected because everybody was wondering how you are going to combine limited back-history with strong guarantees

  125. Ge0rG

    Yes

  126. jonas’

    quoting Link Mauve from above: 15:22:43 Link Mauve> Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.

  127. jonas’

    quoting Link Mauve from above: 15:22:43 Link Mauve> Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.

  128. jonas’

    i guess we can defer the discussion based on that?

  129. Link Mauve

    Indeed, that’d be my preferred course of action.

  130. Ge0rG

    I wanted to clarify the issue, but it's in the Council logs as well, obviously.

  131. Ge0rG

    Alright, let's defer

  132. dwd

    OK, so nothing on this yet. That's fine.

  133. dwd

    4) Voting

  134. Kev

    Is there anything?

  135. dwd

    (Please do so, I think some expire today).

  136. jonas’

    Link Mauve, you’re pending votes on: - https://github.com/xsf/xeps/pull/778 - https://github.com/xsf/xeps/pull/787 - https://github.com/xsf/xeps/pull/779

  137. Kev

    Ah, right.

  138. Ge0rG

    Link Mauve is owing me a vote or two

  139. dwd

    5) Next Meeting

  140. jonas’

    Link Mauve, you’re pending votes on: - https://github.com/xsf/xeps/pull/778 - https://github.com/xsf/xeps/pull/787 - https://github.com/xsf/xeps/pull/779 - https://github.com/xsf/xeps/pull/758

  141. dwd

    I think we're moving into the Time Of No Georg?

  142. jonas’

    +1 wfm

  143. jonas’

    +1w wfm

  144. Ge0rG

    dwd: right. I can't promise presence in the next two meetings.

  145. dwd

    +1wwfm2.

  146. Kev

    The interregnum!

  147. Kev

    Yeah, WFM.

  148. Ge0rG

    it might work on short notice though.

  149. Link Mauve

    Wfm too.

  150. dwd

    OK, great.

  151. dwd

    6) AOB

  152. dwd

    I'll assume that we've covered everything.

  153. dwd

    7) Ite, Meeting Est

  154. dwd

    And I numbered it right this time, Tedd.

  155. Kev

    Thanks all

  156. Ge0rG

    Thanks

  157. jonas’

    \o/ thx

  158. Link Mauve

    Thanks. :)

  159. Link Mauve

    And now, to cast my votes!