jdev - 2022-12-27

  1. Beherit has left

  2. Beherit has joined

  3. marc has left

  4. marc has joined

  5. xnamed has left

  6. adx has joined

  7. Vaulor has left

  8. wurstsalat has left

  9. antranigv has joined

  10. marc has left

  11. marc has joined

  12. PapaTutuWawa has left

  13. antranigv has left

  14. antranigv has joined

  15. antranigv has left

  16. marc has left

  17. marc has joined

  18. antranigv has joined

  19. john-machine has left

  20. Maranda[x] has left

  21. Maranda[x] has joined

  22. john-machine has joined

  23. rubi has left

  24. rubi has joined

  25. rubi has left

  26. rubi has joined

  27. rubi has left

  28. rubi has joined

  29. debacle has left

  30. rubi has left

  31. rubi has joined

  32. pasdesushi has left

  33. Menel has left

  34. rubi has left

  35. adx has left

  36. rubi has joined

  37. antranigv has left

  38. larma has left

  39. YagizĐ° has joined

  40. nik has joined

  41. rubi has left

  42. rubi has joined

  43. stefan has left

  44. marc0s has left

  45. marc0s has joined

  46. rubi has left

  47. rubi has joined

  48. Schimon_ has joined

  49. selurvedu has left

  50. rubi has left

  51. rubi has joined

  52. kapad has left

  53. rubi has left

  54. Millesimus has left

  55. rubi has joined

  56. rubi has left

  57. rubi has joined

  58. nik has left

  59. marc has left

  60. marc has joined

  61. Millesimus has joined

  62. Maranda[x] has left

  63. Maranda has left

  64. Mjolnir Archon has left

  65. rubi has left

  66. rubi has joined

  67. rubi has left

  68. rubi has joined

  69. Menel has joined

  70. rubi has left

  71. rubi has joined

  72. Vaulor has joined

  73. rubi has left

  74. rubi has joined

  75. stefan has joined

  76. rubi has left

  77. rubi has joined

  78. rubi has left

  79. rubi has joined

  80. atomicwatch has joined

  81. rubi has left

  82. rubi has joined

  83. Vaulor has left

  84. rubi has left

  85. rubi has joined

  86. Millesimus has left

  87. Vaulor has joined

  88. Millesimus has joined

  89. MSavoritias (fae,ve) has joined

  90. rubi has left

  91. rubi has joined

  92. wurstsalat has joined

  93. wurstsalat has left

  94. wurstsalat has joined

  95. Millesimus has left

  96. Millesimus has joined

  97. atomicwatch has left

  98. rubi has left

  99. rubi has joined

  100. Mx2 has left

  101. atomicwatch has joined

  102. Mx2 has joined

  103. Vaulor has left

  104. rubi has left

  105. rubi has joined

  106. SouL has left

  107. SouL has joined

  108. Vaulor has joined

  109. rubi has left

  110. Laura has left

  111. atomicwatch has left

  112. rubi has joined

  113. atomicwatch has joined

  114. mirux has joined

  115. Menel has left

  116. nicoco_ has joined

  117. rubi has left

  118. rubi has joined

  119. rubi has left

  120. rubi has joined

  121. atomicwatch has left

  122. nicoco_ has left

  123. atomicwatch has joined

  124. Vaulor has left

  125. rubi has left

  126. rubi has joined

  127. thomaslewis has joined

  128. thomaslewis has left

  129. thomaslewis has joined

  130. MattJ

    nicoco: the additional fields were added in a later version of the XEP. To be compliant with this version, an implementation MUST support those fields, and MUST advertise #extended.

  131. stefan has left

  132. MattJ

    It's not about shaming anyone or not 🙂

  133. thomaslewis has left

  134. rubi has left

  135. Menel has joined

  136. jubalh has left

  137. nicoco_ has joined

  138. Alastair Hogge

    Well said.

  139. thomaslewis has joined

  140. thomaslewis has left

  141. rubi has joined

  142. nicoco_ has left

  143. Vaulor has joined

  144. jubalh has joined

  145. nicoco_ has joined

  146. thomaslewis has joined

  147. stefan has joined

  148. thomaslewis has left

  149. rubi has left

  150. rubi has joined

  151. thomaslewis has joined

  152. thomaslewis has left

  153. john-machine has left

  154. nicoco has joined

  155. nicoco_ has left

  156. nicoco

    MattJ: thanks for the explanation. so if an implementation only supports 3, it urn:xmpp:mam:1 then, I get it. (the shaming part was a joke, no worries ;))

  157. nicoco

    MattJ: thanks for the explanation. so if an implementation only supports 3, it should advertise urn:xmpp:mam:1 then, I get it. (the shaming part was a joke, no worries ;))

  158. jubalh has left

  159. stefan has left

  160. stefan has joined

  161. MattJ

    No, mam:2 did not define the extra 3 fields

  162. john-machine has joined

  163. MattJ

    There are many mam:2 implementations in the wild that don't support the latest revision of the XEP

  164. pep.

    Is there a list of o payloads that shouldn't be broadcasted by a MUC? (to prevent impersonating it)

  165. jonas’


  166. pep.

    All the <{muc*}x/> stuff? And things with stamps? (which are?)

  167. jonas’

    anything in the MUC namespace obviously.

  168. jonas’

    and delay and stanza-id, yes

  169. pep.


  170. jonas’

    only if you advertise the occupant-id feature

  171. jonas’

    (likewise for stanza-id, btw)

  172. jonas’

    and delay and stanza-id must only be stripped if they attempt to impersonate your domain

  173. jonas’

    though you might want to strip them if they otherwise deanonymise the user

  174. jonas’

    oh that's fun

  175. jonas’

    I should not have said that out loud

  176. pep.


  177. pep.

    k. Well I guess it doesn't hurt removing them anyway if they're making look like I did it, even though clients should check disco

  178. pep.

    Ah that means I need to have access to state in this method.. to know my own domain :x

  179. stefan has left

  180. rubi has left

  181. rubi has joined

  182. pep.

    https://xmpp.org/extensions/xep-0045.html#security doesn't seem to mention this. /me adds it to the TODO

  183. jonas’

    what exactly?

  184. pep.

    A list of stuff not to broadcast.

  185. jonas’

    ah, stripping <{muc}x/>

  186. gregory has left

  187. Matrix Traveler (bot) has left

  188. homebeach has left

  189. homebeach has joined

  190. Matrix Traveler (bot) has joined

  191. gregory has joined

  192. pep.

    https://code.bouah.net/pep/hanabi-muc/commit/ce640864cae80f4456ac67c0914e745a8215f658 that's about all I can do without knowledge of my own domain I guess :x

  193. stuart.j.mackintosh has left

  194. stuart.j.mackintosh has joined

  195. pep.

    Next step.

  196. jonas’

    I see an "and" in the commit message :<

  197. jonas’

    (it's disguised as ;, but still)

  198. pep.


  199. pep.

    You have seen nothing.

  200. rubi has left

  201. rubi has joined

  202. pep.

    https://xmpp.org/extensions/xep-0203.html#security < This mentions stripping fwiw

  203. pep.

    https://xmpp.org/extensions/xep-0359.html < This only says validating entities should check whether @from actually supports it.

  204. Mario Sabatino has joined

  205. Mario Sabatino has left

  206. Mario Sabatino has joined

  207. SouL has left

  208. nicoco

    MattJ: I don't grasp it all tbh, but I'll just respect the MUST I guess ;)

  209. rubi has left

  210. rubi has joined

  211. jubalh has joined

  212. marc0s has left

  213. marc0s has joined

  214. stefan has joined

  215. agh has joined

  216. MattJ

    nicoco: I think you've got it, apart from that you implicitly made an assumption that the previous version of the XEP used mam:1

  217. MattJ

    We've had mam:1, mam:2, and mam:2+mam:2#extended

  218. pep.

    (mam:3! :p)

  219. pep.

    Just that it didn't want to be named mam:3

  220. gregory has left

  221. MattJ

    The new changes were all additions, so switching the whole lot to mam:3 would have needlessly broken every existing implementation

  222. gregory has joined

  223. pep.

    I think it's exactly the same really. I hope implementations don't check 'urn:xmpp:mam:2' but '^uxn:xmpp:mam:2$'. So in any case they'd have multiple checks to do (or to change this regex)

  224. pep.

    (if they even use regex)

  225. Mjolnir Archon has joined

  226. Maranda has joined

  227. MattJ

    I hope you're joking 🙂

  228. pep.

    What do you mean

  229. MattJ

    Maybe I misunderstood your statement

  230. kapad has joined

  231. jubalh has left

  232. jonas’


  233. MattJ

    I'm not sure what regex has to do with anything

  234. MattJ

    It has zero applicability here

  235. pep.

    regex or whatever. I hope they check for the full string to equal the namespace they're looking for

  236. pep.

    Not some partial equality

  237. MattJ

    They shouldn't be doing regex, no

  238. pep.

    That's not the point

  239. rubi has left

  240. rubi has joined

  241. nicoco

    we all know what happens when you try to parse XML with regular expressions, don't we?

  242. nicoco

    we all know what happens when we try to parse XML with regular expressions, don't we?

  243. pep.

    Forget I even said anything about regex, it doesn't matter to make this point

  244. MattJ

    I'm happy to say I've never used regex to parse XML, and I would never do so

  245. MattJ

    The sender retracted their previous message but your client does not support that

  246. jonas’

    I cannot say the same.

  247. MattJ

    I did it yesterday, with sed, in a bash script (it was a config file though, not XMPP)

  248. pep.

    So I stand by my comment above, I see no different in using mam:2#extended or mam:3. It's exactly the same change to me for a client to support it

  249. pep.

    (or ignore it)

  250. pep.


  251. Holger

    MattJ: I still believe that MUST can be slightly confusing as it may mislead the reader to believe the client can rely on those fields. Yes if you strictly follow the text then you'll probably get that you should check for the :2#extended feature. But if I see a MUST I'll always assume it was added to make a protocol/interop guarantee, which isn't the case here. So if I knew nothing about 0313 history it'd confuse me as well.

  252. Holger

    No big thing of course.

  253. Maranda has left

  254. Mjolnir Archon has left

  255. MattJ

    pep. [09:17]: > So I stand by my comment above, I see no different in using mam:2#extended or mam:3. It's exactly the same change to me for a client to support it The difference isn't for clients that are updated to support it, the difference is for clients that are not updated - they continue to work

  256. SouL has joined

  257. pep.

    MattJ, they would anyway, since "mam:2" definitely isn't the same string as "mam:2#extended"

  258. gregory has left

  259. MattJ

    Ah, so you're saying the XEP update should have said you MUST advertise mam:2 and mam:3

  260. MattJ

    Could have done that, yes

  261. pep.

    Ah, yeah

  262. pep.

    Ok sorry if that was the confusion

  263. gregory has joined

  264. MattJ

    That would probably have been confusing, as people might have tried using mam:3 in stanzas

  265. MattJ

    #extended is just a disco feature

  266. MattJ

    The core namespace remained mam:2

  267. pep.

    It's just names and conventions. You make them do whatever you want to :)

  268. MattJ

    And we did 🙂

  269. pep.

    I'm not saying it doesn't make sense, it's fine this way. Just that there wasn't much more differences to me to use mam2/3

  270. MattJ

    But it wasn't done only to make upgrading easy, it was done to keep compatibility with existing clients (given that 98% of the protocol is the same)

  271. pep.

    It looks like you're saying mam2/3 wouldn't keep compatibility and I'm saying that's not true. In both cases a server zould advertise both features right?

  272. pep.

    (if it supported both)

  273. MattJ

    It's not as simple as that, unfortunately

  274. pep.

    Ok I don't understand then

  275. pep.

    But it's fine, we can drop it if it gets too long :P

  276. nicoco has left

  277. nicoco has joined

  278. MattJ

    We had implementation experience of supporting multiple namespaces concurrently with e.g. XEP-0198

  279. Sam has left

  280. MattJ

    It's certainly possible, and perfectly fine if it's necessary. But it's not as trivial as it seems on the surface, and there was no need to do it in this case.

  281. pep.

    I actually don't get how it differs technically. 'mam:2#extended' is another version, same as 'mam:3'

  282. MattJ

    No, note how in the XEP, all the elements are still in the mam:2 namespace

  283. rubi has left

  284. pep.

    Ok, it just makes slightly more sense to name it mam:2#foo, I guess, but that doesn't change that you could have advertised anything to say "we support this" and still used mam:2 in the spec

  285. john-machine has left

  286. pep.

    It's just a flag, the name doesn't really matter. It makes it easier for humans for sure (even though some may wonder why you're not using #extended then as the ns :p)

  287. MattJ

    Yes, you're totally right

  288. MattJ

    Given the choice though, I think #extended was a better fit because advertising mam:3 would lead people to assume that's the namespace of the elements too. They might assume that with #extended too of course, but less likely I'd hope.

  289. MattJ

    All we'd need was one server accidentally supporting mam:3 elements and then we'd soon have one or more clients doing it too 🙂

  290. pasdesushi has joined

  291. atomicwatch has left

  292. pep.

    Holger, that "if .. MUST" doesn't disturb me that much. As an analogy I think I prefer !(foo && bar) rather than !foo || !bar. Plus in a spec it can quickly get messy to know what goes with what :/

  293. stefan has left

  294. Holger

    Not sure we mean the same thing? My point is, for me a MUST implies a guarantee, i.e. protocol breakage if it's ignored. In this case there's no breakage if it's ignored, the guarantee only depends on the XEP revision, which is not a protocol thing. So the MUST may be confusing while trying to understand the protocol.

  295. pep.

    Well the MUST is behind a predicate here

  296. jonas’

    Holger, no it doesn't depend on the XEP revisino, it depends on a feature.

  297. Holger

    jonas’: The text says "servers MUST support (and announce) the feature".

  298. pep.

    The text says "Servers supporting"

  299. Holger

    It doesn't say "if the feature is announced, it MUST be supported".

  300. pep.

    It could be made slightly more explicit maybe, with an if

  301. pep.

    Maybe we should stick to simple english in specs, to make that less confusing and more accessible :/

  302. jonas’

    Holger, > Servers supporting fields marked with an asterisk (*) MUST advertise the disco feature 'urn:xmpp:mam:2#extended' and clients that depend on these fields MUST verify that the server advertises this feature before attempting to use them.

  303. pep.

    (That'd definitely help me too)

  304. Holger

    > Six further fields are defined by this XEP and MUST be supported by servers, though all of them are optional for the client.

  305. Holger

    nicoco pointed that out yesterday. I didn't remember it. Which is probably also due to the fact that it makes no sense to me 🙂

  306. jonas’

    Holger, https://xmpp.org/extensions/attic/xep-0313-0.6.html#filter

  307. atomicwatch has joined

  308. jonas’

    the non-asterisk fields were always part of MAM

  309. pasdesushi has left

  310. Holger

    Sure, but those are only three?

  311. jonas’


  312. jonas’


  313. jonas’

    that does indeed sound like a weird thing then

  314. jonas’

    MattJ, wording issue or intentional? :)

  315. Matrix Traveler (bot) has left

  316. homebeach has left

  317. homebeach has joined

  318. Matrix Traveler (bot) has joined

  319. jonas’

    ("Six fields MUST be supported; servers supporting the last three MUST announce feature X". I would've expected: "Three fields MUST be supported, the other three fields MUST be supported iff the feature is announced")

  320. Holger

    đź‘Ť If the real intention simply was to encourage servers to offer them, it could just be stated that way, in my book.

  321. stefan has joined

  322. john-machine has joined

  323. stefan has left

  324. agh has left

  325. agh has joined

  326. pasdesushi has joined

  327. MattJ

    It's not encouragement, they are mandatory

  328. MattJ

    As is #extended

  329. debacle has joined

  330. pep.

    It's there because.. some previous version of mam:2 didn't have them?

  331. jonas’

    MattJ, but that's a weird thing to say if "clients that depend on these fields MUST verify that the server advertises this feature before attempting to use them"

  332. jonas’

    but I get your perspective now

  333. jonas’

    with mam:2 as one version, and mam:2+mam:2#extended as the next version.

  334. jonas’

    interesting way to look at things, I shall keep that in mind.

  335. pep.

    It's there because.. some previous version of 313 didn't have them?

  336. rubi has joined

  337. Menel has left

  338. MattJ

    The alternative was mam:3 and breaking the world, or making these fields perpetually optional

  339. Holger

    Effectively they _are_ optional until we bump to mam:3.

  340. MattJ

    How so?

  341. MattJ

    It's a federated open ecosystem. By that logic, everything ever is always optional 🙂

  342. pep.

    And even the bump to mam:3 would be optional :P

  343. MattJ

    This is no different from bumping to mam:3 really, as pep said... they are just strings

  344. Holger

    Adhering to a MUST is not "optional".

  345. Holger

    In my book.

  346. MattJ

    The only difference is backwards compatibility is gained for legacy implementations

  347. MattJ

    Agreed, but you just wrote that it is

  348. Holger

    Well I expressed my concerns above, guess I won't bring them over better by adding even more text 🙂 Call it a day.

  349. pep.

    Holger, it is. It depends on time, motivation, money, [insert something here]. And while that's not implemented you're just "not compliant"(tm), or half-compliant

  350. pep.

    (or something-compliant)

  351. MattJ

    A server cannot be compliant with the latest XEP version without supporting those things

  352. MattJ

    They are not optional

  353. larma has joined

  354. MattJ

    However implementations may not be up to date with the latest version of the XEP (whether it uses mam:3 or #extended)

  355. adx has joined

  356. Holger

    Yes I get that idea. I just think it's confusing to do offer a guarantee that depends on a XEP revision, as the latter isn't a protocol thing.

  357. antranigv has joined

  358. MattJ

    We do that all the time though

  359. MattJ

    I think you're only confused because we didn't call it mam:3

  360. john-machine has left

  361. Holger

    We may disagree but that's definitely not my confusion, no.

  362. MattJ


  363. MattJ

    So a XEP can never mandate stuff in a new revision?

  364. rubi has left

  365. rubi has joined

  366. pep.

    Or from which point of its lifecycle (knowing that MAM was experimental for a really long time while being implemented in many places)

  367. marc has left

  368. Holger

    MattJ: If ignoring the new MUST breaks nothing then my answer would be no.

  369. marc has joined

  370. SouL has left

  371. pep.

    no it can't mandate stuff in newer revisions?

  372. mirux has left

  373. mirux has joined

  374. MattJ

    I think that's where we disagree then

  375. Holger

    Not without actually bumping the namespace, no.

  376. pep.

    Well it has been bumped here

  377. MattJ

    This happens widely in protocols

  378. marc has left

  379. MattJ

    Like how TLS 1.3 has many new MUSTs, but still advertises as TLS 1.2 in the handshake for compatibility purposes

  380. marc has joined

  381. MattJ

    In practice many things still accept 1.2 right now, but that won't always be the case

  382. john-machine has joined

  383. Wojtek has joined

  384. flow

    doesn't tls 1.3 still negotiate that it's 1.3 despite the fact that the TLS version announced in the hello message is still 1.2?

  385. pulkomandy has left

  386. kapad

    as an somehow 'outsider', means that dont deal in developing xmpp server/clients, but also have read some of the xeps around, i dare to say that i feel a xep never give the choice how you gonna advertise a feature, but how you must. xep describes both the implementation and the language between xmpp entities. and because that lang spoken by machines must follow syntax at any cost

  387. Matrix Traveler (bot) has left

  388. homebeach has left

  389. homebeach has joined

  390. Matrix Traveler (bot) has joined

  391. rubi has left

  392. rubi has joined

  393. xnamed has joined

  394. SouL has joined

  395. pulkomandy has joined

  396. flow

    > MattJ> So a XEP can never mandate stuff in a new revision? It is less about the revision, but about mandating new stuff without a namespace bump. And even there, it depends on the "new stuff"

  397. flow

    IMHO the mam xep could have simply strongly encouraged mam:2#extended, instead of mandating it with a new revision under the same namespace

  398. pep.

    There is a namespace bump

  399. flow

    I obviously don't see it so feel free to enlighten me, it appears the namespace is still mam:2

  400. pep.

    The bump is #extended

  401. flow

    that's one way to view it, but certainly not the tranditional namespace bump kind

  402. pep.

    As I said earlier, it's as if the spec had said "advertize both mam:3 and mam:2 to stay compatible"

  403. Sam has joined

  404. flow

    pep., fwiw, I agree with MattJ that bumping to mam:3 just because there fields where added whould have been destructive

  405. flow

    because then suddenly all mam:2-only implementations could no longer use mam:3-only services, for no good reason

  406. Mjolnir Archon has joined

  407. Maranda has joined

  408. pep.

    I think you've missed my point then, but it's fine

  409. flow

    if you "extend" a spec, by basically optional fields, then the mam:2#extended approach is sensible

  410. flow

    pep., very well possible, it was a large backlog to read ;)

  411. pep.

    You can "extend" a spec naming the extended ns whatever you like, here it's "mam:2#extended", it could have been "mam:3"

  412. pep.

    In both cases the spec says you advertize "mam:2" as well to stay compatible, and you're done

  413. pep.

    Anyway, there is a bump to me here

  414. pep.

    Just not the kind we're used to see (numbers) but it's the exact same thing to me. The string changes

  415. rubi has left

  416. pep.

    Just that 313 defines "Compatibility with the spec" as "You have implemented all-the-things". I doubt generally we see this wording in other specs? But I don't really see an issue with it.

  417. pep.

    It "only" prevents you to call your impl fully compatible if it doesn't implement everything

  418. rubi has joined

  419. john-machine has left

  420. nik has joined

  421. jonas’

    I don't think that sticking to the notion of "one namespace per document version" is a good thing

  422. jonas’

    it's counter to the extensibility idea

  423. pep.

    I agree

  424. jonas’

    as long as elements don't change incompatibly, we should stick with the same identifier

  425. jonas’

    (this has been done in MIX IIRC)

  426. jonas’

    so this step, with adding mam:2#extended *and* mandating it in the current XEP version (which was, by the way, before stabilization as 1.0), is very sensible to me

  427. jonas’

    so this step, with adding mam:2#extended *and* mandating it in the current XEP version (which was, by the way, before stabilization as 1.0) without changing anything existing as mam:2, is very sensible to me

  428. jonas’

    and using mam:2#extended instead of mam:3 is also good because it clearly shows that this is not the traditional way we've handled namespace versioning

  429. jonas’

    so all fine by me

  430. stuart.j.mackintosh has left

  431. stuart.j.mackintosh has joined

  432. Wojtek has left

  433. flow

    mandating #extended in the current MAM version gains you nothing compared to just strongly encouraging it, instead it just causes confusion.

  434. techmetx11 has left

  435. techmetx11 has joined

  436. flow

    simply because there is no gurantee that there isn't an implementation out there that never has seen the new XEP revision and just announces mam:2

  437. jonas’

    flow, I think quite the contrary

  438. jonas’

    to someone coming newly to the spec, it's better to mandate it.

  439. jonas’

    that's ok, clients are clearly told they need to check for #extended

  440. flow

    why? the spec could simply say "if you are working on an mam implementation, then you really should also implement #extended"

  441. rubi has left

  442. rubi has joined

  443. flow

    that would have the same effect

  444. jonas’

    that are more words than "MUST implement this"

  445. jonas’

    less words good

  446. jonas’

    you'd still need the notice that client devs need to check for the feature explicitly

  447. flow

    instead, what we have causes confusion, as can be seen by the question that started this discussion

  448. Holger

    "Why on earth would I need to check for #extended if it's mandatory?"

  449. flow

    what Holger says

  450. pep.

    Because specs are living documents :x

  451. pep.

    Things change

  452. flow

    pep., that shouldn't be an excuse that they can be confusing

  453. flow

    or even cause interoperability issues

  454. jonas’

    we can add "because it was added as an extension to mam:2"

  455. jonas’

    but I'm not sure that helps anyone

  456. MattJ

    Holger [11:21]: > "Why on earth would I need to check for #extended if it's mandatory?" Why check for mam:3 if it's mandatory?

  457. MattJ

    It's the same difference

  458. pep.

    s/ for mam:3/ even :P

  459. flow

    I don't see how mam:3 compares to the mam:2 + #extended situation

  460. jonas’

    imagine those form fields had been a separate document

  461. MattJ

    I don't see how it differs

  462. jonas’

    and it'll become clear

  463. flow

    mam:2 can work without #extended, it is a prime example of an extension that does not break backwards compatibility on the protcol layer

  464. nik has left

  465. MattJ

    mam:1 still works if implemented, too

  466. Holger

    MattJ: Are you talking mam:3 instead of #extended or mam:3 instead of mam:2+#extended?

  467. MattJ

    Either works

  468. flow

    mam:3 instead of #extended would be pretty strange and not idomatic

  469. Holger

    MattJ: The former breaks compat, obviously.

  470. MattJ

    A client that depends on the stuff in the latest revision can check only for #extended

  471. flow

    and mam:3 instead of mam:2+#extended would be destructive, as in, cause interoperability issues for no reason

  472. nik has joined

  473. Holger

    MattJ: Yes. I'm not arguing that something doesn't work. Just that it's slightly confusing when trying to grasp the spec.

  474. jonas’

    Holger, I guess PRs welcome then

  475. pep.

    "jonas’> imagine those form fields had been a separate document" < this really

  476. flow

    I am not sure what would change if those form fields would be specified separate document?

  477. Holger

    Would 0313 mandate to implement it?

  478. flow

    but I view them as something that could have been specified in an extra document (like the various pubsub extensions)

  479. flow

    not sure how this is relevant for the discussion, though

  480. jonas’

    flow, if they had been a separate document, nobody would be confused about the "mandatory fields and check for this feature and don't rely on it unless you see that feature" thing

  481. flow

    if they where in a separte document, then it would also be strange if the mam xep says that you also need to implement the mam:2#extended xep…

  482. jonas’

    right, it wouldn't say that

  483. jonas’

    instead we'd have an indiscoverable mess

  484. flow

    why would it be indiscoverable?

  485. jonas’

    how would you learn that XEP-5555 is relevant to you, when just looking at XEP-0313?

  486. flow

    forward pointer in the mam xep?

  487. MattJ

    Because MAM would no longer mean "XEP-0313"

  488. flow

    similar to pubsub does not just mean xep60

  489. jonas’

    which isn't exactly great

  490. MattJ

    Once you add the pointer and say it's mandatory, might as well put it in the same doc 🙂

  491. flow

    right, but I am arguing that saying it is mandatory gains you nothing and only causes confusion, compared to just strongly recommending it

  492. marc has left

  493. marc has joined

  494. pep.

    (Also how MUC doesn't just mean 0045. /me looks at https://wiki.xmpp.org/web/MUC_Extensions )

  495. rubi has left

  496. pep.

    "Once you add the pointer and say it's mandatory, might as well put it in the same doc" < "It depends"(tm)

  497. rubi has joined

  498. pep.

    The doc gets huge and messy, you might want to split it up

  499. john-machine has joined

  500. pep.

    Just that the xep discoverability story is meh

  501. marc0s has left

  502. marc0s has joined

  503. PapaTutuWawa has joined

  504. gregory has left

  505. Dele Olajide has joined

  506. gregory has joined

  507. stefan has joined

  508. rubi has left

  509. rubi has joined

  510. nicoco has left

  511. nicoco has joined

  512. hearty has joined

  513. Kev has joined

  514. Kev has left

  515. Laura has joined

  516. rubi has left

  517. rubi has joined

  518. adx has left

  519. pasdesushi has left

  520. rubi has left

  521. rubi has joined

  522. marc0s has left

  523. marc0s has joined

  524. adx has joined

  525. marc0s has left

  526. marc0s has joined

  527. nik has left

  528. Wojtek has joined

  529. Wojtek has left

  530. rubi has left

  531. rubi has joined

  532. Wojtek has joined

  533. gregory has left

  534. gregory has joined

  535. pulkomandy has left

  536. marc0s has left

  537. marc0s has joined

  538. Wojtek has left

  539. marc0s has left

  540. marc0s has joined

  541. kapad has left

  542. inky has left

  543. Vaulor has left

  544. Vaulor has joined

  545. pulkomandy has joined

  546. rubi has left

  547. rubi has joined

  548. adx has left

  549. Wojtek has joined

  550. Wojtek has left

  551. Matrix Traveler (bot) has left

  552. homebeach has left

  553. homebeach has joined

  554. Matrix Traveler (bot) has joined

  555. Wojtek has joined

  556. adx has joined

  557. gregory has left

  558. gregory has joined

  559. rubi has left

  560. nik has joined

  561. norayr has joined

  562. marc0s has left

  563. marc0s has joined

  564. marc0s has left

  565. marc0s has joined

  566. gregory has left

  567. gregory has joined

  568. hearty has left

  569. atomicwatch has left

  570. gregory has left

  571. gregory has joined

  572. sonny has left

  573. rubi has joined

  574. pasdesushi has joined

  575. sonny has joined

  576. nik has left

  577. nik has joined

  578. atomicwatch has joined

  579. Vaulor has left

  580. goffi has left

  581. goffi has joined

  582. Vaulor has joined

  583. rubi has left

  584. gregory has left

  585. nik has left

  586. gregory has joined

  587. PapaTutuWawa has left

  588. SouL has left

  589. SouL has joined

  590. nik has joined

  591. rom1dep has left

  592. hearty has joined

  593. Vaulor has left

  594. nik has left

  595. inky has joined

  596. nik has joined

  597. goffi has left

  598. rom1dep has joined

  599. marc0s has left

  600. marc0s has joined

  601. Vaulor has joined

  602. rubi has joined

  603. goffi has joined

  604. marc0s has left

  605. marc0s has joined

  606. Wojtek has left

  607. marc0s has left

  608. marc0s has joined

  609. Wojtek has joined

  610. nik has left

  611. nik has joined

  612. marc0s has left

  613. marc0s has joined

  614. marc0s has left

  615. marc0s has joined

  616. rubi has left

  617. rubi has joined

  618. goffi has left

  619. goffi has joined

  620. rubi has left

  621. rubi has joined

  622. gregory has left

  623. oshn has left

  624. gregory has joined

  625. Menel has joined

  626. Kev has joined

  627. Kev has left

  628. rubi has left

  629. rubi has joined

  630. oshn has joined

  631. Mario Sabatino has left

  632. Mario Sabatino has joined

  633. rubi has left

  634. rubi has joined

  635. gregory has left

  636. Wojtek has left

  637. gregory has joined

  638. PapaTutuWawa has joined

  639. rubi has left

  640. Maranda[x] has joined

  641. gregory has left

  642. nik has left

  643. gregory has joined

  644. thomaslewis has joined

  645. thomaslewis has left

  646. nik has joined

  647. Vaulor has left

  648. gregory has left

  649. gregory has joined

  650. rubi has joined

  651. jubalh has joined

  652. MSavoritias (fae,ve) has left

  653. MSavoritias (fae,ve) has joined

  654. MSavoritias (fae,ve) has left

  655. MSavoritias (fae,ve) has joined

  656. rubi has left

  657. nik has left

  658. nik has joined

  659. Laura has left

  660. pulkomandy has left

  661. pulkomandy has joined

  662. nik has left

  663. pulkomandy has left

  664. pulkomandy has joined

  665. Laura has joined

  666. lovetox has left

  667. soulcaramel has left

  668. lovetox has joined

  669. stefan has left

  670. pulkomandy has left

  671. gregory has left

  672. flow

    right, but I am arguing that saying mam:2#extended is mandatory gains you nothing and only causes confusion, compared to just strongly recommending mam:2#extended

  673. gregory has joined

  674. pulkomandy has joined

  675. Zash

    flow, if you don't implement #extended then what you have is https://xmpp.org/extensions/attic/xep-0313-0.6.3.html

  676. jubalh has left

  677. PapaTutuWawa has left

  678. pulkomandy has left

  679. SouL has left

  680. pulkomandy has joined

  681. Sam has left

  682. Sam has joined

  683. SouL has joined

  684. rom1dep has left

  685. rom1dep has joined

  686. Patiga has left

  687. Wojtek has joined

  688. rubi has joined

  689. Holger

    I (we?) are arguing this MUST to be confusing, at least to newcomers. There's an 'extended' feature that servers MUST implement and announce. To me, the obvious question would be "why do clients need to check for it if it's mandatory?" Even if I'm on the right track and assume spec evolution to be the culprit, I'd go on "then why is it mandatory now, am I missing something?". I may be wrong about this potential confusion. But I'm confused how you guys keep insisting on explaining the status quo, rather than explaining why you see no potential for confusion 🙂

  690. Holger

    I mean this entire topic came up due to the confusion I have in mind.

  691. jonas’

    propose wording changes

  692. jonas’

    best way to discuss stuff is when looking at a diff

  693. Holger

    Yeah, except that I'm not sure how to word the reason for it being mandatory now.

  694. Holger

    But I can propose wording that explains how the additional feature exists due to spec evolution, yes.

  695. gregory has left

  696. gregory has joined

  697. rubi has left

  698. john-machine has left

  699. krit has left

  700. krit has joined

  701. PapaTutuWawa has joined

  702. MattJ

    > rather than explaining why you see no potential for confusion I can't say I don't see potential for confusion, rather I see potential for confusion everywhere I look for it. I'm happy to find ways to reduce confusion, but you have to draw a line somewhere

  703. MattJ

    Adding more words about a couple of simple MUSTs also has potential to cause confusion

  704. krit has left

  705. john-machine has joined

  706. krit has joined

  707. Kev has joined

  708. Kev has left

  709. Kev has joined

  710. Kev has left

  711. Mx2 has left

  712. gregory has left

  713. gregory has joined

  714. thomaslewis has joined

  715. thomaslewis has left

  716. stefan has joined

  717. gregory has left

  718. gregory has joined

  719. Mx2 has joined

  720. Mx2 has left

  721. MSavoritias (fae,ve) has left

  722. stefan has left

  723. Maranda[x] has left

  724. gregory has left

  725. gregory has joined

  726. gregory has left

  727. gregory has joined

  728. nicoco has left

  729. nicoco has joined

  730. gregory has left

  731. gregory has joined

  732. selurvedu has joined

  733. YagizĐ° has left

  734. Wojtek has left

  735. gregory has left

  736. gregory has joined

  737. atomicwatch has left

  738. Vaulor has joined

  739. gregory has left

  740. gregory has joined

  741. Patiga has joined

  742. gregory has left

  743. Patiga has left

  744. Patiga has joined

  745. gregory has joined

  746. Trung has left

  747. rubi has joined

  748. gregory has left

  749. gregory has joined

  750. mirux has left

  751. qy has left

  752. qy has joined

  753. stefan has joined

  754. gregory has left

  755. gregory has joined

  756. Dele Olajide has left

  757. Dele Olajide has joined

  758. rubi has left

  759. Dele Olajide has left

  760. Dele Olajide has joined

  761. Dele Olajide has left

  762. rubi has joined

  763. rubi has left

  764. rubi has joined

  765. Millesimus has left

  766. Mx2 has joined

  767. Millesimus has joined

  768. gregory has left

  769. Millesimus has left

  770. Mario Sabatino has left

  771. gregory has joined

  772. rubi has left

  773. rubi has joined

  774. nicoco has left

  775. SouL has left

  776. PapaTutuWawa has left

  777. PapaTutuWawa has joined

  778. PapaTutuWawa has left

  779. Vaulor has left

  780. Millesimus has joined

  781. rubi has left

  782. rubi has joined

  783. gregory has left

  784. Schimon_ has left

  785. gregory has joined

  786. Millesimus has left

  787. wurstsalat has left