XSF Editor Team - 2015-10-15

  1. m&m waves

  2. SamWhited nods

  3. stpeter


  4. m&m

    yet another RFC with your name on it

  5. stpeter

    and you :-)

  6. stpeter

    I still have 3 I-Ds to submit before the cutoff on Monday, sigh

  7. m&m

    do you want to skip on editor stuff then>

  8. m&m


  9. stpeter

    it's OK, let's make some progress

  10. m&m


  11. m&m

    first, something we're going to need to address

  12. m&m

    Kev found what he feels are substantive changes in XEP-0030

  13. m&m

    around how xml:lang factors into uniqueness

  14. stpeter

    right, I saw a message about that somewhere

  15. stpeter

    did we track down the check-in that modified this?

  16. m&m

    yes, sometime back in 2008

  17. stpeter

    this paragraph, eh? "Each <identity/> element MUST possess the 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity; the <identity/> element MAY also possess a standard 'xml:lang' attribute, which enables the entity to return localized results if desired (i.e., the <query/> element MAY include multiple <identity/> elements with the same category+type but with different 'xml:lang' values, however the <query/> element MUST NOT include multiple <identity/> elements with the same category+type+xml:lang but with different 'name' values)."

  18. m&m


  19. m&m


  20. Kev

    I think I suggested list discussion, mostly (disclaimer, I'm ill today, not firing on all cylinders).

  21. Kev

    Just to check we weren't about to include a substantive change without discussion.

  22. Kev

    It looks like the change in question was ages old, but never included in a new revision.

  23. Kev

    And at some point it accidentally got regenerated into the current version, like the 313 stuff.

  24. stpeter

    I'd need to review the discussion list history from June of 2008

  25. stpeter

    and earlier

  26. stpeter

    perhaps this was discussed as part of the run-up to 2.4 but was left out somehow.

  27. Kev

    I didn't do that. But yes, that would be sensible.

  28. stpeter

    I can't recall.

  29. Kev

    I think I did a search of my mail archives for likely-looking queries and didn't find anything, but maybe I'm mistaking it for something else.

  30. Kev

    Anyway - my block was the temporary check-we-don't-accidentally-break-something type, not the this-must-not-happen type.

  31. stpeter

    I don't have a quick answer.

  32. Kev

    I'm not sure that -1s are the appropriate mechanism here, but I don't think we have anything else available to say "Oh, wait, a minute, before we do that...", because otherwise the votes expire and it runs through on majority.

  33. stpeter

    I might have been thinking this was a sensible clarification, I might have received some implementation feedback asking for clarification, it could have resulted from discussion about XEP-0115 somewhere, etc.

  34. Kev

    -1 on something that seems broadly right feels wrong, but there we go.

  35. m&m

    I'm now thinking of XMP Council's -1 as equivalent to the IESG's *DISCUSS*

  36. stpeter

    cf. Section 5.1 of XEP-0115

  37. stpeter

    e.g., "Sort the service discovery identities [15] by category and then by type and then by xml:lang (if it exists), formatted as CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]. [16] Note that each slash is included even if the LANG or NAME is not included (in accordance with XEP-0030, the category and type MUST be included)."

  38. stpeter

    So they have to be unique.

  39. stpeter

    m&m: right, "let's have a chat about this"

  40. stpeter

    shall we take it to the list?

  41. stpeter

    or is it already there? ;-)

  42. m&m

    the list discussion hasn't started yet

  43. stpeter

    see also https://github.com/xsf/xeps/commit/bf110edfccddf0c22089df2861e0231bdb05c3a2#diff-5313e01f95bfb0963280ca4dfb497800L275

  44. stpeter

    but this was in XEP-0115 earlier

  45. stpeter

    this looks like the kind of thing that someone asked me about and we clarified it in two places

  46. stpeter

    however, the constraint was already in XEP-0115 by then

  47. stpeter

    now I'd need to go through the history of XEP-0115 too

  48. stpeter

    probably not the best use of our time here :-)

  49. m&m

    probably not (-:

  50. stpeter

    shall we move along to things we can settle now?

  51. m&m


  52. Kev

    If this is already covered in the general lore by 115 and it was just missing from 30, let me know and I'll remove my -1. I was concerned that it might be adding in multi-lang without discussion.

  53. m&m

    I do recall this being discussed for 115

  54. stpeter

    BTW this xml:lang rule was not in version 1.4 of XEP-0115 and was added for version 1.5, published in February 2008

  55. stpeter

    so we can look at the discussion leading up to 1.5

  56. m&m

    anyway … let's move on

  57. stpeter

    of which there was much, I think - or at least lots of release candidate versions of 1.5 leading up to publication and approval in Feb 2008

  58. stpeter


  59. stpeter


  60. stpeter

    next conundrum? ;-)

  61. m&m

    we've got action we can take for 115, which is to get back to Kev on details, then decide what's next

  62. m&m


  63. m&m


  64. m&m

    I believe this just needs to be merged into the next release

  65. m&m

    nope, I need to reach out to Kev and MattJ about reviewing the latest changes

  66. m&m

    I'll send that note out shortly

  67. m&m


  68. m&m

    this is ready to take to council

  69. m&m

    in the past, this would have been an 1.yrcX interim release

  70. m&m

    well, tmp publish

  71. stpeter

    also BTW https://github.com/xsf/xeps/commit/6057a1fb42c18d1dddf07cdc0daa72696c327734#diff-5313e01f95bfb0963280ca4dfb497800 - that's where we made the change to 115

  72. m&m

    stpeter: you're having a tough time moving on today (-:

  73. stpeter

    m&m: agreed on #41

  74. stpeter

    I am - now I'm fascinating by what happened here :-)

  75. m&m

    I don't blame you … gone down a bunch of rabbit holes like this in the past myself

  76. Kev

    I've just been through (quickly) the 100ish post thread about 115. I'll remove my -1.

  77. m&m

    noted and thanks, Kev

  78. stpeter

    Kev: yeah lots of discussion in January 2008! http://mail.jabber.org/pipermail/standards/2008-January/thread.html

  79. m&m

    for #41, I suggest we ask the council if they're good going to draft from the changelog

  80. stpeter moves on mentally :-)

  81. Kev

    Mail sent.

  82. m&m

    and render upon request

  83. m&m

    trying to avoid publish snafus

  84. stpeter

    on https://github.com/xsf/xeps/pull/63 I asked Lance to make some fixes - I can ping him about that

  85. m&m


  86. m&m

    #82 is on hold, waiting on Mr. Wild

  87. m&m

    same with #83, actually (-:

  88. SamWhited

    #83 I need to sit down and rework; I just keep forgetting to do it.

  89. SamWhited

    Based on list feedback and discussion from last week.

  90. stpeter

    it's still on my list to go through XEP-0198 proposals but I haven't carved out the time yet

  91. m&m

    so #84 on hold pending author

  92. stpeter

    see above on needing to update a few Internet-Drafts :-)

  93. m&m


  94. stpeter

    also I'm way behind on a certain MUC/MIX discussion :-)

  95. Kev

    That one just needs you to say "Kev, make the changes" and watch while I fail to find time :)

  96. m&m

    I still haven't had time to read all of the changes to #91

  97. m&m

    failing to find time is a running theme

  98. stpeter

    always :-)

  99. Kev

    Yes, sorry.

  100. m&m

    we're all guilty

  101. stpeter

    Lance says he'll update XEP-215 per #63

  102. m&m


  103. Kev

    Unless we're desperately short of people I'll drop Council next year. Won't give me much extra time, but will cut back the amount of stuff I'm committing to and struggling with.

  104. stpeter

    https://github.com/xsf/xeps/pull/94 LGTM as I replied there

  105. stpeter

    Kev: yeah I might need to do some recruiting it seems

  106. stpeter

    I'm the only person who's put a hat into the ring for anything ;-)

  107. m&m

    stpeter: agreed, just needs some massaging to get its editorial version

  108. stpeter

    m&m ok good

  109. m&m

    #95 is pending a response from stpeter I think

  110. stpeter

    yeah I _just_ replied

  111. m&m

    looks like #96 is also ready for merging

  112. stpeter

    +1 on #96

  113. m&m

    I just took it over to track my failures (-:

  114. m&m

    #98 is just fixing examples, and stripping extraneous whitespace.

  115. m&m

    I think it's good to merge as an editorial revision

  116. stpeter


  117. m&m

    #100 needs some council discussion still, I think

  118. m&m

    need to make sure that makes it onto their next agenda

  119. SamWhited

    Can we go ahead and merge #99 so I can use it? It works fine (at least on Linux; might be able to install things with homebrew on macs). People can improve it later if they want to support their system more generically.

  120. m&m

    SamWhited: let me try it out … sorry, it kept slipping

  121. stpeter

    I think it would be good to have a discussion on the list about deprecating stream compression entirely given the attacks that exist - or at least have a discussion about whether those attacks apply to XMPP, because if they do then deprecating stream compression would seem to be the right thing to do.

  122. SamWhited

    m&m: Many thanks :)

  123. m&m

    stpeter: agreed

  124. stpeter

    or at least, "might" be the right thing to do

  125. m&m

    I'm not entirely sure these attacks are applicable to XMPP, given its stateful nature

  126. m&m

    but the discussion is good to have

  127. SamWhited

    I know we did a big security analysis when we implemented it; pretty sure the answer ended up being "as long as there are flushes on stanza boundaries on both ends it will be okay", but I'll see if I can't get the official report or discussion. Might have good info, I dunno.

  128. SamWhited

    s/flsuhes/full flushes/

  129. m&m

    that would be great, Sam

  130. SamWhited goes to figure out who did that... it was shortly before I started here.

  131. stpeter


  132. stpeter

    thanks, Sam!

  133. m&m

    so, uh, #106 seems contested to me (-:

  134. stpeter

    106 or 104?

  135. m&m

    gah, yeah 104

  136. stpeter


  137. m&m

    I merged 0016 and 104 in an odd way

  138. SamWhited


  139. stpeter

    I haven't looked at #106 yet

  140. stpeter


  141. stpeter

    Sam suggested that I need to post in the privacy lists discussion

  142. SamWhited

    Please and thank you :)

  143. m&m

    so, #106 is still pending author?

  144. Kev

    I think I suggested that Sam suggested that ... :)

  145. SamWhited


  146. stpeter

    I haven't been closely tracking that thread, but given that I've been the one slowly pushing forward with alternatives (invisibility and blocking commands), I think it's safe to say that I am not a huge fan of privacy lists - and we developed privacy lists originally to address a requirement that we misunderstood from RFC 2779 way back in the early days of the XMPP WG!

  147. stpeter

    so I will post in that thread

  148. Kev

    (And so who really composed Beethoven's 5th?)

  149. Kev

    stpeter: I think that would be useful, thanks.

  150. stpeter


  151. m&m is updating his .todo .. un momento

  152. m&m


  153. m&m

    so, #104 is pending more list discussion

  154. m&m

    #106 is pending author action

  155. m&m

    #108 just needs to be mergec

  156. m&m

    merged even

  157. m&m

    (with an editorial revision)

  158. stpeter

    I need to depart for another meeting

  159. m&m

    I think we're done

  160. m&m


  161. m&m

    and congrats on yet-another-RFC (-:

  162. Kev

    Thanks to our diligent Editors ;)

  163. stpeter