XMPP Council - 2019-04-24

  1. Kev

    Ok, I've remembered why the full-JID limit is in place, and it's an attempt to avoid issues with id collisions.

  2. Kev

    re: https://github.com/xsf/xeps/pull/784/files

  3. Kev

    I don't know if that should change our opinions at all.

  4. Kev

    For https://github.com/xsf/xeps/pull/778/files (I thought you could suggest text tweaks directly in github, but I don't see how now), under mandatory support I suggest adding the text """ While future versions of this specification (or other specifications) might use a different set of delivery rules, they would signify this by advertising a namespace other than "urn:xmpp:carbons:rules:0". """ , which I think matches what I suggested/requested last week. Ge0rG ^

  5. Ge0rG

    Kev: that's a great suggestion. I pondered about writing something along those lines, but then I realized that this is exactly why you have versioned namespaces in the first place, and thus considered it redundant

  6. Kev

    Half, yes. There's an ulterior motive there, which is that it's a get-out clause for letting us change things during Draft that otherwise would be more difficult :)

  7. Kev

    By mentioning that more changes might come later.

  8. Ge0rG

    Kev: https://github.com/xsf/xeps/pull/778/commits/e6cb1297f3a70b5f32af39250bd19951ec3c063d

  9. Ge0rG

    Kev: you claimed to have started a list discussion on https://github.com/xsf/xeps/pull/779 but I don't see anything.

  10. Ge0rG

    *hem* *hem*

  11. dwd


  12. dwd

    1) Roll Call

  13. jonas’


  14. Kev


  15. Ge0rG .o/

  16. dwd

    Link? Or are we Linkless today?

  17. dwd


  18. jonas’


  19. Kev

    Ge0rG: if it helps your search, I said this about 779: """ This seems a little backwards to me - it’s only saying the completely non-normative 'is a good practice’ for doing the right thing, while saying ’should’ (yes, I realise lower case) accept the wrong thing. Should we not SHOULD doing the right thing? /K """

  20. dwd

    Unlunk, then.

  21. dwd

    2) Agenda Bashing

  22. Ge0rG

    let's put #779 on the agenda then?

  23. dwd

    OK, so Georg's suggested agenda plus #779.

  24. Ge0rG

    The only source of agenda items that I wanted to push onto everybody was what I came up with in the last week.

  25. Ge0rG

    I checked open PRs for "Council Needed", but don't know about proto XEPs or other issues

  26. dwd

    I'm in the office on a poor excuse for a computer, so I'm a bit rubbish today, but:

  27. dwd

    3) Items for voting.

  28. dwd

    a) #778 (XEP-0280 rules bit)

  29. jonas’

    +1 on #778

  30. Ge0rG

    I'm very much +1 on this.

  31. Ge0rG

    Please consider that it received another small update just one hour prior to this Meeting.

  32. dwd

    I think I'm +1, but I'll re-review properly if I have the time.

  33. Kev

    I'm +1 if I can have my text from earlier (bonus points if it also changes back to MAY when not using the feature ,but not blocking)

  34. dwd

    (But assume +1)

  35. Ge0rG

    dwd: _when_ you have the time?

  36. Kev

    Ah, my tweak's already in. +1 then.

  37. Ge0rG

    Kev: your text is already in

  38. dwd

    Ge0rG, I appreciate your optimism. I should do tonight.

  39. Ge0rG

    Actually, the SHOULD->MAY change is something we MAY discuss today

  40. dwd

    I think that's everyone +1, with Link Mauve on list.

  41. dwd

    And I'll suggest discussion later in AOB, if that's OK?

  42. Ge0rG

    With the new feature (does the name `urn:xmpp:carbons:rules:0` sound right to you?) I don't insist on SHOULDing the rules by default

  43. dwd

    b) #787 (Xep-0045, kill GC-1.0 with fire)

  44. Kev

    Ge0rG: I'd prefer SHOULD->MAY, but not a hill for me.

  45. Ge0rG

    +1 on #787

  46. jonas’

    +1 on #787

  47. Kev

    urn...carbons:rules:0 seems fine to me.

  48. dwd

    +1 on this from me.

  49. Kev

    +1 on 787. I note that I'm not convinced it won't break anything, but progress and all that.

  50. dwd

    Kev, My conclusion was that it'll break things, but break them cleanly.

  51. Ge0rG

    Kev: prosody 0.11 was rolled out without GC1 and there was no Major Backlash

  52. Kev

    Major Backlash, reporting for duty.

  53. dwd

    c) #779 (I don't know what this is, even)

  54. Ge0rG

    We can rename it into GCexit if that suits you more.

  55. Kev

    Ge0rG: I'd like an extension, please.

  56. Ge0rG

    #779 is about an informative box in 0184 regarding the message @type

  57. Kev

    https://github.com/xsf/xeps/pull/779/files is what we discussed two weeks ago.

  58. dwd

    Yes, I was thinking this looked familiar.

  59. Kev

    My onlist response was > This seems a little backwards to me - it’s only saying the completely non-normative 'is a good practice’ for doing the right thing, while saying ’should’ (yes, I realise lower case) accept the wrong thing. Should we not SHOULD doing the right thing?

  60. Ge0rG


  61. Ge0rG

    Kev: I can uppercase it.

  62. Ge0rG

    but I won't uppercase the "must" in the MUC section

  63. Kev

    It's the other way around though, I think.

  64. Kev

    At the moment we're not should nor SHOULDing doing the right thing (matching type).

  65. Ge0rG

    because an implementation might want to realize MUC receipts as a MUC-PM

  66. Kev

    We're only shoulding what to do if you receive the wrong thing (different type).

  67. Kev

    I suggest s/It is a good proctice to/A client SHOULD/, I think.

  68. Kev

    (ignoring my typos)

  69. dwd

    I'll have a premptivee +1 on this. I'm pretty sure it's more or less right and that you two will figure outt the precise language here.

  70. Ge0rG

    Kev: that would be a normative change.

  71. Kev

    I think requiring the client to match non-matching types already is.

  72. Ge0rG

    I agree that it's the Right Thing, but I wasn't brave enough to introduce _that_

  73. Ge0rG

    Kev: prior versions didn't have any requirements on the incoming message type, so... no?

  74. Kev


  75. Ge0rG

    you could therefore argue that a client MUST accept different message types.

  76. Kev

    In that case, I'd suggest dropping that SHOULD back to a should, and brushing it under the carpet.

  77. Ge0rG

    Kev: I just added a patch to the PR containing the SHOULD.

  78. Kev

    Yeah, ok.

  79. Ge0rG

    Now you made me regret it.

  80. Kev

    Do we have enough +1s to pass if I +0? :)

  81. Ge0rG


  82. dwd

    jonas’ ?

  83. Kev

    +0 then.

  84. Ge0rG

    > PR #779 - XEP-0184: add a box about types and JIDs - https://github.com/xsf/xeps/pull/779 > Dave: [pending] > Georg: +1 > Jonas: +1 > Kev: [on-list] > Link: +1

  85. jonas’

    still +1

  86. dwd

    Yeah, I think I voted +1 afterward/

  87. dwd

    And I'm still +1 whatever you guys decide on this.

  88. Ge0rG

    Is it an AOB to actually decide that?

  89. Kev

    The branch as-is is what's going in, I think.

  90. Kev

    And while I don't think it's quite right, I'm ok with that.

  91. dwd


  92. dwd

    4) Outstanding Votes.

  93. dwd

    I have no clue today. But please check if you have any oustanding votes and vote them, outstandingly.

  94. dwd

    5) AOB

  95. Kev

    I believe I'm completely up to date now, unusually.

  96. jonas’

    mayeb we should re-discuss that PR I brought up on the list again

  97. Ge0rG

    I'm pending on #736 because we need feedback from Link Mauve

  98. Ge0rG

    jonas’: which one would that be?

  99. jonas’

    -> https://github.com/xsf/xeps/pull/758 for next agenda maybe, I think it was technically vetoed but I’d like to re-open discussion on that one

  100. jonas’

    because Kevs reasoning is unclear to me.

  101. Kev

    What was my reasoning? :)

  102. jonas’

    here’s my respones to your reasoning: https://mail.jabber.org/pipermail/standards/2019-April/036059.html

  103. jonas’

    here’s your original reasoning: https://mail.jabber.org/pipermail/standards/2019-March/035888.html

  104. Ge0rG

    nobody remembers, so move it to next week or have it added to AOB?

  105. Kev

    Ah, I remember, excellent.

  106. Kev

    This is in 5.4 https://xmpp.org/extensions/xep-0060.html#entity-metadata

  107. Kev

    Which says "If metadata is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like."

  108. Kev

    So I think if you add more options here, you SHOULD now include them (if you include any).

  109. Kev

    And so I think the claim that it doesn't change conformance wasn't right.

  110. dwd

    Right, and jonas’'s argument is that by the wording there, the access-model SHOULD already be included.

  111. Kev

    Ah, hrmm.

  112. dwd likes typing "jonas’'s" because of the fun punctuation.

  113. Kev

    Yeah, I buy that argument.

  114. dwd

    I suspect the practical solution would be to change the "it SHOULD" to "implementations are encouraged" in order to reflect reality.

  115. Kev

    Ah, no, because there is a registry in there for the form_type

  116. Kev

    And this is adding to it.

  117. Kev


  118. Ge0rG

    dwd: this is the worst way to improve an XEP.

  119. jonas’

    it is, but it is still a configuration option

  120. jonas’

    and it still should be reflected in there

  121. dwd

    Ge0rG, Indeed. But we then add a feature that says "I do this bit right".

  122. Ge0rG

    dwd: that's better. Or we write into the XEP that before version 1.23.42, the behavior was different and that the other end must cope with old entities.

  123. dwd

    Ge0rG, My way is more interoperable, I think.

  124. jonas’

    I don’t think that applies in this case

  125. dwd

    Ge0rG, But yes.

  126. jonas’

    because the set of configuration options is already rather fuzzy

  127. Ge0rG

    dwd: I'm not sure I agree.

  128. Kev

    The set of config options is, but the set of config options you're allowed to include in pubsub#metadata isn't.

  129. Kev

    As there's a registry for that.

  130. dwd

    Ge0rG, You can do both, mind.

  131. Ge0rG

    But this is all a meta discussion because 0060 would overload my capacity today.

  132. jonas’

    Kev, a registry is mutable though

  133. dwd

    Kev, Registries are intended to be changed outside the XEP that defines them though.

  134. Kev


  135. Kev

    Yeah, I withdraw my -1.

  136. jonas’

    I think we’d have to formally re-vote given that the voting period is looong over

  137. Kev

    Shove it on next week's agenda, that gives me 7 days to have an excuse to be belligerent.

  138. dwd

    jonas’, I don't think we need to, actually. The wording in XEP-0001 isn't clear, but the phrasing suggests that a COuncil person withdrawing their objection is sufficient.

  139. dwd

    Happy to revote is people *want*, mind.

  140. jonas’

    I’d expect this to be more in hte bylaws than in '1

  141. dwd

    Happy to revote if people *want*, mind.

  142. jonas’

    but I don’t care a lot, i’m fine with just kev withdrawing the vote and we go ahead

  143. Kev

    Votes are cheap, I think the precedent of publishing something that was long ago vetod is not one to set.

  144. dwd

    jonas’, Nope, standards process, not by-laws.

  145. dwd

    Fair enough, I'll stick it on next week then.

  146. jonas’


  147. Kev

    Unless we want to +1 it now ,in which case +1.

  148. Kev

    But I'd rather just end the meeting on time :)

  149. dwd

    Yeah, even better.

  150. dwd

    Hah, too late:

  151. jonas’

    not yet ;)

  152. jonas’

    +1 wfm

  153. Ge0rG

    There are still AOBs.

  154. jonas’

    +1w wfm

  155. jonas’

    (too slow)

  156. Ge0rG

    I'm still +0

  157. dwd

    Well, given we've hit the half hour, I'll cut us short, but feel free to continue chatting.

  158. dwd

    6) Next Meeting

  159. dwd


  160. jonas’


  161. dwd

    7) Ite Meeting Est

  162. Ge0rG

    +2W for me.

  163. dwd

    Ge0rG, Noted.

  164. Ge0rG

    and it will be a +3W after that one.

  165. Ge0rG

    Technically, I'm not totally gone, but I'll most probably be in holiday mode away from a PC, and keeping up with Councils on a mobile is _hard_.

  166. dwd

    Ge0rG, Nice.

  167. jonas’

    Ge0rG, so you’ll be able to vote on-list?

  168. Ge0rG

    so back to #779. I actually wanted to ask Council whether we want to move on with putting normative language on The Right Thing into the XEP, or whether the fig leaf note box is the best trade-off I can get.

  169. Ge0rG

    jonas’: given that I'll be gone for two weeks, and the two week voting period, I'm much confident that yes.

  170. jonas’

    very good

  171. edhelas


  172. edhelas

    so let's see the vote next week then :)

  173. Ge0rG sobs for his AOBs