XMPP Council - 2014-02-05

  1. Tobias

    anything on the agenda for today?

  2. fippo

    i have "talk about deprecating the compliance suite" on my list and _think_ i poked kev about adding it to the agenda

  3. Tobias

    okay...sounds reasonable

  4. Kev

    You did.

  5. Kev

    It's time.

  6. Kev


  7. Kev

    I'm here.

  8. fippo


  9. Tobias


  10. Lance


  11. Kev

    Matt sends apologies.

  12. Kev

    2) Compliance suites.

  13. Kev

    Should we be deprecating 270?

  14. fippo

    i'd say yes because it requires 3920 and 3921. which are obsoleted by 6120 and 6121

  15. ralphm


  16. Lance


  17. Tobias


  18. Kev

    ralphm: Don't you try and sneak your filthy votes in :p

  19. Kev

    And yes, I agree.

  20. fippo

    the more tricky question is how we replace it. we have http://xmpp.org/extensions/xep-0302.html (comp suites 2012)

  21. Kev

    What about 305, or whatever the replacement was?

  22. Kev

    302, OK :)

  23. fippo

    302 is a better starting point at least. my feeling is that we need something along the lines of "if you're a mobile client, then you should implement..."

  24. Lance

    yes, I'd be +1 to getting 302 active when we deprecate 270

  25. ralphm

    Kev: heh

  26. Tobias

    fippo, mobile client column?

  27. fippo

    "if you're a web client then...", "if you're a jingle client..."

  28. fippo

    tobias: more like different tables

  29. Tobias

    if we're improving 302 we should at least change its name

  30. ralphm

    no kidding

  31. Kev

    I think that would be sane.

  32. ralphm

    I'm wondering if a year is a good differentiator, but don't have a better idea

  33. ralphm

    You'd not moving targets

  34. ralphm


  35. stpeter

    why not remove the year?

  36. Kev

    stpeter: Because then you have to target versions, or XEP numbers.

  37. fippo

    well, if someone prints a flyer, they want a stable reference

  38. stpeter

    just "XMPP Compliance Suites"

  39. stpeter

    Kev: right, but we can reference the XEP number I think

  40. Kev

    We could do XMPP Compliance Suite and obsolete the old one and publish a new one with the same name every time, but that seems icky somehow.

  41. Lance

    In future, I'd say a better approach would be to make xmpp.org/extensions be able to display XEPs by use-case category

  42. stpeter

    "XEP-0302 compliant"

  43. ralphm

    you'd want to refer to a specific one? The document version?

  44. Kev

    It seems to me, without much consideration, that it's not a bad thing in 2014 to say you're compliant with the 2012 compliance suite.

  45. stpeter

    the alternative is that we commit to updating them every year :-)

  46. Tobias

    Lance, nice idea

  47. stpeter

    Kev: hmm, you're probaby right

  48. Kev

    It gives people a feeling how current the document is.

  49. stpeter

    (and then we update it whenever we think that's needed)

  50. Kev

    I don't feel so strongly about this that I'll fight rough consensus.

  51. Kev

    stpeter: By 'update' you mean 'publish a new year's'?

  52. stpeter


  53. Kev

    This seems sanest to me.

  54. ralphm

    Does it? If something doesn't change, is it stale?

  55. Kev

    ralphm: No, and I don't think that is implied.

  56. stpeter

    if we decide that 2012 is out of date, we start work on a new one to supersed the old

  57. Tobias

    Kev, and old ones get deprecated if new ones reach draft?

  58. ralphm


  59. Kev

    ralphm: But it gives someone in 2014 who doesn't support the 2014 profile yet a bit of a get-out as to why they still support 2012 only.

  60. ralphm


  61. Zash

    Perhaps drop the year and just replace the xep with a new one?

  62. ralphm


  63. ralphm

    I'd include the year then

  64. Kev

    Zash: That was suggested, and I prefer keeping the year, really. I don't see a strong argument against the year, other than it might make us look inactive if we skip a year - but I don't really believe that's true, either.

  65. stpeter nods to Kev

  66. Zash


  67. Kev

    We're not committing to providing a new suite every year, we're committing to saying that every time we think there's a change in the baseline required for XMPP, we'll release a new one and date it.

  68. Lance

    Kev: +1 on that statement

  69. ralphm


  70. stpeter

    then we just need some text that says "this is the latest compliance suite and it will be replaced by a new one when the need arises"

  71. Tobias

    yup...with a year it's also nicer to reference....as been said, without it you'd need to refer to the version all the time (the year would be some kind of higher version)

  72. Kev

    stpeter: This seems entirely reasonable to me.

  73. ralphm

    Not +1, because Kev gets confused, but I agree

  74. Tobias

    stpeter, +1 for some text like that

  75. Kev

    ralphm: Very kind, sir.

  76. fippo

    '+1 as well. i dont even think we need to immediately deprecate an old suite. only when it gets obsolete for some reason (as happened to the 2010)

  77. Kev

    fippo: Well, there's multiple states here we could use.

  78. Kev

    And, it's a bit of a shame that we always go through Deprecated to get to Obsolete.

  79. Kev

    Because for compliance suites we probably want to go straight to Obsolete.

  80. Zash

    Why are they Standards Track?

  81. Tobias

    Kev, to change that process we'd need to change some icky ascii art, right? :)

  82. ralphm

    you don't have to imo

  83. Kev

    There's no problem with implementing an old compliance suite, so they're not logically deprecated, but they are obsolete :)

  84. fippo

    no. e.g. the 2012 ones would be deprecated by 2014 whereas the 2010 ones should be obsoleted

  85. Kev

    fippo: I don't think that releasing 2014 means there's anything actively wrong with 2012, which is what deprecated means.

  86. ralphm

    If Council decides it goes to Deprecated and immediately to Obsolete, that's fine

  87. Kev

    Deprecated means Do Not Do This.

  88. fippo

    kev: good point.

  89. Kev

    Obsolete means This Is Not Relevant Any More.

  90. ralphm

    The old one will be marked as superseded, obsolete seems proper

  91. ralphm

    We should maybe make that explicit in the red heading

  92. fippo

    speaking of which, didn't we discuss that heading a while back...?

  93. Kev

    fippo: We did.

  94. Kev

    Does everyone think we're done with compliance suites for the moment.

  95. Kev


  96. ralphm

    yes previous council did

  97. Lance

    If we need to, we should update XEP-1 to make this route OK. I know we've gone straight to obsolete before though, for roster versioning xep, etc

  98. ralphm

    I don't see a reason to change XEP-0001

  99. Kev

    A Standards Track XEP that has been advanced to a status of Final may be superseded by a future XEP approved by the XMPP Council. In such cases, the status of the earlier XEP shall be changed to Deprecated, possibly with an expiration date assigned by the XMPP Council (see the Expiration Dates section below). After a reasonable period of time or upon the passing of the expiration date, the status of the XEP shall be changed to Obsolete.

  100. ralphm

    just vote to do two steps at once

  101. Kev

    So if we feel that the reasonable period of time is measured in nanoseconds, we're golden.

  102. Lance

    awesome :)

  103. stpeter


  104. Tobias


  105. ralphm


  106. Kev

    I think we're done on compliance suites. Including that we have voted to Obsolete 270?

  107. Lance


  108. Tobias


  109. fippo


  110. ralphm


  111. Kev


  112. ralphm

    (oops, did it again)

  113. Tobias

    he did it again

  114. Zash


  115. Kev

    3) Date of next. SBTSBC?

  116. ralphm

    old habits die hard

  117. Lance


  118. Tobias


  119. fippo

    wfm too

  120. Kev

    Jolly good.

  121. Kev

    4) AOB?

  122. stpeter

    did the Council vote on XEP-0152?

  123. stpeter

    the last call ended on January 31

  124. stpeter notes that he needs to get the Editorial Team up and running so that things don't fall through the cracks quite as often

  125. Kev

    Nope. I think perhaps with the new Editor team we should formalise whether they're going to keep track of LCs or Council is.

  126. Kev

    My vote is, of course, that they track them and poke Council to vote on them.

  127. ralphm

    Council IMO

  128. stpeter

    Kev: I'm fine with that -- the team can request agenda items

  129. Kev

    I note that at the summit I asked a room full of XSF members to raise their hand if they were not volunteering for the Editor team, and no-one did. So every XSF member present who isn't already on Board or Council has volunteered to join that team :)

  130. ralphm


  131. Kev

    I'm not quite sure why people then started calling me Evil Kev.

  132. Tobias

    *phew* ;)

  133. stpeter

    Kev: we could all learn from your management style :-)

  134. ralphm

    we had sufficient applications, I think

  135. Kev

    ralphm: Yes, I think so.

  136. stpeter

    ralphm: yes, I will schedule an organizational meeting next week

  137. Kev

    I /think/ that we decided that Council would then select from that pool, but I should check.

  138. stpeter

    that's my recollection

  139. stpeter

    we need to get the UPnP liaison team going, too

  140. Kev

    (I anticipate Council's selection being "You want to do it, good [man|woman|other]".

  141. Kev

    Yes, I have a TODO to chat to you.

  142. stpeter


  143. Kev

    I think we've not got AOB, but we do have 152 for the agenda next week.

  144. stpeter

    sounds good

  145. fippo

    evil kev: does tobias get to "vote" on the resolution we made at the non-official impromptu meeting on wednesday evening?

  146. Kev

    fippo: I think simple majority works there.

  147. Kev


  148. Kev

    Thanks all, I think we're done.

  149. Kev bangs the gavel.

  150. ralphm


  151. Tobias


  152. Kev

    (The informal Council vote in question was "Should Council decide to be evil?" it passed with 4/5 of Council present :))

  153. Tobias

    4/5 votes yes, let's be evil or no?

  154. stpeter tries to figure out why he can log into his personal server with Gajim but not Adium

  155. Tobias

    stpeter, just blame xnyhps :)

  156. ralphm


  157. stpeter

    well, Adium would connect yesterday, but not today :-)

  158. Tobias

    maybe an easteregg

  159. stpeter

    I suppose I ought to join the xsf@ chatroom, eh?

  160. Zash

    stpeter: Security feature?

  161. ralphm

    stpeter: yes please

  162. ralphm

    Board meeting in a few minutes