XSF Discussion - 2021-09-08


  1. neshtaxmpp has left
  2. neshtaxmpp has joined
  3. alex11 has joined
  4. soundconcept has left
  5. soundconcept has joined
  6. adiaholic has joined
  7. adiaholic has left
  8. neshtaxmpp has left
  9. neshtaxmpp has joined
  10. neshtaxmpp has left
  11. neshtaxmpp has joined
  12. lskdjf has left
  13. floretta has left
  14. floretta has joined
  15. sonny has left
  16. sonny has joined
  17. sonny has left
  18. sonny has joined
  19. sonny has left
  20. sonny has joined
  21. sonny has left
  22. sonny has joined
  23. floretta has left
  24. neshtaxmpp has left
  25. stp has left
  26. sonny has left
  27. sonny has joined
  28. floretta has joined
  29. neshtaxmpp has joined
  30. sonny has left
  31. adiaholic has joined
  32. sonny has joined
  33. scorch has left
  34. adiaholic has left
  35. meeeeson has left
  36. meeeeson has joined
  37. adiaholic has joined
  38. neshtaxmpp has left
  39. scorch has joined
  40. adiaholic has left
  41. stp has joined
  42. andrey.g has left
  43. Server Stats Discoverer (traveler bot) has left
  44. homebeach has left
  45. Rixon 👁🗨 has left
  46. Half-Shot has left
  47. Matthew has left
  48. uhoreg has left
  49. Half-Shot has joined
  50. Matthew has joined
  51. Rixon 👁🗨 has joined
  52. uhoreg has joined
  53. homebeach has joined
  54. Server Stats Discoverer (traveler bot) has joined
  55. stp has left
  56. floretta has left
  57. floretta has joined
  58. scorch has left
  59. adiaholic has joined
  60. adiaholic has left
  61. norkki has left
  62. norkki has joined
  63. neshtaxmpp has joined
  64. adiaholic has joined
  65. scorch has joined
  66. adiaholic has left
  67. neshtaxmpp has left
  68. floretta has left
  69. floretta has joined
  70. adiaholic has joined
  71. adiaholic has left
  72. adiaholic has joined
  73. adiaholic has left
  74. adiaholic has joined
  75. aerick has left
  76. Kev has left
  77. Kev has joined
  78. adiaholic has left
  79. Yagiza has joined
  80. Seve has joined
  81. jgart has joined
  82. wladmis has joined
  83. adiaholic has joined
  84. govanify has left
  85. govanify has joined
  86. adiaholic has left
  87. sonny has left
  88. sonny has joined
  89. aerick has joined
  90. ti_gj06 has joined
  91. mukt2 has left
  92. neshtaxmpp has joined
  93. alex11 has left
  94. jgart has left
  95. jgart has joined
  96. lorddavidiii has joined
  97. Kev has left
  98. Kev has joined
  99. jgart has left
  100. jgart has joined
  101. DebXWoody has joined
  102. jgart has left
  103. jgart has joined
  104. wladmis has left
  105. Kev has left
  106. Kev has joined
  107. pasdesushi has joined
  108. adiaholic has joined
  109. wladmis has joined
  110. jcbrand has joined
  111. floretta has left
  112. floretta has joined
  113. marc0s has left
  114. marc0s has joined
  115. mukt2 has joined
  116. mimi89999 has left
  117. mimi89999 has joined
  118. me9 has joined
  119. DebXWoody has left
  120. Kev has left
  121. Kev has joined
  122. mukt2 has left
  123. adiaholic has left
  124. Tobias has joined
  125. yushyin has left
  126. malthe has joined
  127. adiaholic has joined
  128. mukt2 has joined
  129. malthe has left
  130. pasdesushi has left
  131. pasdesushi has joined
  132. karoshi has joined
  133. Kev has left
  134. Kev has joined
  135. adiaholic has left
  136. Menel has joined
  137. mukt2 has left
  138. mukt2 has joined
  139. me9 has left
  140. Kev has left
  141. Kev has joined
  142. adiaholic has joined
  143. Kev has left
  144. Kev has joined
  145. yushyin has joined
  146. pasdesushi has left
  147. adiaholic has left
  148. eevvoor has joined
  149. lorddavidiii has left
  150. Kev has left
  151. Kev has joined
  152. wurstsalat has joined
  153. marc0s has left
  154. marc0s has joined
  155. mukt2 has left
  156. mukt2 has joined
  157. Kev has left
  158. malthe has joined
  159. Kev has joined
  160. Kev has left
  161. Kev has joined
  162. jgart has left
  163. lorddavidiii has joined
  164. floretta has left
  165. floretta has joined
  166. MattJ Google and Cisco at least used to participate
  167. marc0s has left
  168. marc0s has joined
  169. marc0s has left
  170. marc0s has joined
  171. Kev has left
  172. Kev has joined
  173. Kev has left
  174. Kev has joined
  175. Kev has left
  176. Kev has joined
  177. mukt2 has left
  178. Kev has left
  179. Kev has joined
  180. malthe has left
  181. Kev has left
  182. Kev has joined
  183. Kev has left
  184. Kev has joined
  185. kyemxden has left
  186. kyemxden has joined
  187. ti_gj06 has left
  188. mukt2 has joined
  189. Kev has left
  190. Kev has joined
  191. mukt2 has left
  192. goffi has joined
  193. adiaholic has joined
  194. wurstsalat has left
  195. wurstsalat has joined
  196. Bung has joined
  197. wurstsalat has left
  198. wurstsalat has joined
  199. DebXWoody has joined
  200. adiaholic has left
  201. mukt2 has joined
  202. mukt2 has left
  203. lorddavidiii has left
  204. lorddavidiii has joined
  205. Kev has left
  206. Kev has joined
  207. sonny has left
  208. sonny has joined
  209. sonny has left
  210. sonny has joined
  211. Kev has left
  212. Kev has joined
  213. jl4 has joined
  214. georgeorwell has joined
  215. ti_gj06 has joined
  216. adiaholic has joined
  217. LNJ has joined
  218. adiaholic has left
  219. mukt2 has joined
  220. jgart has joined
  221. jgart has left
  222. stp has joined
  223. adiaholic has joined
  224. Kev has left
  225. Kev has joined
  226. Kev has left
  227. Kev has joined
  228. stp has left
  229. chronosx88 has left
  230. chronosx88 has joined
  231. Kev has left
  232. Kev has joined
  233. adiaholic has left
  234. Bung has left
  235. debacle has joined
  236. chronosx88 has left
  237. chronosx88 has joined
  238. eevvoor has left
  239. eevvoor has joined
  240. chronosx88 has left
  241. chronosx88 has joined
  242. mjk has joined
  243. adiaholic has joined
  244. jl4 has left
  245. jl4 has joined
  246. mjk has left
  247. eevvoor has left
  248. mjk has joined
  249. eevvoor has joined
  250. emus has left
  251. emus has joined
  252. adiaholic has left
  253. lskdjf has joined
  254. Bung has joined
  255. mukt2 has left
  256. mukt2 has joined
  257. Bung has left
  258. arcxi has left
  259. mjk has left
  260. Kev We certainly should care about those implementations, yes. We can’t write specs and then not care about breaking them in spec updates just because we didn’t know about them.
  261. mukt2 has left
  262. dwd At Pando we (deliberately) stored groupchat messages in the personal archive for resynchronization etc. However, these weren't XEP-0045, but ESL's "Muclight", so there weren't any "holes" in that archive.
  263. jonas’ Kev, but should we care about implementations which don't participate in the standards process?
  264. Bung has joined
  265. dwd jonas’, I would argue we're unlikely to get them to use XMPP at all if it's unstable for their purposes.
  266. dwd jonas’, So hardly likely to help them decide to participate.
  267. Ge0rG Kev, dwd: I've written down my questions on list and I'd really appreciate your input
  268. dwd Ge0rG, For XEP-0313? OK.
  269. Kev jonas’: Yes, we absolutely should. This isn’t an old boys club where we write specs only for ourselves.
  270. soundconcept has left
  271. soundconcept has joined
  272. jonas’ dwd, what's the benefit for XMPP? implementations which use XMPP and then don't contribute to the standards process or anything, what does that give XMPP as a whole?
  273. Kev jonas’: Implementations.
  274. jonas’ what's the benefit of that?
  275. Kev What’s the point of a protocol without implementations?
  276. Ge0rG I'm losing track of the meta discussion
  277. jonas’ Kev, well, fair enough I guess
  278. arcxi has joined
  279. Bung has left
  280. Mikaela has joined
  281. jl4 has left
  282. jl4 has joined
  283. mjk has joined
  284. dwd jonas’, It seems to me we're more likely to see an increase in active participation in the community with more usage of the protocols. Equally, if we focus solely on existing participants and ignore the wider usage, I don't see that we can have any outcome bu a reduction in usage, and therefore participation.
  285. mukt2 has joined
  286. jonas’ I guess the question is: what is the likelihood that any current longstanding non-participant becomes a participant in the future? vs. the likelihood that XMPP loses ever more relevance because the wide-spread public use-cases cannot be covered.
  287. Kev I think that’s a false dichotomy.
  288. jonas’ or can only be covered by documents having an ugly EXPERIMENTAL tag slapped all over them because we cannot reach consensus.
  289. Kev There’s a world of difference between not making unflagged deliberately breaking changes because we need those implementations they break ‘not ones we care about’ and not addressing use cases.
  290. jl4 has left
  291. jl4 has joined
  292. Kev There’s a world of difference between making unflagged deliberately breaking changes because we need those implementations they break ‘not ones we care about’ and not addressing use cases.
  293. kyemxden has left
  294. Server Stats Discoverer (traveler bot) has left
  295. Matthew has left
  296. Rixon 👁🗨 has left
  297. Half-Shot has left
  298. uhoreg has left
  299. homebeach has left
  300. Kev There’s a world of difference between making unflagged deliberately breaking changes because we deem those implementations they break ‘not ones we care about’ and not addressing use cases.
  301. kyemxden has joined
  302. jonas’ not having MAM stable is arguably "not addressing a use case"
  303. Rixon 👁🗨 has joined
  304. uhoreg has joined
  305. Half-Shot has joined
  306. dwd jonas’, Well, yes, the experimental and lack of progress is certainly a problem.
  307. Kev Again, I think it’s a false dichotomy to say that the only two options are “stop it being stable” and “mark existing compliant implementations non-compliant (and therefore expect them not to interop)”.
  308. jonas’ Kev, enlighten me how to fix it other than that :)
  309. Matthew has joined
  310. homebeach has joined
  311. Kev Not introduce “SHOULD NOT” (or worse MUST NOT) on text that previously was SHOULD.
  312. Kev Job done.
  313. jonas’ It seems that at least one council member is not going to let that pass though.
  314. jonas’ (for good reasons for the wide-spread public usecases if you'd ask me)
  315. Kev Into meetings, AFK a few hours.
  316. Paganini has left
  317. jonas’ same, gl
  318. mjk has left
  319. Paganini has joined
  320. adiaholic has joined
  321. mukt2 has left
  322. Ge0rG I'm reading that as "Experimental is Implicit Stable, because it might have implementations that we don't know about and that would break if we change it"
  323. Ge0rG And it's tangentially related to "we must not bump versions because the implementation ecosystem is so slow that we would fragment it"
  324. dwd Ge0rG, Well, yes and no. We protect deployed use of Experimental by namespace versioning, and that allows for parallel deployment of different versions of unstable protocols.
  325. jonas’ (which is an implementation burden much of the IM ecosystem cannot bear)
  326. dwd Ge0rG, But protocols that end up "stuck" in Experimental end up de-facto Stable. When de-facto is not reflected by the standards process it's not the de-facto that's wrong.
  327. jonas’ having a SHOULD written there when there are hundreds of deployments which do not honour it feels wrong though.
  328. Ge0rG dwd: many implementations struggle with fully implementing a single version of a given protocol, and we have almost no visibility into which versions are supported where
  329. dwd jonas’, That, too.
  330. adiaholic has left
  331. dwd Ge0rG, And also that.
  332. Ge0rG I remember a discussion with a developer of a new client who was confused by that exact SHOULD, and I had to explain that the known server implementations don't even honor it.
  333. dwd Ge0rG, At least some that presumably you've heard of have it as an option. MongooseIM, for example.
  334. dwd Ge0rG, I have replied to your note with a possible path forward, anyway.
  335. Server Stats Discoverer (traveler bot) has joined
  336. Ge0rG dwd: great, thanks!
  337. Daniel has left
  338. debacle has left
  339. Daniel has joined
  340. adiaholic has joined
  341. pasdesushi has joined
  342. Kev dwd: Presumably you also want a feature advertised saying that such an option is present, yes?
  343. dwd Kev, That'd be sensible, yes.
  344. Kev I might make that change now while I have two minutes then, if it unblocks this.
  345. Ge0rG I'm even more confused now.
  346. Ge0rG dwd: I've responded on list now.
  347. Kev About what? Dave suggested adding a flag for whether you want gc results for your query or not. Absent that flag both behaviours are valid, meaning existing implementations that either do what’s written or don’t include them are all compliant, and that going forward we can understand what we’ll receive, which seems to address your concern.
  348. Ge0rG I was implicitly assuming that type=groupchat equals MUC, and I think this is the cause of most of the confusion and debate.
  349. LNJ has left
  350. kyemxden has left
  351. kyemxden has joined
  352. Ge0rG Kev: I don't like it, because not having a default value is bad protocol, but I'm willing to take it as the lesser evil compared to namespace-bumping or eternal-experimental. Something is going to die in me when I +0 or +1 that.
  353. Ge0rG However, I'm still unconvinced that storing MUC history in the personal archive and returning it without an explicit query is a good idea.
  354. adiaholic has left
  355. Kev The shattering of your immortal soul aside, if I put some security considerations in, and add text/query parameter/disco features along Dave’s lines, you’ll withdraw your imminent -1?
  356. flow has joined
  357. adiaholic has joined
  358. Ge0rG Kev: is it a matter of rushing it through the Council today, or can we maybe have a few more days of pondering about a less unreasonable alternative?
  359. Kev I don’t particularly care about Experimental->Draft^h^h^h^h^hStable for this at the moment, but I know lots of other people do.
  360. Kev Ge0rG: I leave when Council do stuff up to Council, I just want to remove your current objections.
  361. Ge0rG This is a discussion that I wish we would have had during the LC.
  362. Ge0rG Kev: I think that it would be better to exchange a few more mails and get me to a solid +1 instead of getting me to a +0 today with a solution that's cementing a bad protocol design.
  363. debacle has joined
  364. Kev If your idea of a solid +1 is one in which it is forbidden to send groupchat results, as some current deployments do, without bumping namespaces, I don’t think we can achieve that while maintaining the (implicit?) promise that when we make breaking changes to Experimental XEPs we do something with namespaces or features such that compliant deployments don’t become non-compliant.
  365. Ge0rG Kev: but it'd be great if you could suggest a security section mentioning that a client MUST filter by query-id and by from address
  366. Ge0rG oh wait, that would be a breaking change as well.
  367. wgreenhouse has left
  368. Kev FWIW, it’s perfectly fine for a client to only filter on from address if it serialises queries, from a security considerations perspective.
  369. Ge0rG Kev: from my reading of the current 0313 text, a client can not rely on a server actually delivering type=groupchat results.
  370. mukt2 has joined
  371. Ge0rG This is of course different with servers that will nevertheless send those.
  372. Kev > Kev: from my reading of the current 0313 text, a client can not rely on a server actually delivering type=groupchat results. Indeed, but it must be able to cope with receiving them. If the XEP were changed to say “You won’t get them”, servers that do send them could break clients that know they won’t receive them.
  373. wgreenhouse has joined
  374. Ge0rG Kev: right.
  375. Ge0rG Can we add a feature and a query element with a default value and have a note that the default is undefined when the feature is not present?
  376. Ge0rG ie. no feature -> unknown; feature -> default=no-groupchat?
  377. Kev <p>Servers that understand the 'include-groupchat' field MUST advertise the 'urn:xmpp:mam:2#gc-field' (even if they cannot return groupchat messages), and servers that understand the 'include-groupchat' field and store groupchat messages in the user's archive must advertise the 'urn:xmpp:mam:2#groupchat-available' feature</p>
  378. adiaholic has left
  379. Kev That’s what I propose for disco.
  380. jl4 has left
  381. Kev So that means if you don’t store gc, you advertise #gc-field. If you store gc you advertise #gc-field and #gc-available.
  382. Ge0rG Kev: nitpick: rename the feature to `urn:xmpp:mam:2#groupchat-field` or maybe `urn:xmpp:mam:2#include-groupchat`
  383. Kev I did the opposite and changed both to gc.
  384. Ge0rG to make it better searchable for "groupchat"
  385. Ge0rG 👍
  386. Kev But I can revert, this is not a death hill.
  387. Ge0rG I have a slight bias towards `groupchat` and a strong bias towards consistency
  388. Ge0rG now how will that field be used? should it always be present in the query, with a boolean value for returning / not returning?
  389. Kev So if I understand your request, when #groupchat-field is advertised by the server, you’re saying that clients that don’t specify the gc field shouldn’t get groupchat?
  390. Ge0rG Kev: yes
  391. Kev I know of deployments where that would be unfortunate.
  392. Ge0rG it sounds like a breaking change when you say it
  393. Kev Where if the server was upgraded to a new MAM, but the client wasn’t, behaviour would change in an unfortunate way.
  394. adiaholic has joined
  395. southerntofu has joined
  396. Kev I think it would be better to go with Dave’s suggestion and leave the behaviour undefined in the face of not specifying the field, because then servers can leave their existing behaviour in place for undefined, and existing deployments don’t change behaviour on upgrade.
  397. Ge0rG I dislike it a bit less now.
  398. Kev (I do agree that it is at best unsatisfying to have optional options that don’t have defaults, but …)
  399. Ge0rG The alternative route would require a namespace bump *and* a feature
  400. Kev I think Dave’s proposal is the least bad option we’ve got.
  401. Kev Given where we are.
  402. Ge0rG I still don't see how returning semi-random blocks of MUC history is of any use.
  403. Kev I think that’s because you’re viewing MUC history in the user archive as being ‘everything that happened’ and I view it as ‘everything the user received’.
  404. Ge0rG But maybe you can elaborate that and the other questions on-list as well :)
  405. Ge0rG Kev: even in the latter case it's going to be weird.
  406. Kev My primary use of MAM is searching for something that I know I saw somewhere, but I can’t remember the details of, nor whether it was in one of the team rooms or in a direct message.
  407. Ge0rG Should it _also_ include the history that the client already received via live MUC traffic?
  408. Ge0rG Should a client use MAM IDs from MUC messages for an `after-id` query?
  409. Kev Yes, I agree there is weirdness.
  410. Ge0rG The existing implementations must have handled that weirdness in some way, right?
  411. Ge0rG Kev: which protocol are you using for searching?
  412. Kev 313 with a search field in the data form.
  413. Ge0rG The `urn:example:xmpp:free-text-search` one? ;)
  414. Kev I think we predate that, but I don’t recall TBH.
  415. Ge0rG I suppose that having a "free text search" field standardized in 313 would be of value as well.
  416. Ge0rG I'd argue that returning MUC results in queries _by default_ is a bad idea, but I can see how it makes sense for text-search queries. But those are only adding another option to the form, so making that an indicator to change the default response is weird as well.
  417. Kev <p>A client MUST verify the source of MAM query results against an open query (i.e. checking the stanza 'from' matches the entity that was queried) and MUST either ignore or otherwise disregard (maybe with a warning to the user) unsolicited results. This is to avoid the situation where a malicious entity sends MAM results while the client is querying a different entity and the client processes the malicious results as if they were part of the legitimate results.</p>
  418. Kev That sort of thing is what you care about, right Ge0rG?
  419. mukt2 has left
  420. Kev "Additionally, if the client has multiple queries in flight at once, it MUST also check that the query ID for a result matches that of an open query for that entity."
  421. adiaholic has left
  422. Ge0rG Kev: you make it sound like you may only receive MAM results while at least one query is running
  423. Ge0rG I think that "unsolicited MAM results" would be the most probable incarnation of the attack, because they don't rely on race conditions
  424. Ge0rG So it might be good to consolidate the pre-conditions (unsolicited, wrong from, wrong query-id) first, and then tell to ignore / warn the user?
  425. Ge0rG and how are we going to introduce that MUST without namespace-bumping? This might even break existing implementations, if those are susceptible to impersonation attacks.
  426. Kev > Kev: you make it sound like you may only receive MAM results while at least one query is running That’s right, isn’t it? If you receive results outside a query, you must drop them.
  427. Kev > and how are we going to introduce that MUST without namespace-bumping? This might even break existing implementations, if those are susceptible to impersonation attacks. I think you’re being facetious here, but just in case, I don’t think closing this particular security vulnerability would be a reason to namespace bump.
  428. Kev Since anyone vulnerable to such an attack is already broken, whether by behaviour or spec.
  429. Ge0rG > If you receive results outside a query, you must drop them. This may sound like an obvious thing, but many implementations have callbacks that are called on each message / each forwarded element and might just process those even outside of a query
  430. Ge0rG So I'd rather write it down in that paragraph
  431. Kev "A client MUST verify the source of MAM query results against an open query (i.e. checking the stanza 'from' matches the entity that was queried) and MUST either ignore or otherwise disregard (maybe with a warning to the user) unsolicited results - whether because the 'from' doesn't match an open query, or because there is no open query"
  432. Kev Bit after -
  433. Ge0rG Good enough for me :)
  434. Ge0rG Kev: Also feel free to copy&paste the CVE-2019-16235 and CVE-2020-26547 blocks from 0280, as those also affect MAM
  435. antranigv has left
  436. Kev Jonas thought sorting out the CVEs was Editorial, so I’ll leave that for the moment.
  437. antranigv has joined
  438. Ge0rG Good enough.
  439. Kev I figure just getting an author patch in with the other comments is probably providing more urgentness right now.
  440. Ge0rG Kev: you are right.
  441. Ge0rG Regarding process, do we need another LC or can that be considered as "implementing LC feedback from last time"?
  442. Kev As far as I would care, this is addressing feedback issued since LC.
  443. antranigv has left
  444. soundconcept has left
  445. soundconcept has joined
  446. Kev I know LCs are two weeks or whatever, but in practice from the moment LC is issued until it advances to Drable is one big LC period.
  447. antranigv has joined
  448. Ge0rG So we can actually vote on advancing it today.
  449. Kev If I get this patch submitted and an Editor gets it merged (or Council vote based on the merging), potentially. I could be dragged away from it at any moment, though, and I’m pretty slow at writing XEP stuff.
  450. Ge0rG Writing XEP text is not an easy job.
  451. malthe has joined
  452. Kev Ok, please be kind about this paragraph, because I don’t think it’s straightforward to write (I’ll include the specifics of ‘include-groupchat’ else where in the protocol section. This is in business rules: <p>Previous versions of this specification stated that a server SHOULD also include messages of type 'groupchat' that have a &lt;body&gt;. This advice has now been dropped, and servers MAY include groupchat messages in their archives. Whether a server stores groupchat messages or not is now left as an implementation (or deployment) decision. Whether a client wants to receive groupchat messages in results can be signalled with the 'include-groupchat' field (if supported by the server - see "Determining support") - where the server doesn't support this field, or where a client doesn't specify it in the query, whether groupchat messages are included in the result is implementation-defined; this allows existing deployments to not break with the introduction of the 'include-groupchat' query field in a later version of this specification, but it is RECOMMENDED that all client implementations of the current version of this specification always include the field where the server supports it, and that servers support it.</p>
  453. Kev Ge0rG & dwd: Does that roughly match your expectations?
  454. mukt2 has joined
  455. jonas’ SGTM
  456. Ge0rG Kev: +1
  457. Ge0rG would anything break if a client unconditionally includes <include-groupchat>?
  458. dwd Looks good from my side.
  459. dwd Ge0rG, I did wonder about that. I think forms generally pre-suppose ignoring unknown fields, but I'd need to check.
  460. Kev Ge0rG: Depends how the server processes unexpected query fields. I wouldn’t like to recommend it.
  461. jonas’ Ge0rG, possibly.
  462. Ge0rG Extensible.
  463. jonas’ I think the question "what happens on undeclared fields" was raised in the previous LC
  464. Kev Extensible doesn’t mean that when the server says “You can use these fields” that it should accept other ones :)
  465. Ge0rG Kev: well, normally it should mean "ignore all the fields you don't know"
  466. Ge0rG jonas’: indeed, because the implication was to return results that don't match what the client asked for.
  467. Kev Actually, including it serves no purpose.
  468. Kev Because if the server doesn’t support it, you won’t get it respecting in.
  469. Kev Because if the server doesn’t support it, you won’t get it respecting it.
  470. Kev So even if you could always include gc=false, you’d still have to expect gc results.
  471. Ge0rG Kev: the purpose is for a client that knows what it wants to always tell the server, without requiring a feature discovery round-trip
  472. malthe has left
  473. Ge0rG Kev: well, you also have to ignore those results from a server that doesn't have the feature.
  474. Kev Regardless - if we later determine that it is safe to include it’s a non-breaking change to a Drable (or Final) XEP to say “A client can safely always include this feature”.
  475. Kev But saying it now and later finding it was wrong is a breaking change.
  476. Ge0rG Rrrrright.
  477. Kev So I suggest we don’t add it now.
  478. Kev <p>If a client includes a form field that the server does not recognise, the server MUST respond with a 'feature-not-implemented' error.</p>
  479. Kev So it’s definitely not safe.
  480. Ge0rG Yay.
  481. Ge0rG so s/where the server supports it/iff the server supports it/?
  482. Ge0rG We have so far exactly one use of "iff", in 0390
  483. belong has left
  484. mukt2 has left
  485. Kev Ok, another please be kind;
  486. Kev <section3 topic='Including groupchat results in a user archive' anchor='query-include-groupchat'> <p>If the server advertises that it includes groupchat messages in a user's archive (see <link url='#support'>Determining support</link>), a client may query a user archive and request for them to be included in the result with the 'include-groupchat' field set to 'true'. </p> <example caption='Querying the archive and including groupchat messages in results'><![CDATA[ <iq type='set' id='juliet1'> <query xmlns='urn:xmpp:mam:2'> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'> <value>urn:xmpp:mam:2</value> </field> <field var='include-groupchat'> <value>true</value> </field> ... </x> </query> </iq> ]]></example> <p>If the server advertises that it includes groupchat messages in the archive, or it advertises that it doesn't, a client may request that they not be included by setting the 'include-groupchat' field to 'false'.</p> <example caption='Querying the archive and excluding groupchat messages from results'><![CDATA[ <iq type='set' id='juliet1'> <query xmlns='urn:xmpp:mam:2'> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'> <value>urn:xmpp:mam:2</value> </field> <field var='include-groupchat'> <value>false</value> </field> ... </x> </query> </iq> ]]></example> <p>Note that where the client doesn't specify the 'include-groupchat' field, it is implementation-defined whether groupchat messages are included in the results (see <link url='#business_rules'>Business Rules</link>).</p> </section3>
  487. jonas’ Ge0rG, I came to the conclusion that `iff` is too close to a typo and it shoudl be written as `if and only if` always
  488. Ge0rG jonas’: +1 to that
  489. Kev If I’m writing for an English-first audience, I’ll happily use iff. I think in XEPs it’s probably ill-advised.
  490. Ge0rG Kev: you might want to add a note that if a client adds the field on a server not advertising the feature, it will receive a `feature-not-implemented` error
  491. Kev That can’t hurt.
  492. antranigv has left
  493. Kev "Clients MUST NOT include this field where servers don't advertise support, as the server would reject such a form."
  494. mukt2 has joined
  495. Ge0rG Kev: +1
  496. Kev Ok, I think I have a suitable change, then.
  497. antranigv has joined
  498. belong has joined
  499. Kev Ge0rG (and others) - would you mind checking https://github.com/xsf/xeps/compare/master...Kev:xep313/LC-feedback-Ge0rG?expand=1 is close enough to what you expect, please, before I open the PR? I’m running out of morning and I increasingly urgently need to move on to other things :)
  500. Ge0rG Kev: that will only open a PR window, ITYM https://github.com/Kev/xeps/commit/992d40b20995692b1d3db5a760948d88103283ef
  501. Kev It shows a diff for me, but probably :)
  502. jl4 has joined
  503. mukt2 has left
  504. Ge0rG Kev: could you add a <section2 topic='Sender Impersonation' anchor='security-impersonation'> around the security paragraph?
  505. Ge0rG other than that, it looks great to me!
  506. Kev + </section2> + <section2 topic='Sender Impersonation' anchor='security-impersonation'>
  507. Kev Branch updated. I’ll submit, thanks.
  508. Ge0rG I still think that we'd greatly benefit from a statement like "Servers SHOULD NOT send offline history to clients that perform a MAM query before their initial presence"
  509. Kev I don’t disagree in principle, although I kinda feel it’s too big a can of worms for right now.
  510. Kev And we obviously can’t fully SHOULD NOT without some sort of namespace guarding.
  511. Ge0rG Well, this is exactly the can of worms you want to address before going Drable.
  512. malthe has joined
  513. georgeorwell has left
  514. Kev I can pop in a line to business rules if you’re happy that it’s non-normative.
  515. LNJ has joined
  516. adiaholic has joined
  517. Ge0rG This is exactly the sort of thing I'd like discussed among server and client developers.
  518. georgeorwell has joined
  519. Kev <p>A server MAY choose not to deliver offline messages to a client that has already queried their MAM archive and received the archived copies of those messages that would otherwise be delivered - while not required of an implementation, this is helpful to avoid duplicate messages for clients, so is suggested.</p> Seems safe enough, to me.
  520. Ge0rG Kev: great wording, +1
  521. Kev Also pushed.
  522. Kev I’ll raise the PR, then.
  523. Ge0rG Kev: please do!
  524. Kev I think that’s done now - https://github.com/xsf/xeps/pull/1104
  525. Kev I guess I *could* hit merge myself, but I’d probably better leave it for jonas’ in case I messed something up in the PR.
  526. adiaholic has left
  527. Bung has joined
  528. stp has joined
  529. malthe has left
  530. jonas’ yes please don't just hit merge
  531. jonas’ we don't have any automation there and it'll confuse the heck out of me
  532. antranigv has left
  533. georgeorwell has left
  534. georgeorwell has joined
  535. Wojtek has joined
  536. jl4 has left
  537. jl4 has joined
  538. govanify has left
  539. govanify has joined
  540. adiaholic has joined
  541. belong has left
  542. adiaholic has left
  543. govanify has left
  544. govanify has joined
  545. adiaholic has joined
  546. chronosx88 has left
  547. chronosx88 has joined
  548. mukt2 has joined
  549. adiaholic has left
  550. antranigv has joined
  551. sonny has left
  552. sonny has joined
  553. chronosx88 has left
  554. chronosx88 has joined
  555. andrey.g has joined
  556. mukt2 has left
  557. soundconcept has left
  558. soundconcept has joined
  559. kyemxden has left
  560. kyemxden has joined
  561. andrey.g has left
  562. mukt2 has joined
  563. soundconcept has left
  564. soundconcept has joined
  565. soundconcept has left
  566. soundconcept has joined
  567. soundconcept has left
  568. soundconcept has joined
  569. belong has joined
  570. soundconcept has left
  571. soundconcept has joined
  572. ti_gj06 has left
  573. soundconcept has left
  574. soundconcept has joined
  575. soundconcept has left
  576. soundconcept has joined
  577. antranigv has left
  578. belong has left
  579. lskdjf has left
  580. lskdjf has joined
  581. belong has joined
  582. soundconcept has left
  583. soundconcept has joined
  584. Ellenor Malik mew
  585. soundconcept has left
  586. wladmis has left
  587. wladmis has joined
  588. Kev has left
  589. Kev has joined
  590. wladmis has left
  591. wladmis has joined
  592. Kev has left
  593. wladmis has left
  594. Kev has joined
  595. wladmis has joined
  596. jl4 has left
  597. soundconcept has joined
  598. wladmis has left
  599. adiaholic has joined
  600. antranigv has joined
  601. Kev has left
  602. Kev has joined
  603. sonny has left
  604. sonny has joined
  605. soundconcept has left
  606. soundconcept has joined
  607. malthe has joined
  608. soundconcept has left
  609. soundconcept has joined
  610. soundconcept has left
  611. soundconcept has joined
  612. Kev has left
  613. Kev has joined
  614. malthe has left
  615. Kev has left
  616. Kev has joined
  617. soundconcept has left
  618. soundconcept has joined
  619. antranigv has left
  620. Kev has left
  621. Kev has joined
  622. DebXWoody has left
  623. Kev has left
  624. Kev has joined
  625. sonny has left
  626. sonny has joined
  627. sonny has left
  628. sonny has joined
  629. antranigv has joined
  630. Kev has left
  631. DebXWoody has joined
  632. Kev has joined
  633. Calvin has joined
  634. wladmis has joined
  635. wladmis has left
  636. antranigv has left
  637. Kev has left
  638. Kev has joined
  639. Kev has left
  640. Kev has joined
  641. Calvin has left
  642. kyemxden has left
  643. kyemxden has joined
  644. Kev has left
  645. Kev has joined
  646. Kev has left
  647. Kev has joined
  648. Kev has left
  649. Kev has joined
  650. sonny has left
  651. sonny has joined
  652. sonny has left
  653. Kev has left
  654. Kev has joined
  655. Kev has left
  656. sonny has joined
  657. Kev has joined
  658. Kev has left
  659. Kev has joined
  660. govanify has left
  661. Kev has left
  662. govanify has joined
  663. wladmis has joined
  664. adiaholic has left
  665. wladmis has left
  666. wladmis has joined
  667. georgeorwell has left
  668. georgeorwell has joined
  669. mjk has joined
  670. adiaholic has joined
  671. larma has left
  672. sonny has left
  673. sonny has joined
  674. sonny has left
  675. sonny has joined
  676. adiaholic has left
  677. norkki has left
  678. norkki has joined
  679. malthe has joined
  680. sonny has left
  681. sonny has joined
  682. sonny has left
  683. sonny has joined
  684. adiaholic has joined
  685. meeeeson has left
  686. harry837374884 has left
  687. adiaholic has left
  688. govanify has left
  689. harry837374884 has joined
  690. adiaholic has joined
  691. chronosx88 has left
  692. chronosx88 has joined
  693. soundconcept has left
  694. Server Stats Discoverer (traveler bot) has left
  695. homebeach has left
  696. Matthew has left
  697. Half-Shot has left
  698. uhoreg has left
  699. Rixon 👁🗨 has left
  700. Half-Shot has joined
  701. Matthew has joined
  702. Rixon 👁🗨 has joined
  703. uhoreg has joined
  704. homebeach has joined
  705. Server Stats Discoverer (traveler bot) has joined
  706. mukt2 has left
  707. mukt2 has joined
  708. sonny has left
  709. sonny has joined
  710. sonny has left
  711. sonny has joined
  712. eevvoor has left
  713. soundconcept has joined
  714. Kev has joined
  715. govanify has joined
  716. meeeeson has joined
  717. papatutuwawa has joined
  718. jgart has joined
  719. ti_gj06 has joined
  720. mjk has left
  721. jgart has left
  722. adiaholic has left
  723. jgart has joined
  724. belong has left
  725. Kev has left
  726. mukt2 has left
  727. Server Stats Discoverer (traveler bot) has left
  728. homebeach has left
  729. Matthew has left
  730. Half-Shot has left
  731. uhoreg has left
  732. Rixon 👁🗨 has left
  733. Half-Shot has joined
  734. Matthew has joined
  735. Rixon 👁🗨 has joined
  736. uhoreg has joined
  737. homebeach has joined
  738. Server Stats Discoverer (traveler bot) has joined
  739. Steve Kille has left
  740. Steve Kille has joined
  741. me9 has joined
  742. debacle has left
  743. meeeeson has left
  744. Kev has joined
  745. marc0s has left
  746. marc0s has joined
  747. Kev has left
  748. adiaholic has joined
  749. Kev has joined
  750. Kev has left
  751. adiaholic has left
  752. mukt2 has joined
  753. sonny has left
  754. sonny has joined
  755. sonny has left
  756. sonny has joined
  757. marc0s has left
  758. marc0s has joined
  759. paul has left
  760. paul has joined
  761. jl4 has joined
  762. me9 has left
  763. mjk has joined
  764. sonny has left
  765. sonny has joined
  766. Kev has joined
  767. Server Stats Discoverer (traveler bot) has left
  768. homebeach has left
  769. Matthew has left
  770. Half-Shot has left
  771. uhoreg has left
  772. Rixon 👁🗨 has left
  773. Half-Shot has joined
  774. Matthew has joined
  775. Rixon 👁🗨 has joined
  776. uhoreg has joined
  777. homebeach has joined
  778. Server Stats Discoverer (traveler bot) has joined
  779. Kev has left
  780. wladmis has left
  781. adiaholic has joined
  782. soundconcept has left
  783. wladmis has joined
  784. meeeeson has joined
  785. Ge0rG So I wanted to have a perma-link to "this year's compliance suite XEP" and it's not possible :(
  786. wladmis has left
  787. soundconcept has joined
  788. wurstsalat Ge0rG, nginx redirect?
  789. Ge0rG wurstsalat: something like https://xmpp.org/compliancesuite/ maybe?
  790. Ge0rG wurstsalat: who can create such a redirect?
  791. harry837374884 has left
  792. wurstsalat Ge0rG, this file (I think) https://github.com/xsf/xmpp.org/blob/master/deploy/xsf.conf
  793. Ge0rG wurstsalat: I'm not sure I should dare doing that without asking the A-Team, sorry, the i-team first.
  794. papatutuwawa has left
  795. wurstsalat Ge0rG, sure! those redirects work when building the page via docker
  796. belong has joined
  797. soundconcept has left
  798. pjn has left
  799. adiaholic has left
  800. wladmis has joined
  801. harry837374884 has joined
  802. Ge0rG https://github.com/xsf/xmpp.org/pull/960 is for the i-team
  803. alacer has joined
  804. Kev has joined
  805. wladmis has left
  806. alacer has left
  807. wladmis has joined
  808. wladmis has left
  809. ti_gj06 has left
  810. jl4 has left
  811. jl4 has joined
  812. jl4 has left
  813. jl4 has joined
  814. wladmis has joined
  815. jl4 has left
  816. jl4 has joined
  817. wladmis has left
  818. wladmis has joined
  819. adiaholic has joined
  820. mukt2 has left
  821. papatutuwawa has joined
  822. ti_gj06 has joined
  823. werdan has joined
  824. belong has left
  825. emus please dont merge untill we have the new website setup
  826. belong has joined
  827. mukt2 has joined
  828. raghavgururajan has left
  829. Yagiza has left
  830. adiaholic has left
  831. Ge0rG emus: better comment that on the PR
  832. sonny has left
  833. sonny has joined
  834. sonny has left
  835. sonny has joined
  836. emus yep
  837. adiaholic has joined
  838. Wojtek has left
  839. paul has left
  840. paul has joined
  841. malthe has left
  842. Wojtek has joined
  843. pjn has joined
  844. Wojtek has left
  845. adiaholic has left
  846. jgart has left
  847. lorddavidiii has left
  848. adiaholic has joined
  849. DebXWoody has left
  850. stpeter has joined
  851. stpeter has left
  852. LNJ has left
  853. DebXWoody has joined
  854. lorddavidiii has joined
  855. lorddavidiii has left
  856. lorddavidiii has joined
  857. adiaholic has left
  858. Daniel has left
  859. Daniel has joined
  860. Daniel has left
  861. Daniel has joined
  862. sonny has left
  863. sonny has joined
  864. sonny has left
  865. sonny has joined
  866. goffi has left
  867. debacle has joined
  868. harry837374884 has left
  869. harry837374884 has joined
  870. kyemxden has left
  871. kyemxden has joined
  872. flow has left
  873. werdan has left
  874. jl4 has left
  875. jl4 has joined
  876. mukt2 has left
  877. werdan has joined
  878. Mikaela has left
  879. Mikaela has joined
  880. mukt2 has joined
  881. kyemxden has left
  882. kyemxden has joined
  883. kyemxden has left
  884. kyemxden has joined
  885. andrey.g has joined
  886. eta has left
  887. eta has joined
  888. papatutuwawa has left
  889. raghavgururajan has joined
  890. wladmis has left
  891. wladmis has joined
  892. jl4 has left
  893. jl4 has joined
  894. ti_gj06 has left
  895. jl4 has left
  896. jl4 has joined
  897. Sam has left
  898. Sam has joined
  899. wladmis has left
  900. wladmis has joined
  901. jl4 has left
  902. jl4 has joined
  903. sebastian has left
  904. sebastian has joined
  905. wladmis has left
  906. jl4 has left
  907. jl4 has joined
  908. lovetox has left
  909. mukt2 has left
  910. jl4 has left
  911. jl4 has joined
  912. lovetox has joined
  913. mukt2 has joined
  914. jl4 has left
  915. jl4 has joined
  916. werdan has left
  917. jl4 has left
  918. meeeeson has left
  919. jl4 has joined
  920. jgart has joined
  921. Kev has left
  922. Kev has joined
  923. jl4 has left
  924. jl4 has joined
  925. jl4 has left
  926. jl4 has joined
  927. sonny has left
  928. sonny has joined
  929. sonny has left
  930. sonny has joined
  931. sonny has left
  932. jl4 has left
  933. sonny has joined
  934. jl4 has joined
  935. jl4 has left
  936. Server Stats Discoverer (traveler bot) has left
  937. Matthew has left
  938. Rixon 👁🗨 has left
  939. Half-Shot has left
  940. homebeach has left
  941. uhoreg has left
  942. Half-Shot has joined
  943. Matthew has joined
  944. Rixon 👁🗨 has joined
  945. uhoreg has joined
  946. homebeach has joined
  947. Seve has left
  948. Mikaela has left
  949. jl4 has joined
  950. adiaholic has joined
  951. wladmis has joined
  952. phryk MattJ, Zash: Do you guys have a list which clients support the technically non-standard invite-based registrations you implemented? (i.e. prosody mod_invites)
  953. bean has left
  954. phryk making some progress with dynamically built setup guides for my services' site and need that info to recommend people how to do things depending on what OS they're on and what client i'm recommending per OS. :)
  955. adiaholic has left
  956. belong has left
  957. adiaholic has joined
  958. Server Stats Discoverer (traveler bot) has joined
  959. MattJ phryk, I recently learned that it was 99% standardized as https://xmpp.org/extensions/xep-0445.html
  960. MattJ but it had somehow passed me by
  961. belong has joined
  962. mjk has left
  963. jcbrand has left
  964. adiaholic has left
  965. scorch has left
  966. mukt2 has left
  967. belong has left
  968. mukt2 has joined
  969. Kev has left
  970. Kev has joined
  971. pasdesushi has left
  972. Tobias has left
  973. belong has joined
  974. malthe has joined
  975. jcbrand has joined
  976. robertooo has left
  977. robertooo has joined
  978. mukt2 has left
  979. sonny has left
  980. sonny has joined
  981. ralphm has left
  982. ralphm has joined
  983. mukt2 has joined
  984. sonny has left
  985. sonny has joined
  986. sonny has left
  987. sonny has joined
  988. aerick has left
  989. aerick has joined
  990. lorddavidiii has left
  991. malthe has left
  992. lovetox has left
  993. jl4 has left
  994. sonny has left
  995. sonny has joined
  996. sonny has left
  997. sonny has joined
  998. jcbrand has left
  999. sonny has left
  1000. sonny has joined
  1001. sonny has left
  1002. sonny has joined
  1003. phryk If I recall the situation right you and Zash implemented that but it wasn't complete, so you implemented the necessary extra bits and added them to the XEP but the original author reverted those changes to the XEP.
  1004. govanify has left
  1005. govanify has joined
  1006. Alex has left
  1007. wurstsalat has left
  1008. debacle has left
  1009. mukt2 has left
  1010. mukt2 has joined
  1011. sonny has left
  1012. sonny has joined
  1013. sonny has left
  1014. sonny has joined
  1015. raghavgururajan has left
  1016. raghavgururajan has joined
  1017. marc0s has left
  1018. marc0s has joined
  1019. sonny has left
  1020. sonny has joined
  1021. sonny has left
  1022. andrey.g has left
  1023. sonny has joined
  1024. sonny has left
  1025. sonny has joined
  1026. sonny has left
  1027. sonny has joined
  1028. lovetox has joined
  1029. mukt2 has left
  1030. wladmis has left
  1031. mukt2 has joined
  1032. Server Stats Discoverer (traveler bot) has left
  1033. Matthew has left
  1034. Rixon 👁🗨 has left
  1035. Half-Shot has left
  1036. homebeach has left
  1037. uhoreg has left
  1038. Half-Shot has joined
  1039. Matthew has joined
  1040. Rixon 👁🗨 has joined
  1041. uhoreg has joined
  1042. homebeach has joined
  1043. Server Stats Discoverer (traveler bot) has joined
  1044. floretta has left
  1045. alex11 has joined
  1046. adiaholic has joined
  1047. floretta has joined
  1048. wladmis has joined
  1049. phryk also none of the known client doaps report support for it :P
  1050. Kev has left
  1051. Kev has joined
  1052. adiaholic has left
  1053. mukt2 has left
  1054. mukt2 has joined
  1055. adiaholic has joined
  1056. adiaholic has left
  1057. floretta has left
  1058. floretta has joined
  1059. Menel has left
  1060. emus has left
  1061. karoshi has left
  1062. wladmis has left
  1063. floretta has left
  1064. floretta has joined
  1065. Kev has left
  1066. Kev has joined