XSF logo 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 sure
  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 (XEP-0001)
  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 indeed
  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