XMPP Council - 2021-08-11

  1. daniel


  2. Ge0rG

    I've heard it's that special date and time again, but I'm still on the run

  3. Zash

    My gosh, is this the time?

  4. daniel

    Do we have a jonas’?

  5. Dave Cridland


  6. Zash

    Dun dun duuun

  7. jonas’

    1) Roll Call

  8. jonas’


  9. jonas’

    thanks Zash for poking me

  10. Zash

    Here. Full house?

  11. jonas’

    I was sunken deeply in the horrifying lecture which is https://counterexamples.org/

  12. jonas’

    either way, welcome everyone

  13. jonas’

    2) Agenda Bashing

  14. jonas’

    this time, it was not a late agenda, which is good and surprising given the chaotic day I had yesterday. I don't even remember much of writing it :)

  15. jonas’

    please complain about anything which might be missing inline and asap

  16. jonas’

    3) Editor's Update

  17. jonas’

    Pubsub Caching Hints have been accepted as New as per council vote

  18. jonas’

    also, the moved 2.0 protoxep has been merged into '283 and authorship has been transferred to MattJ as discussed

  19. jonas’

    4) Items for Voting

  20. jonas’

    None, as far as I know.

  21. jonas’

    5) Pending votes

  22. jonas’

    - Georg on ProtoXEP https://xmpp.org/extensions/inbox/disco-feature-attachment.html

  23. jonas’

    I note that there has been some discussion on list about this

  24. jonas’

    I think Stephen makes some valid points

  25. jonas’

    but there was also more discussion in xsf@ and my personal take away is that the proposal isn't really sensible after all

  26. Zash

    "the proposal" = the protoXEP or what was posted to the list?

  27. jonas’


  28. daniel

    fwiw i never "liked" the XEP. but i think it's speced out well enough to deserve being an experimental xep

  29. Dave Cridland

    I thought it seemed quite sensible for RSM (and needed), and I was willing to see how the Generic version played out.

  30. daniel

    just be careful with implementing it and more careful with referencing it from other xeps

  31. jonas’

    -1, my rationale being the following, but I can be persuaded: - Any disco#info feature needs to be backed by some kind of implementation text - Even though for some combination of features the implementation may be obvious, it should still be written down somewhere, because obvious doesn't really work - If there is text backing the implementation of a combination of two features, that is the obvious place to declare a disco#info feature string - If there is a place where a disco#info string is written down which needs to be read by implementors anyway, there is no benefit from having a way to construct such a string; an opaque string match is required in the implementation anyway.

  32. jonas’

    and to bring this to the point which IMO makes this -1-worthy: it misleads implementations and specification authors to think that they can just slap together two feature strings and it will be immediately clear what is supposed to happen there.

  33. daniel

    i (mostly?) agree with your points. to me this doesn’t necessarily warent a -1

  34. Ge0rG

    I'm with jonas’, plus introducing @ as a special character in an otherwise opaque identifier is kinda evil

  35. daniel

    but i respect your choice to veto

  36. jonas’

    daniel, I may be over the line here, however, I think this may be actievly harmful

  37. jonas’

    at the same time, I acknowledge that we need to solve the issue that an entity declaring RSM and an entity declaring e.g. MAM or PubSub or '0030 is not clear about how and where RSM is supported

  38. jonas’

    I think the discussion in xsf@ about this has been guiding in the sense that it became clear in which documents those specific cases need to be addressed (if at all -- I think MAM clearly references RSM already and hard-depends on it, so MAM feature implies RSM anyway)

  39. Ge0rG

    Yeah, it creates a precedent for a really bad practice. In the end, somebody will add a matrix of all possible combinations of main feature × supporting feature

  40. Dave Cridland

    Well, certainly this could be solved more immediately by a set of RSM+Pubsub (etc) features.

  41. Zash

    So the root problem is signaling optional dependencies?

  42. daniel

    fair. (it once again boils down to what experimental means)

  43. jonas’

    Zash, I think so

  44. jonas’

    Zash, because for mandatory dependencies it doesn't matter.

  45. jonas’

    in the end, RSM should never have had a feature string :)

  46. Ge0rG

    Or by requiring MAM to support RSM without a distinct disco feature

  47. Zash

    Yeah, you don't need to advertise something that is implied by e.g. the MAM feature.

  48. jonas’

    I'm going with -0, because I may be wrong about this and Experimental may still be a place for it. I'll post my concerns on the list so that others can weigh in.

  49. jonas’

    Ge0rG, your vote please.

  50. Zash

    Maybe this should be turned into an Informational XEP, as I think was mentioned in xsf@

  51. jonas’

    Zash, even that is not useful in my opinion

  52. Ge0rG

    Zash: I don't like that idea

  53. Dave Cridland

    Zash, I don't think that really solves anything.

  54. Dave Cridland

    I am finding myself swayed by your arguments,here, jonas’ + Ge0rG.

  55. Ge0rG

    jonas’: -0 from me as well, because I fully agree that we need explicit wording for optional dependencies, where we easily can define their own feature during

  56. Ge0rG

    jonas’: -0 from me as well, because I fully agree that we need explicit wording for optional dependencies, where we easily can define their own feature string

  57. Zash

    General guidelines for advertising support for optional use of other XEPs, whether by "X@Y" or "Y#x"

  58. Ge0rG

    Zash: maybe that's something where an editor can easily change the strings during submission?

  59. jonas’

    I think introducing some kind of "syntax" is useful for the humans in the XMPP stack.

  60. jonas’

    even if no code can make automated decisions based on the syntax

  61. Dave Cridland

    I think this is a problem that needs addressing for RSM, for sure. But the generic nature of this approach is a bit of a risk.

  62. jonas’


  63. jonas’


  64. Ge0rG

    Somebody would have to go through all of our existing XEPs to check for prior art

  65. jonas’

    it seems that this discussion has become a bit complicated. shall we prolong our voting period by another week?

  66. jonas’

    I am currently typing a long email in response to the thread to involve the author in this

  67. Dave Cridland

    SO I'm wondering about switching to veto, with a resolution of removing the generic nature of this - that is, make it explicitly about RSM and making each feature explicitly defined, and then I think that addresses all our concerns "for now"?

  68. Ge0rG

    Also there is the mess called 0045

  69. jonas’

    Dave Cridland, that's kind of what I'm going to propose on-list anyway, so go for it IMO

  70. jonas’

    Ge0rG, what's got '45 to do with this?

  71. Zash

    Combinations of things?

  72. Dave Cridland

    I'll change to veto then. I think that leaves open a generic solution if one seems needed.

  73. jonas’

    ACK thx

  74. Ge0rG

    jonas’: inconsistently named optional features

  75. jonas’

    Ge0rG, doesn't matter, opaque strings ;)

  76. jonas’

    but yeah

  77. jonas’

    okay, last call for votes on this protoxep because we all did a lot of switcheroo here

  78. jonas’

    daniel, Zash, any changes?

  79. Zash

    Good arguments, so -0 I think?

  80. Zash

    Or hold until the list discussion comes to a conclusion

  81. daniel

    yeah. it doesn’t matter; but i'm fine with rejecting it after hearing the arguments

  82. daniel

    it=my vote

  83. jonas’


  84. jonas’

    thanks all

  85. jonas’

    I'm going to write an extensive email into the thread to explain all this to the author and also to singpolyma

  86. jonas’

    6) Date of Next

  87. jonas’

    +1w wfm

  88. Zash

    +1w wfm

  89. Dave Cridland

    +1w wfm

  90. daniel

    +1w wfm

  91. Ge0rG

    +1W WFM

  92. jonas’

    7) AOB

  93. jonas’


  94. Dave Cridland

    Not from me.

  95. jonas’

    nobody else is moving so

  96. jonas’

    8) Ite Meeting Est

  97. jonas’

    thanks everyone

  98. jonas’

    I'm going to write the email in the thread and compile minutes :)

  99. daniel

    thanks jonas’

  100. Dave Cridland

    Thanks jonas’ !

  101. jonas’

    mail sent in that thread, minutes sent, thanks everyone.

  102. jonas’ dives back into "Counterexamples"

  103. Zash dives into a bag of potatoes

  104. mdosch

    Bag? You bought them? I thought your growing them in the woods.

  105. jonas’

    mdosch, and how do you collect them if not in a bag?

  106. mdosch

    Hmm, treu.

  107. mdosch

    Hmm, true.

  108. Kev

    FWIW, I think veto was the right call, and Jonas has roughly repeated the points I tried to make in xsf@ the other day, more elloquently

  109. Kev

    (Jonas than me)