XSF logo XSF Editor Team - 2015-10-15


  1. stpeter has joined
  2. stpeter has left
  3. SamWhited has left
  4. SamWhited has left
  5. SamWhited has left
  6. SamWhited has left
  7. SamWhited has left
  8. SamWhited has left
  9. Flow has joined
  10. Flow has left
  11. Ash has joined
  12. Kev has left
  13. Kev has left
  14. m&m has joined
  15. stpeter has joined
  16. m&m waves
  17. SamWhited nods
  18. stpeter howdy
  19. m&m yet another RFC with your name on it
  20. stpeter and you :-)
  21. stpeter I still have 3 I-Ds to submit before the cutoff on Monday, sigh
  22. m&m do you want to skip on editor stuff then>
  23. m&m ?
  24. stpeter it's OK, let's make some progress
  25. m&m alright
  26. m&m first, something we're going to need to address
  27. m&m Kev found what he feels are substantive changes in XEP-0030
  28. m&m around how xml:lang factors into uniqueness
  29. stpeter right, I saw a message about that somewhere
  30. stpeter did we track down the check-in that modified this?
  31. m&m yes, sometime back in 2008
  32. 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)."
  33. m&m yep
  34. m&m https://github.com/xsf/xeps/commit/bf110edfccddf0c22089df2861e0231bdb05c3a2#diff-86c7b1b1dbf6dd553b5a7b53a1cb87ce
  35. Kev I think I suggested list discussion, mostly (disclaimer, I'm ill today, not firing on all cylinders).
  36. Kev Just to check we weren't about to include a substantive change without discussion.
  37. Kev It looks like the change in question was ages old, but never included in a new revision.
  38. Kev And at some point it accidentally got regenerated into the current version, like the 313 stuff.
  39. stpeter I'd need to review the discussion list history from June of 2008
  40. stpeter and earlier
  41. stpeter perhaps this was discussed as part of the run-up to 2.4 but was left out somehow.
  42. Kev I didn't do that. But yes, that would be sensible.
  43. stpeter I can't recall.
  44. 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.
  45. Kev Anyway - my block was the temporary check-we-don't-accidentally-break-something type, not the this-must-not-happen type.
  46. stpeter I don't have a quick answer.
  47. 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.
  48. 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.
  49. Kev -1 on something that seems broadly right feels wrong, but there we go.
  50. m&m I'm now thinking of XMP Council's -1 as equivalent to the IESG's *DISCUSS*
  51. stpeter cf. Section 5.1 of XEP-0115
  52. 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)."
  53. stpeter So they have to be unique.
  54. stpeter m&m: right, "let's have a chat about this"
  55. stpeter shall we take it to the list?
  56. stpeter or is it already there? ;-)
  57. m&m the list discussion hasn't started yet
  58. stpeter see also https://github.com/xsf/xeps/commit/bf110edfccddf0c22089df2861e0231bdb05c3a2#diff-5313e01f95bfb0963280ca4dfb497800L275
  59. stpeter but this was in XEP-0115 earlier
  60. stpeter this looks like the kind of thing that someone asked me about and we clarified it in two places
  61. stpeter however, the constraint was already in XEP-0115 by then
  62. stpeter now I'd need to go through the history of XEP-0115 too
  63. stpeter probably not the best use of our time here :-)
  64. m&m probably not (-:
  65. stpeter shall we move along to things we can settle now?
  66. m&m let's
  67. 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.
  68. m&m I do recall this being discussed for 115
  69. 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
  70. stpeter so we can look at the discussion leading up to 1.5
  71. m&m anyway … let's move on
  72. 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
  73. stpeter nod
  74. stpeter yep
  75. stpeter next conundrum? ;-)
  76. 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
  77. m&m s/115/30/
  78. m&m https://github.com/xsf/xeps/pull/40
  79. m&m I believe this just needs to be merged into the next release
  80. m&m nope, I need to reach out to Kev and MattJ about reviewing the latest changes
  81. m&m I'll send that note out shortly
  82. m&m https://github.com/xsf/xeps/pull/41
  83. m&m this is ready to take to council
  84. m&m in the past, this would have been an 1.yrcX interim release
  85. m&m well, tmp publish
  86. stpeter also BTW https://github.com/xsf/xeps/commit/6057a1fb42c18d1dddf07cdc0daa72696c327734#diff-5313e01f95bfb0963280ca4dfb497800 - that's where we made the change to 115
  87. m&m stpeter: you're having a tough time moving on today (-:
  88. stpeter m&m: agreed on #41
  89. stpeter I am - now I'm fascinating by what happened here :-)
  90. m&m I don't blame you … gone down a bunch of rabbit holes like this in the past myself
  91. Kev I've just been through (quickly) the 100ish post thread about 115. I'll remove my -1.
  92. m&m noted and thanks, Kev
  93. stpeter Kev: yeah lots of discussion in January 2008! http://mail.jabber.org/pipermail/standards/2008-January/thread.html
  94. m&m for #41, I suggest we ask the council if they're good going to draft from the changelog
  95. stpeter moves on mentally :-)
  96. Kev Mail sent.
  97. m&m and render upon request
  98. m&m trying to avoid publish snafus
  99. stpeter on https://github.com/xsf/xeps/pull/63 I asked Lance to make some fixes - I can ping him about that
  100. m&m thanks
  101. m&m #82 is on hold, waiting on Mr. Wild
  102. m&m same with #83, actually (-:
  103. SamWhited #83 I need to sit down and rework; I just keep forgetting to do it.
  104. SamWhited Based on list feedback and discussion from last week.
  105. stpeter it's still on my list to go through XEP-0198 proposals but I haven't carved out the time yet
  106. m&m so #84 on hold pending author
  107. stpeter see above on needing to update a few Internet-Drafts :-)
  108. m&m right
  109. stpeter also I'm way behind on a certain MUC/MIX discussion :-)
  110. Kev That one just needs you to say "Kev, make the changes" and watch while I fail to find time :)
  111. m&m I still haven't had time to read all of the changes to #91
  112. m&m failing to find time is a running theme
  113. stpeter always :-)
  114. Kev Yes, sorry.
  115. m&m we're all guilty
  116. stpeter Lance says he'll update XEP-215 per #63
  117. m&m cool
  118. 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.
  119. stpeter https://github.com/xsf/xeps/pull/94 LGTM as I replied there
  120. stpeter Kev: yeah I might need to do some recruiting it seems
  121. stpeter I'm the only person who's put a hat into the ring for anything ;-)
  122. m&m stpeter: agreed, just needs some massaging to get its editorial version
  123. stpeter m&m ok good
  124. m&m #95 is pending a response from stpeter I think
  125. stpeter yeah I _just_ replied
  126. m&m looks like #96 is also ready for merging
  127. stpeter +1 on #96
  128. m&m I just took it over to track my failures (-:
  129. m&m #98 is just fixing examples, and stripping extraneous whitespace.
  130. m&m I think it's good to merge as an editorial revision
  131. stpeter agreed
  132. m&m #100 needs some council discussion still, I think
  133. m&m need to make sure that makes it onto their next agenda
  134. 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.
  135. m&m SamWhited: let me try it out … sorry, it kept slipping
  136. 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.
  137. SamWhited m&m: Many thanks :)
  138. m&m stpeter: agreed
  139. stpeter or at least, "might" be the right thing to do
  140. m&m I'm not entirely sure these attacks are applicable to XMPP, given its stateful nature
  141. SamWhited has left
  142. m&m but the discussion is good to have
  143. 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.
  144. SamWhited s/flsuhes/full flushes/
  145. m&m that would be great, Sam
  146. SamWhited goes to figure out who did that... it was shortly before I started here.
  147. stpeter :)
  148. stpeter thanks, Sam!
  149. m&m so, uh, #106 seems contested to me (-:
  150. stpeter 106 or 104?
  151. m&m gah, yeah 104
  152. stpeter k
  153. m&m I merged 0016 and 104 in an odd way
  154. SamWhited <insert-evil-laugh-here>
  155. stpeter I haven't looked at #106 yet
  156. stpeter (FWIW)
  157. stpeter Sam suggested that I need to post in the privacy lists discussion
  158. SamWhited Please and thank you :)
  159. m&m so, #106 is still pending author?
  160. Kev I think I suggested that Sam suggested that ... :)
  161. SamWhited indeed
  162. 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!
  163. stpeter so I will post in that thread
  164. Kev (And so who really composed Beethoven's 5th?)
  165. Kev stpeter: I think that would be useful, thanks.
  166. stpeter k
  167. m&m is updating his .todo .. un momento
  168. m&m ok
  169. m&m so, #104 is pending more list discussion
  170. m&m #106 is pending author action
  171. m&m #108 just needs to be mergec
  172. m&m merged even
  173. m&m (with an editorial revision)
  174. stpeter I need to depart for another meeting
  175. m&m I think we're done
  176. m&m thanks!!
  177. m&m and congrats on yet-another-RFC (-:
  178. Kev Thanks to our diligent Editors ;)
  179. stpeter :)
  180. SamWhited has left
  181. SamWhited has left
  182. Kev has left
  183. Ash has left
  184. Flow has joined
  185. m&m has left
  186. m&m has joined
  187. stpeter has left
  188. stpeter has joined
  189. stpeter has left
  190. SamWhited has left
  191. Neustradamus has joined
  192. m&m has left
  193. Neustradamus has left
  194. m&m has joined
  195. SamWhited has left
  196. Ash has left
  197. Flow has left
  198. SamWhited has left
  199. stpeter has joined
  200. SamWhited has left
  201. SamWhited has left
  202. Ash has left
  203. m&m has left
  204. stpeter has left