XMPP Council - 2017-01-18


  1. Link Mauve

    Hmm, I will be on a coach today during the meeting, I don’t know if they have wifi there so I might be unable to join. :/

  2. Tobias

    Link Mauve, thanks for letting us now :)

  3. Dave Cridland

    Link Mauve, https://www.youtube.com/watch?v=TiBI3A2WcrE

  4. daniel

    I wont be able to attend either.

  5. Tobias

    seems it's about time

  6. Tobias

    1) Roll call

  7. SamWhited waves

  8. Tobias

    Link Mauve and daniel sent apologies earlier today

  9. Tobias

    Dave Cridland?

  10. Tobias

    .

  11. Dave Cridland

    Hiya

  12. Tobias

    2) Minute Taker

  13. Tobias

    happy to do it if nobody else wants

  14. SamWhited

    I'll do it

  15. Tobias

    ok

  16. Tobias

    3) Move XEP-0153: vCard-Based Avatars to "Obsolete"

  17. Tobias

    seems the discussion pretty much died

  18. Tobias

    but hey..let's vote anyway

  19. Tobias

    -1

  20. SamWhited

    +1

  21. Dave Cridland

    I think there's no concensus to do this, so -1.

  22. Dave Cridland

    Ugh. Consensus.

  23. Dave Cridland

    Actually I don't even know how to spell anything at all today.

  24. Kev

    'anything'

  25. SamWhited

    Dave Cridland: Not to worry, that's me every day :)

  26. Tobias

    the rest will vote on list, if they want to i assume

  27. Dave Cridland

    What about the 'at all'? See? Fraught with complexity.

  28. Tobias

    4) XEP-0300 fixing, and Jingle FT

  29. Tobias

    according to latest news, Swift does Jingle FT :4 with base64 and Salut-a-toi does Jingle FT :4 with hex encoding

  30. Tobias

    everyone in agreement that bumping versions, fixing examples and explitly specifing what encoding to use is the right way to go from here?

  31. Dave Cridland

    Which namespaces are getting bumped?

  32. Dave Cridland

    Jingle FT *and* hashes?

  33. Tobias

    Jingle FT and hashes, yes

  34. SamWhited

    +1 for namespace bump and specifying an encoding

  35. Dave Cridland

    Does Jingle FT need it? I thought bumping hashes would be sufficient?

  36. Link Mauve

    Dave Cridland, that was my understanding too.

  37. Tobias

    Kev suggested this would be neede

  38. Tobias

    *needed

  39. Link Mauve

    I found some wifi at the first stop, but no wifi in the coach itself. :(

  40. SamWhited

    You'd have to bump the version that Jingle FT used for hashes, wouldn't that break Jingle FT compatibility if two things were advertising ft:4 but using different hashes versions?

  41. SamWhited

    So I think that means you'd have to bump FT too

  42. Kev

    What Sam said.

  43. Kev

    Unless he and I have both misunderstood Jingle FT.

  44. Dave Cridland

    Does Jingle FT mandate hashes? I thought they were optional.

  45. SamWhited

    "REQUIRED when offering a file, otherwise OPTIONAL"

  46. Tobias

    Kev, although XEP-0300 version is discoverable via caps, so clients could send the version the other side supports

  47. Dave Cridland

    Ah, no, REQUIRED when offering.

  48. Dave Cridland

    Also, it requires a specific namespace.

  49. Dave Cridland

    So yeah, bump away.

  50. Link Mauve

    Indeed, then +1 to bumping both.

  51. Tobias

    ok..great

  52. Tobias will prepare the required PRs over the week

  53. Tobias

    5) Sam's elaborate topic "A bit late, but let's have a vote on moving the 2016 compliance suite forwards. Even if we get vetoes or people think it doesn't make sense, that will give me a place to start on changes to the 2017 ones."

  54. Tobias

    i think it'd make more sense to ship out a compliance suite XEP for 2017 at this point

  55. SamWhited

    heh, sorry, that description got a bit out of hand

  56. SamWhited

    In that case, what differences should there be for 2017?

  57. Dave Cridland

    Um. I'll have to go on list for this. But I don't *think* 2016 is ready, quite, yet from what I recall.

  58. Tobias

    SamWhited, my idle XEP..but yeah...i'll post more on the list

  59. SamWhited

    Sounds good; I'll start a list topic about what we want for a 2017 list then, and people can reply with fixes there.

  60. SamWhited

    Unless someones already done it or is drafting an email, in which case I'll wait for that

  61. Tobias

    SamWhited, sounds like a plan

  62. Tobias

    6) Accept https://xmpp.org/extensions/inbox/bind2.0.html as experimental

  63. SamWhited

    One more thing

  64. SamWhited

    before we move on

  65. Tobias

    ok

  66. SamWhited

    On this topic: can we go ahead and deprecate the 2010 ones and just not have compliance suites for a bit? I still feel like it's confusing to have them hanging around when we have no new alternative and many of the things in them are probably out of date.

  67. SamWhited

    Especially if we're going to be starting over again on 2017 ones which will presumbaly take a while to get right.

  68. Dave Cridland

    Is no current compliance suite better than an out of date one?

  69. SamWhited

    I think so

  70. Tobias

    SamWhited, probably makes sense...although i think we should have at least a new one before deprecating the old one

  71. Dave Cridland

    I think I'd want to review them again to understand why.

  72. SamWhited

    We've had a new one for a while, it just didn't get advanced. I suspect a new-new one would be the same way

  73. SamWhited

    If 2010 (or whatever it is) is up to date, I think it's fine, but otherwise I think it's better to have no recommendation than to have old ones that may be wrong

  74. Tobias

    SamWhited, true...the 2016 is experimental, so fine my be deprecating the 2010 one

  75. Dave Cridland

    I don't think they're likely to be wrong. But in any case, I'll review and get back to you.

  76. SamWhited

    I wouldn't want someone to go implement, eg. SI file transfer or something if everything is moving to Jingle just because they saw it in an old document

  77. SamWhited

    Yah, if they're not wrong I suppose it's fine to leave them

  78. SamWhited

    I haven't actually looked; although it still looks bad that the current up to date recommendations are from 2010

  79. SamWhited

    Might be better to deprecate just for image

  80. Tobias

    SamWhited, any other points on that topic?

  81. SamWhited

    Nope, that's it. Thanks.

  82. Tobias

    6) Accept https://xmpp.org/extensions/inbox/bind2.0.html as experimental

  83. Kev

    "I wouldn't want someone to go implement, eg. SI file transfer or something if everything is moving to Jingle just because they saw it in an old document" Sounds sound to me, FWIW.

  84. SamWhited

    (note that I'm not sure that SI File Transfer is in there; that was just the first thing that was sort of superseded that came to mind)

  85. SamWhited

    +1 to accept bind 2.0

  86. Dave Cridland

    +1 on Bind 2.0.

  87. Dave Cridland

    SamWhited, It isn't.

  88. Tobias

    +1, although it's missing tons of specific references to the standards and extensions it talks about

  89. Dave Cridland

    SamWhited, The only "old" thing is Privacy Lists.

  90. SamWhited

    Dave Cridland: I definitely think we should deprecate it then

  91. Dave Cridland

    SamWhited, Only applies to Advanced Server, actually.

  92. Tobias

    7) Deferring lots of XEPs

  93. Tobias

    SamWhited, why did you put that on the agenda?

  94. SamWhited

    Just wanted to mention that I'd done this in the notes (in case it wasn't obvious)

  95. Dave Cridland

    Tobias, I think he likes deferring things and has run out?

  96. SamWhited

    If you notice anything wrong, or want to push something forward please do so

  97. SamWhited

    I do like deferring things :)

  98. Tobias

    we used to have a calendar that had the dates in for when XEPs expire or are deferred

  99. Tobias

    but people thought we needed a new website instead :P

  100. SamWhited

    Zash suggested a bot that deferred things automtaically; I doubt anyone has the bandwidth, but I liked the idea

  101. Tobias

    ok..guess that's noted then

  102. Tobias

    8) Consider advancing XEP-0333: Chat Markers to LC

  103. SamWhited

    Related; this is the only deferred thing that stood out to me as in wide spread use (I think?) and that hasn't been changed because it appears to be working.

  104. Tobias

    is it in wide spread use?

  105. Kev

    Is it in widespread use? :)

  106. SamWhited

    I thought so? Conversations does it anyways, and I tend to see it for all my contacts (only a few of which use Conversations), but I don't have a lits.

  107. Dave Cridland

    Is it in... Oh, wait.

  108. SamWhited

    Maybe no action is necessary

  109. Dave Cridland

    LC it. If it's good enough to implement, and seems to be working, it's probably ready for a Last Call.

  110. Dave Cridland

    And if nobody responds and/or people flag issues, then that was what LC was for.

  111. Tobias

    happy to LC it , yes

  112. Dave Cridland

    In particular, "widespread use" is for Draft->Final, really, not Experimental->Draft.

  113. Kev

    Might be worth LCing 233 while we're at it.

  114. Dave Cridland

    Kev, Hmmm. Why is Mili's name not on that? She wrote/rewrote quite a chunk of that, didn't she?

  115. Tobias

    happy to have an LC on that too

  116. Dave Cridland

    Happy to LC it, mind. Just glanced at it and was surprised.

  117. Tobias

    9) Date of next

  118. Tobias

    same time next week?

  119. SamWhited

    Cool, I'll issue LCs on both of those then.

  120. SamWhited

    WFM

  121. Tobias

    wfm

  122. Dave Cridland

    Tobias, WFM, noting that I'll be travelling the week after.

  123. Tobias

    10) AOB (probably none because of all the discussions in between)

  124. Tobias

    no AOB it seems, YAY

  125. Tobias bangs the gavel

  126. Tobias

    thanks everyone

  127. SamWhited

    Thanks all!

  128. Tobias

    SamWhited, thanks for wrtiting up the minutes

  129. SamWhited

    sure thing; sent

  130. SamWhited

    actually, how does LC work? I guess that needs to be pending votes too

  131. SamWhited

    Or would the absentees just vote on the LC itself?

  132. Zash

    Or do they vote after the LC?

  133. SamWhited

    Process is hard.

  134. SamWhited goes to try and find a reference

  135. Zash

    To the XEP 1 machine!

  136. Tobias

    "Before an Experimental XEP may be proposed to the XMPP Council for advancement to Draft (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs), the XMPP Council must agree that the XEP is ready to be considered for advancement. Once the Council so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental to Proposed and (2) issue a Last Call for open discussion on the Standards list. The Last Call shall expire not less than fourteen (14) days after the date of issue."

  137. SamWhited

    "Once the council agrees", so I guess that needs a vote

  138. Tobias

    SamWhited, we first vote on it (probably the safest to show we're all in agreement)

  139. SamWhited

    Fixed; marking us all as +1

  140. Tobias

    SamWhited, so...let's vote on it next week?

  141. SamWhited

    Oh, or that; I'm doubly getting ahead of myself

  142. Tobias

    or do the minutes include a record for voting so others know they'll have to vote on it

  143. Tobias

    otherwise it'll look a bit odd

  144. Kev

    > Kev, Hmmm. Why is Mili's name not on that? She wrote/rewrote quite a chunk of that, didn't she? Probably because adding oneself to the author list is unseemly, and no-one else did it.

  145. SamWhited

    It says that we all agreed

  146. Tobias

    considering how long they were ignored one week more or less probably doesn't matter

  147. SamWhited

    yah, WFM

  148. Kev vanishes again