XMPP Council - 2017-12-06


  1. Kev

    'tis time, 'tis time.

  2. jonasw

    the harpie cries

  3. Kev

    1) Bread products!

  4. jonasw

    I gotta leave at 1630Z, so I won’t be able to properly take minutes

  5. Kev

    jonasw: I can do minutes, it's ok ta.

  6. Kev

    Dave sends apologies. daniel, Ge0rG, SamWhited - you here?

  7. jonasw

    two out of those have spoken in other MUCs just a few minutes ago :)

  8. Ge0rG here

  9. SamWhited

    I'm here

  10. daniel

    hi

  11. Kev

    2) 186 LC

  12. Kev

    I'm +1

  13. Kev

    (This is a re-issue because the last one expired without Council voting)

  14. SamWhited

    What are we voting on?

  15. SamWhited

    Oops, too slow

  16. SamWhited

    I don't think we have to vote on this; editor will just reissue the LC

  17. SamWhited

    (but +1 FWIW)

  18. Ge0rG

    +1 for LC

  19. Kev

    I think that's right, as it happens.

  20. daniel

    +1

  21. jonasw

    editor will take notice that this is the councils opinion and re-issue the LC sometime tomorrow, maybe tonight (or somebody besides me does it)

  22. Kev

    And same for

  23. Kev

    3) 352 LC

  24. Kev

    jonasw: More than Council's opinion, it's what xep1 says :)

  25. Kev

    4) Deprecating 84

  26. jonasw

    Kev, we could also simply move it back to experimental, couldn’t we?

  27. Kev

    No, xep1 says that if there's a vote that wasn't completed, the Editors will re-issue an LC.

  28. jonasw

    ah okay

  29. Kev

    So, deprecating '84, which I think was Link Mauve's request.

  30. Kev

    (That's pubsub avatars, for anyone who needs to know)

  31. daniel

    has there been any argument on why?

  32. Ge0rG

    I haven't yet compared pubsub avatars to vcard avatars, so I'm impartial.

  33. jonasw

    IIRC, vcard works today

  34. Kev

    It just appeared on the Council board without an argument why.

  35. jonasw

    IIRC, the argument was "vcard works today"

  36. Kev

    Link Mauve can probably say why, though.

  37. Ge0rG

    jonasw: weren't there special cases where vcard doesn't work in MUCs?

  38. Kev

    Ge0rG: none that PEP does work in, I think.

  39. SamWhited

    I'd prefer to deprecate 0153. 0084 has its problems, but seems like a better more future-compatible platform, but I don't care as long as we move towards a single way to do avatars.

  40. Ge0rG

    0153 is Historical already.

  41. Kev

    Indeed, deprecating 153 is likely not the right thing to do.

  42. SamWhited

    I disagree; it appears right now that we're recommending two different ways to do avatars, which seems to be the main problem here to me.

  43. Kev

    I'm not convinced that we should be deprecating 84. I'm -1 for the moment, but in the minutes I'll invite an argument why it should happen.

  44. Kev

    No, I mean that a Historical XEP doesn't need deprecating, because of its nature :)

  45. Kev

    (Although we can do so, certainly)

  46. Ge0rG

    SamWhited: which are the two? 84 and 153?

  47. SamWhited

    Ge0rG: Yes

  48. Ge0rG

    SamWhited: and where are we recommending 153?

  49. Ge0rG

    (and for what reasons)

  50. daniel

    and the other two :-)

  51. SamWhited

    It's got a big green block of text that says "This is draft" at the top

  52. Kev

    Ge0rG: We're not, but it's the de facto standard.

  53. jonasw

    (which I learnt the hard way which I find annoying)

  54. Kev

    Anyway, with one -1 in place, let's gather votes for this and move on.

  55. daniel

    -1

  56. Ge0rG

    387 goes with 84, so it might be not smart to deprecate it.

  57. SamWhited

    Sounds good; I'll discuss on list if necessary.

  58. Kev

    SamWhited: "sounds good" is voting which way?

  59. Kev

    Same question for contestant number Ge0rG.

  60. Ge0rG

    -1 for now, until reasons for deprecation are provided

  61. SamWhited

    Kev: "let's move on" sounds good, I mean. On list.

  62. Kev

    Ta.

  63. Kev

    5) Reverting 48 to 49

  64. Kev

    That's reverting bookmarks to iq:private instead of private pubsub.

  65. daniel

    is there an argument on why?

  66. SamWhited

    I'm not sure why this one was brought up either; is there a problem with them as they are today?

  67. Kev

    This isn't a voting point, because there's no vote to be made.

  68. jonasw

    I did

  69. Kev

    But let's discuss.

  70. jonasw

    the argument is that the change from private XML to pubsub happened in draft state, which is a major breakage of the protocol. many deployments are still on Private XML

  71. jonasw

    which is indiscoverable to new developers

  72. Kev

    jonasw: So it's a point of process?

  73. jonasw

    no, also a point of usability by developers

  74. Ge0rG

    I think deployments are on private XML because some major XMPP server implementations lack persistent PEP.

  75. Kev

    I think 'indiscoverable' is pushing it a bit, when the XEP says this explicitly.

  76. jonasw

    so the point is, as a new developer, you see the XEP, you think "neat, PEP", implement it, and find no bookmarks

  77. Kev

    I think private pubsub is a better mechanism to be storing these data than iq:private, so reverting to say it should be iq:private seems wrong, and the XEP already says that existing implementations do iq:private, so implementors know that they'll want to consider at least read access to it.

  78. jonasw

    I agree that it is a better mechanism.

  79. Kev

    jonasw: Except you wouldn't, because the XEP notes that people used to do iq:private.

  80. jonasw

    "used to do" implies that it isn’t that way anymore

  81. jonasw

    and also, only read access isn’t sufficient, because there are enough clients and servers out there which still can only do private XML

  82. Ge0rG

    So maybe we should extend 48 with a compat behavior spec?

  83. Ge0rG

    0387 does not enforce the type of backend storage.

  84. Kev

    I think the note that we used to recommend iq:private is sufficient, but we could add an extra sentence to say "and it's still widely used" if it'll make people feel better, and then new implementors are forewarned.

  85. Ge0rG

    We might add both 49 and 223 to 0387 as well

  86. Kev

    But I don't think that saying "you SHOULD use iq:private" instead of the better private pubsub mechanism is right.

  87. SamWhited

    Agreed

  88. Ge0rG

    Kev: in theory, you are right. In practice, implementations of private pubsub will learn about the lack of persistence, the hard way.

  89. jonasw

    Kev, I agree with your second part, I disagree with the precedent this change sets

  90. Ge0rG

    ...of private pubsub bookmarks

  91. daniel

    Ge0rG, more importantly the implementation you are talking about doesn't support making the node private

  92. Kev

    Ge0rG: I am not inclined to avoid doing the Right Thing here because one (popular!) server implementation doesn't have a feature.

  93. daniel

    which arguably is the bigger issue

  94. Kev

    Else we end up with all our XEPs saying "But instead you need to do X for Prosody".

  95. Ge0rG

    Kev: apparently we can not force implementations to do anything.

  96. jonasw

    I gotta run, see you later

  97. Kev

    I don't think I've successfully forced anyone to do anything in my life :)

  98. Kev

    Thanks Jonas.

  99. Ge0rG

    I'm not arguing in favor of "you SHOULD use iq:private", merely pointing out that usage of iq:private is self-reinforcing.

  100. Kev

    It is, certainly.

  101. Kev

    But not all deployments are based on Prosody.

  102. Kev

    I suggest that someone proposes an additional line as I did above to 48, and we vote on that once it's done.

  103. Kev

    I can do that.

  104. Ge0rG

    Kev: please do.

  105. Kev

    Moving on

  106. Kev

    6) Date of next.

  107. Kev

    I can't do next week, and I possibly can't do anything else until the new year, at this point, but will vote on list.

  108. Kev

    Does everyone else want to SBTSBC?

  109. SamWhited

    WFM

  110. Ge0rG

    +1W WFM

  111. Kev

    daniel?

  112. daniel

    next week works for me

  113. Kev

    7) AOB

  114. SamWhited

    I would like to ask that we vote on XEP-0286: Mobile Considerations for LTE Networks (or pull it in next week)

  115. SamWhited

    It's been sitting in the proposed agendums for a few weeks

  116. Kev

    I only grabbed for the Agenda today what Dave'd put on it, so I've not reviewed (and assume no-one else has) 286 and trying to vote on it now would be unhelpful.

  117. Kev

    So I propose I drag it to the Agenda for next week, and we look at it then.

  118. SamWhited

    Works for me; thanks.

  119. Kev

    Anything else?

  120. Kev

    Looks like not. Thanks all.

  121. Kev gangs the bavel

  122. SamWhited

    Thanks Kev

  123. Ge0rG

    Thanks Kev

  124. SamWhited

    Would anyone complain if I removed the "For Editors" column and asked people to move them straight to the editors board's TODO column? That way editors can get alerts

  125. SamWhited

    Everyone *should* have access to the editors board if you're already on the council one

  126. Kev

    I think it only affects Dave and the Editors.

  127. Kev

    Maybe check with him, but it seems sensible to me.

  128. SamWhited

    *nods* going to do it and if he doesn't like it or doesn't have access he can always unarchive it next week

  129. Ge0rG

    "Dave and the Editors" sounds like an awesome name for a Punk band.

  130. moparisthebest

    sounds boring

  131. moparisthebest

    "and then he consulted XEP-0001 for the proper procedure, dum dum dum"

  132. moparisthebest

    it sounds like blues in my brain

  133. Kev

    https://github.com/xsf/xeps/pull/554 - 48 patch.

  134. Ge0rG

    Kev: 👍