XSF Editor Team - 2018-02-17

  1. jcbrand has left

  2. jcbrand has left

  3. jcbrand has left

  4. jcbrand has left

  5. jcbrand has joined

  6. jcbrand has left

  7. jcbrand has left

  8. jcbrand has joined

  9. jcbrand has left

  10. jcbrand has joined

  11. jcbrand has left

  12. jcbrand has joined

  13. bear has left

  14. jcbrand has left

  15. jcbrand has joined

  16. SamWhited has left

  17. jcbrand has left

  18. jcbrand has joined

  19. jcbrand has left

  20. jcbrand has joined

  21. jcbrand has left

  22. jcbrand has joined

  23. jcbrand has left

  24. jcbrand has joined

  25. jcbrand has left

  26. jcbrand has joined

  27. jcbrand has left

  28. jcbrand has joined

  29. Guus has left

  30. Guus has left

  31. jcbrand has left

  32. jcbrand has joined

  33. jcbrand has left

  34. jcbrand has joined

  35. jcbrand has left

  36. jcbrand has joined

  37. jcbrand has left

  38. jcbrand has joined

  39. Guus has left

  40. SamWhited has left

  41. jcbrand has left

  42. jcbrand has joined

  43. Guus has left

  44. jcbrand has left

  45. jcbrand has joined

  46. winfried has left

  47. winfried has joined

  48. winfried has left

  49. winfried has joined

  50. jcbrand has left

  51. jcbrand has joined

  52. winfried has left

  53. winfried has joined

  54. Guus has left

  55. winfried has left

  56. winfried has joined

  57. winfried has left

  58. winfried has joined

  59. Guus has left

  60. Guus has left

  61. Guus has left

  62. Guus has left

  63. jcbrand has left

  64. Guus has left

  65. Guus has left

  66. Guus has left

  67. jcbrand has left

  68. jcbrand has joined

  69. Guus has left

  70. Guus has left

  71. Flow

    jonasw, do you intent to bump the http upload namespace after the latest merge?

  72. jonasw

    ah damn

  73. jonasw

    will do

  74. Flow

    I'm myself not entirely sure if it's required, but I think so

  75. jonasw

    thanks for the reminder

  76. jonasw

    although, I’ll double-check

  77. jonasw

    I think I’m confusing this change with something else

  78. jonasw

    yes I am

  79. jonasw

    the NS-bump-neednig-change was XEP-0401

  80. jcbrand has left

  81. jcbrand has joined

  82. Flow

    jonasw, I think http upload also needs a bump, otherwise a client may show http upload as available with an http upload service that also requires disallowed headers

  83. jonasw

    I also don’t think that it should be the editors job to judge this

  84. Flow

    I think it's the editors job to ensure that changes without a namespace bump are backwards compatbile

  85. jonasw

    Flow, a server could also just be misbehaving, so the behaviour would be the same. I’m not sure this warrants a bump.

  86. Flow

    jonasw, I don't follow that argumentation

  87. jonasw

    lemme retry

  88. jonasw

    the effect of the lack of namespace bump is that a client may try a request only to learn that it won’t be able to upload because of disallowed headers

  89. jonasw

    so the upload would fail due to a policy-violation or something

  90. Flow

    But then the client may already displayed the availability of http upload to the user

  91. jonasw


  92. jonasw

    I’m not entirely sure if this is a problem, because (a) I don’t think we’ve got anything in the wild which does this and (b) a server could also be misconfigured to have the same situation

  93. Flow

    you never know how many users are hidden somewhere and following (b) would mean that we never had to do namespace bumps

  94. jonasw

    where are the procedures for bumping namespaces written down?

  95. Guus has left

  96. jonasw

    I can’t find it in XEP-0001

  97. Flow

    I'd probably always bump as soon as the rules change so that old implementations would violate them, as it was the case here, simply because I don't think that we can build an interoperable and federated system without doing so. The lazy way will be more painful in the long run

  98. Flow

    jonasw, there are none written down AFAIK, besides "if non backwards compatbile change, then bump"

  99. jonasw

    I’d like to have that written down, because I don’t want to get into arguments over this with either council or authors.

  100. Flow

    Not sure if more needs to be written down

  101. Flow

    This is some sort of special case, because as you said a client will find out if the upload compononent follows the new rules or not

  102. jonasw

    I tend to agree in general, but in this specific case, I think it is very unlikely that this is a problem. none of the big object storage services we surveyed the last week did use any header other than the three listed.

  103. jonasw

    so unless somebody did a home-brew solution before e.g. prosody even did have support for that version of the XEP which used some arcane headers/protocol not used by any major block storage *and* which is based on HTTP headers, I don’t think there’ll be an issue.

  104. jonasw

    I know that this is not a super-great or solid argument, but given the limited resources in the developer community, I think that bumping the namespace again just after conversations dropped support for the first namespace would bind more resources than worth it

  105. jonasw

    (prosody only gained support for :0 recently-ish)

  106. Flow

    I know that implementors don't like bumping namespace, I'm also affected, because of that and the particular case I'm not going to pursue this further. But I think that the editors here should be the counterweight when it comes to namespace bumps

  107. Flow

    Also your argument would also hold for PR# 585, wouldn't it?

  108. jonasw

    (btw, I think we’re making breaking changes to MIX all the time currently)

  109. jonasw

    Flow, no, I think the difference between the two cases is that with HTTP upload, it is deemed unsafe to follow the old protocol. so even *if* the client could discover that :0 was supported (suppose we bump to :up1 now), it wouldn’t want to follow that. In this case, if the client can discover that invite:0 is supported, it might choose that.

  110. jonasw

    Flow, no, I think the difference between the two cases is that with HTTP upload, it is deemed unsafe to follow the old protocol. so even *if* the client could discover that upload:0 was supported (suppose we bump to upload:1 now), it wouldn’t want to follow that. In this case, if the client can discover that invite:0 is supported, it might choose that.

  111. jonasw

    (if it wanted to follow the upload:0, it could simply do so.)

  112. Link Mauve

    IIRC, while a XEP is still experimental, the author can do any breaking change they want and don’t have to care about backwards compatibility.

  113. jonasw

    yeah, that argument, too

  114. Link Mauve

    Namespace bumps could be done only in drafts, if we didn’t care enough about that.

  115. Flow

    Link Mauve, IIRC or IMHO? ;)

  116. Link Mauve

    IIRC, I was looking for a source but I can’t find it.

  117. Flow

    I don't find that written down anywhere

  118. Flow

    And I would also hope that we require namespace bumps also for experimental XEPs

  119. Flow

    (MIX also had a namespace bump)

  120. jonasw

    maybe we should ask Council to write a set of rules for this?

  121. jonasw

    > Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).

  122. jonasw


  123. jonasw

    I guess we could technically be saying "f*** you for using experimental".

  124. Flow

    only issue with that is that many important XEPs are experimental

  125. jonasw


  126. jonasw

    but that’s a separate issue

  127. Flow

    that's why i'm arguing for another stage "incubating" before experimental, where namespace bumps are not required

  128. Flow

    and where xeps have a well known location but not a number

  129. jonasw

    I’d rather argue for getting our act together and advance things ;-).

  130. Flow

    sure, but unrealistic

  131. jcbrand has left

  132. Kev has left

  133. jcbrand has joined

  134. jcbrand has left

  135. jcbrand has joined

  136. Flow has left

  137. Guus has left

  138. Guus has left

  139. Guus has left

  140. jcbrand has left

  141. Guus has joined

  142. jcbrand has left

  143. Guus has left

  144. Guus has joined

  145. Guus has left

  146. jcbrand has left

  147. jcbrand has joined

  148. jcbrand has left

  149. jcbrand has left

  150. jcbrand has joined

  151. Guus has joined

  152. jcbrand has left

  153. Guus has left

  154. Guus has joined

  155. jcbrand has joined

  156. Tobi has left

  157. jcbrand has left

  158. jcbrand has joined

  159. Tobi has left

  160. Tobi has joined

  161. jcbrand has left

  162. jcbrand has joined

  163. jcbrand has left

  164. jcbrand has joined

  165. flow has joined

  166. Tobi has joined

  167. Tobi has joined

  168. Tobi has left

  169. Tobi has joined

  170. Guus has left

  171. Guus has left

  172. Guus has left

  173. Guus has left

  174. Guus has left

  175. Guus has left

  176. Guus has left

  177. Guus has left

  178. Guus has left

  179. Guus has left

  180. Guus has joined

  181. Guus has left

  182. Guus has left

  183. jcbrand has left

  184. jcbrand has left

  185. Guus has left

  186. Guus has left

  187. jcbrand has left

  188. jcbrand has left

  189. soul has left

  190. jcbrand has left

  191. jcbrand has left

  192. jcbrand has joined

  193. Guus has left

  194. jcbrand has left

  195. Guus has left

  196. jcbrand has left

  197. Guus has left

  198. Guus has left

  199. SamWhited has left

  200. jcbrand has left

  201. jcbrand has left

  202. jcbrand has joined

  203. jcbrand has left

  204. jcbrand has left

  205. jcbrand has joined

  206. jcbrand has left

  207. jcbrand has joined

  208. SamWhited has left

  209. SamWhited has left

  210. Guus has left

  211. jcbrand has left

  212. Guus has left

  213. Guus has left

  214. Guus has left

  215. jcbrand has left

  216. Guus has left

  217. SamWhited has left

  218. Kev has joined

  219. Kev

    > Link Mauve > IIRC, while a XEP is still experimental, the author can do any breaking change they want and don’t have to care about backwards compatibility. Not really. Breaking changes still typically get bumps in Experimental.

  220. Kev

    But we can certainly be more liberal in our definitions of 'breaking changes' than once it's Draft.

  221. Link Mauve

    Typically yes, but I couldn’t find any document saying we should do it one way or the other one.

  222. Guus has left

  223. jcbrand has left

  224. Tobi has left

  225. jcbrand has left

  226. SamWhited has left

  227. Guus has left

  228. Guus has left

  229. jcbrand has left