XSF logo XSF Discussion - 2017-09-12


  1. Guus has left
  2. jcbrand has left
  3. Martin has joined
  4. tim@boese-ban.de has joined
  5. mimi89999 has joined
  6. ralphm has joined
  7. andrey.g has left
  8. Guus has left
  9. debacle has joined
  10. goffi Ge0rG: Guus: just for the record, I've not "fought" other groups, I've just have complained about the FAQ and only with Matrix. Beside that I have nothing against Matrix as a technology or any other FOSS project
  11. Steve Kille has left
  12. jubalh has joined
  13. Steve Kille has left
  14. jcbrand has joined
  15. efrit has joined
  16. edhelas has left
  17. edhelas has joined
  18. edhelas has left
  19. edhelas has joined
  20. ralphm has joined
  21. tim@boese-ban.de has joined
  22. Ge0rG goffi: sorry, my statement wasn't in any way related to you
  23. tim@boese-ban.de has joined
  24. Guus has left
  25. jubalh has joined
  26. jubalh has left
  27. Guus has left
  28. vanitasvitae has joined
  29. lskdjf has joined
  30. Valerian has left
  31. Valerian has joined
  32. Valerian has left
  33. mimi89999 has joined
  34. stefandxm has joined
  35. Valerian has joined
  36. tim@boese-ban.de has joined
  37. tim@boese-ban.de has joined
  38. stefandxm has left
  39. ralphm has joined
  40. Alex has joined
  41. Holger has left
  42. efrit has left
  43. intosi has left
  44. ralphm has joined
  45. jonasw if someone from board is around, can you please tell me whether https://github.com/xsf/xmpp.org/pull/358#issuecomment-328796484 makes it sufficiently clear why I think that board needs to be involved?
  46. jonasw I thought it was obvious from linking #200, sorry for being unclear and wasting your time at first.
  47. vanitasvitae has left
  48. goffi has left
  49. andrey.g has joined
  50. vanitasvitae has joined
  51. goffi Ge0rG: no worries :). Just wanted to be sure nobody think I'm doing any kind of holy war ;)
  52. SouL :D
  53. pep. goffi, I'd be interested in a diff :)
  54. jonasw pep., https://github.com/matrix-org/matrix-doc/commit/414ef70592a335356122052dd5952af5adbfde8e
  55. pep. heh, nice
  56. SouL You were fast, jonasw
  57. jonasw awesomebar is being awesome
  58. jonasw github could use a todo feature like gitlab has
  59. pep. right, so they did some decorative fixes, and removed a few taunts
  60. ralphm has joined
  61. goffi pep.: yes it still full of wrong statements, but it's a bit better, and the sentence I was most annoyed of ("The whole subject of XMPP vs Matrix seems to bring out the worst in people.") has been removed.
  62. pep. yeah
  63. goffi if you want to see the whole story, you can check https://mastodon.social/@Goffi/17772081
  64. jubalh has joined
  65. SouL thanks
  66. goffi it seems that mastodon has some kind of protocol split issue with GNU Social, and it's moving away from ostatus. We start to have a bunch of mostly incompatibles FOSS "social" protocols :-/
  67. jonasw gateway all the things!
  68. goffi that's handy (and planed), but it's a inelegant workaround, instead of using compatible protocols.
  69. jonasw yupp
  70. Ge0rG Just migrate everything to xmpp. Or to jabber. Or, better, both of them at the same time.
  71. goffi :)
  72. goffi that's plan also: 1) gateway everything 2) ??? 3) XMPP world domination
  73. pep. goffi, but it's better to stay incompatible with half-arsed gateways than having to agree on something you know
  74. pep. has left
  75. pep. has left
  76. dwd pep., That's more or less the story of Internet Mail, though.
  77. efrit has joined
  78. pep. has joined
  79. Valerian has left
  80. Valerian has joined
  81. Valerian has left
  82. vanitasvitae has left
  83. vanitasvitae has joined
  84. Martin has left
  85. jabberatdemo has joined
  86. lumi has joined
  87. jabberatdemo has left
  88. jabberatdemo has joined
  89. Guus has left
  90. tim@boese-ban.de has joined
  91. jabberatdemo has left
  92. Guus has left
  93. jcbrand has left
  94. Guus has left
  95. ralphm has joined
  96. tim@boese-ban.de has joined
  97. Guus has left
  98. Valerian has joined
  99. suzyo has joined
  100. jere has joined
  101. la|r|ma has left
  102. waqas has joined
  103. edhelas has left
  104. edhelas has joined
  105. lskdjf has joined
  106. ralphm has joined
  107. Flow has left
  108. jabberatdemo has joined
  109. jabberatdemo has left
  110. jabberatdemo has joined
  111. tim@boese-ban.de has joined
  112. jabberatdemo has left
  113. jabberatdemo has joined
  114. test has joined
  115. test has left
  116. jabberatdemo has left
  117. stefandxm has joined
  118. Alex has left
  119. stefandxm has left
  120. jcbrand has joined
  121. ralphm has joined
  122. tim@boese-ban.de has joined
  123. Flow has joined
  124. ralphm has left
  125. Yagiza has joined
  126. tim@boese-ban.de has joined
  127. Alex has joined
  128. ralphm has joined
  129. Martin has joined
  130. fp-tester has left
  131. fp-tester has joined
  132. tim@boese-ban.de has joined
  133. ralphm has joined
  134. Steffen Larsen has joined
  135. Steffen Larsen has left
  136. stefandxm has joined
  137. moparisthebest has joined
  138. lumi has left
  139. lumi has joined
  140. stefandxm has left
  141. stefandxm has joined
  142. edhelas memberbot@xmpp.org doesnt answer my requests
  143. jonasw cc @ Alex ^
  144. Alex edhelas: you must be whitelisted
  145. Ge0rG has joined
  146. edhelas I was
  147. Alex let me know your Jid and I will check
  148. Alex after the server crash we lost all whitelist
  149. Alex the list is client side only
  150. Alex send me an email with your Jid and I will check
  151. goffi I've had trouble with it too, it was not responding and I've had to insist
  152. Alex also check that there are no s2s issues to xmpp.org
  153. goffi has left
  154. goffi has joined
  155. edhelas Alex, working, thanks !
  156. Alex ok, you were not whitelisted then
  157. Valerian has left
  158. Valerian has joined
  159. Valerian has left
  160. goffi Alex: oh just seen your message saying you've added my jid, so it was you afterall :)
  161. goffi (you're quick)
  162. lskdjf has left
  163. Martin has left
  164. efrit has left
  165. Ge0rG has left
  166. efrit has joined
  167. tim@boese-ban.de has joined
  168. ralphm has joined
  169. Martin has joined
  170. goffi has left
  171. Valerian has joined
  172. ralphm has left
  173. Valerian has left
  174. Valerian has joined
  175. lovetox has joined
  176. jere has left
  177. jjrh has left
  178. jere has joined
  179. Valerian has left
  180. Valerian has joined
  181. jjrh Ge0rG cool they allow you to connect. There isn't a good reason why they wouldn't but for whatever reason companies like to lock their stuff down. Has riot formally engaged with the xsf?
  182. Ge0rG has left
  183. ralphm has joined
  184. jubalh has left
  185. sonny has left
  186. sonny has joined
  187. efrit has left
  188. sonny has joined
  189. sonny has joined
  190. sonny has left
  191. sonny has joined
  192. jjrh My $0.02 is that I don't think matrix is any threat to xmpp. They are the new hot shiny thing and that's fine and cool - competing open standards is a good thing and in the end there is no reason xmpp can't interoperate. People looking for a protocol that is ready today, field tested and a reasonable assurance it will be supported now and in the future will choose xmpp.
  193. jjrh Being fairly new to xmpp/xsf I'm amazed at the number of places xmpp pops up - it's really cool.
  194. jjrh You got sip handsets supporting xmpp!
  195. jjrh has left
  196. stefandxm has left
  197. stefandxm has joined
  198. jjrh has left
  199. jjrh has left
  200. jjrh has left
  201. stefandxm has left
  202. stefandxm has joined
  203. efrit has joined
  204. Ge0rG has left
  205. jabberatdemo has joined
  206. jonasw I find it interesting that the ejabberd people are the ones arguing the loudest against the dependency between XEP-0191 and XEP-0377, or am I just misperceiving that?
  207. jonasw not to blame anyone, I just find it curious
  208. Holger jonasw: Whatever that would have to do with anything :-) I implemented the current 0377 for ejabberd, I just think an artificial dependency is stupid.
  209. Holger And quite a few non-ejabberd people agreed on the list, no?
  210. jonasw Holger, implicitly, I was wondering whether erlang maybe more strongly enforces separation between components, not knowing much about erlang
  211. SamWhited It's not an artificial dependency; it's expanding the blocking command feature to support providing a reason for the block.
  212. jonasw SamWhited, I find the XEP named misleadingly then
  213. Holger And it's not like the world falls apart if we do it this way, so I should've shut up earlier. I'm just a little baffled how this dependency is justified with reasoning such as "why not?" or "might save a round-trip" or "might enforce my UI on others".
  214. jonasw and the whole section about the payload can be omitted in favour of "how to use with blocking"
  215. SamWhited jonasw: Yes, I agreed to that on list… it may be better to change it or merge it into the blocking command XEP.
  216. Holger SamWhited: Sigh.
  217. suzyo has left
  218. Holger SamWhited: It would be a dependency if I couldn't report spam without also blocking someone.
  219. jubalh has joined
  220. Holger Those things are distinct actions and I can of course do either without doing the other.
  221. Holger So letting one depend on the other is artificial.
  222. SamWhited If you report something is spam, why would you *not* want to block that JID as well?
  223. SamWhited *as
  224. stefandxm this is interesting. is it common / considered "ok" to have one xep extend the content of another xep without the first xep explicitly saying so? (i have a similair challenge)
  225. stefandxm iam thinking about the schemas
  226. jonasw first, it appears to be ineffective and thus a waste of resources. second, if it *isn’t* ineffective, I could be an operator of a service which also uses machine learning to learn spam messages. I would want to know if I receive further spam from the same JID or if I see it being caught by the spam filters
  227. Wiktor has joined
  228. jonasw stefandxm, I think if your extension lives in a different namespace, it is safe to do that
  229. stefandxm but it must still be allowed in the top schema
  230. SamWhited What resource is being wasted? I do agree it's probably ineeffective since they're probably using tons of throwaway JIDs, but I don't see it as hurting anything or wasting resources either
  231. jonasw (of course, you need to ensure that entities are on the same page on what is supported and understood, but an entity which doesn’t understand the new namespaced element should simply discard)
  232. stefandxm by using any or so?
  233. jonasw stefandxm, the schemas are not normative in anycase
  234. jonasw SamWhited, storage for the blocklist
  235. stefandxm jonasw, isnt that up to the xep?
  236. Holger SamWhited: Maybe the server doesn't support blocking, maybe we'll decide to replace blocking with yet another XEP, maybe the server still does 0016, maybe we come to the conclusion that blocking isn't useful due to changing JIDs, I don't know. My point is that it doesn't matter whether your assumption holds. Independent XEPs will work either way.
  237. SamWhited jonasw: If you have that little storage you have other problems, that doesn't even seem worth considering
  238. jonasw SamWhited, sure.
  239. SamWhited Holger: I think that's where we disagree, in any of those cases you should be using something else. Us trying to make general purpose XEPs that are one-size-fits-all is why XMPP is almost entirely broken all the time
  240. jonasw waste of resources is not my primary argument. I generally concur with what Holger writes on list
  241. jubalh has left
  242. jonasw SamWhited, you are right about that, but I don’t think this is one of those cases
  243. SamWhited I do. If we separate them to support everything else under the sun then everything immediately becomes more complicated:
  244. Holger SamWhited: I'm totally against those monster XEPs. But I'm arguing for an extremely simple XEP that does one thing well.
  245. SamWhited Now you have to decide where to send the blocking IQ; does it go to the server? Another client? A spam reporting service? These aren't options I want to exist.
  246. stefandxm I would want it to exist :)
  247. jonasw SamWhited, why the heck would the blocking IQ not go to the server?
  248. Holger SamWhited: To the local server of course.
  249. stefandxm i would want to subscribe to a reporting service that i may chose myself
  250. Holger SamWhited: The XEP should state that, just as the blocking XEP does.
  251. jonasw only the local server can block stanzas for you O_o
  252. stefandxm and then i would use the data from that reporting service to make private blocking decisions
  253. stefandxm just as with spam lists in mail
  254. Holger Now Stefan comes along and everthing falls apart, as usual!
  255. stefandxm :D
  256. jonasw where the spam reporting goes, that should be the local server by default as Holger says, even if only because the only the local server has enough context to make use of that report
  257. SamWhited stefandxm: That works with the current system :)
  258. SamWhited (and would continue to work with the system Holger and jonasw are talking about)
  259. Holger stefandxm: Are you following the standards@ list?
  260. jonasw SamWhited, how does that work with the current system, unless you’re sending something semantically different from a simple spam report to report spam?
  261. Holger stefandxm: Evgeniy (zinid) was complaining about the same Schema issues you mentioned.
  262. stefandxm holger: not anymore :) and i didnt comment on the broad topic just to the generic sense =)
  263. SamWhited jonasw: Right, sorry, what I should have said was "either way we would need to include the payload, but then it can be forwarded wherever you want"
  264. stefandxm holger: I understand he did. mixing schemas like that without having the parent schema explicitly saying its allowe breaks the schemas completely
  265. SamWhited Or you need to know the payload
  266. Holger stefandxm: But I think the general consensus is that you can throw new stuff into existing XML because you're expected to ignore unknown stuff.
  267. stefandxm thats not how xml works
  268. Holger It's how XMPP works :-)
  269. jonasw stefandxm, I think it’s how XMPP … exactly
  270. stefandxm where is that written?
  271. SamWhited I thought 6120 specifically said you had to tolerate unknown namespaces, but I can't find it with a quick search
  272. Holger It does, for clients.
  273. SamWhited But regardless, it's how XMPP works in practice these days even if the original RFC doesn't specifically say it
  274. jonasw Holger, only with a stretch
  275. Holger (Was mentioned in the thread.)
  276. jonasw Holger, I did mention it, and I find my own argument rather weak
  277. Holger jonasw: Yeah well we're doing the same thing elsewhere and Evgeniy keeps being frustrated about this.
  278. jonasw Holger, I also think that it is kind of a design smell when we do this
  279. jonasw it is here, and it is in MIX with the roster query
  280. Wiktor has left
  281. jonasw in both cases, client side, I’ll have to mix components which have nothing to do with each other
  282. jabberatdemo has left
  283. SamWhited I don't understand why you'd have to "mix" anything. Just build this into whatever your blocking command module is.
  284. Holger I agree that this is the general consensus and that 6120 allows this. I'm not so sure whether the idea behing 6120 really was that XEPs should consciously do this, rather than just "be liberal in what you expect".
  285. jonasw SamWhited, sure, but semantically spam reporting has not much to do with blocking, in my opinion
  286. Holger stefandxm: > Clients are advised not to rely on the ability to send data that does not conform to the schemas, and SHOULD ignore any non-conformant elements or attributes https://tools.ietf.org/html/rfc6120#section-11.4
  287. Martin has left
  288. Ge0rG has left
  289. jonasw Holger, yes, I think this claim (in context) only applies to the schemas in RFC 6120
  290. Zash Leaving the decision about whether to report as spam and/or block to implementators instead of the XEP ...
  291. jonasw > An implementation MAY choose to accept or send only data that has been explicitly validated against the schemas provided in this document, but such behavior is OPTIONAL.
  292. stefandxm i dont get it :)
  293. stefandxm i mean, i dont get why a client that knows about a namespace (and its schema) should let through garbage
  294. SamWhited Because we have a lot of different clients and servers and enough interoperability problems without denying every element that has some clients proprietary extension in it.
  295. Holger jonasw: And I also doubt the idea was that an XEP would consciously invalidate an 6120 schema.
  296. stefandxm samwhited: so because clients are sucky and doesnt support schemas properly good clients should ditch the schema because of because?
  297. jonasw Holger, it’s not an 6120 schema though (but I agree that a XEP SHOULD NOT conciously violate another XEPs schema, too)
  298. Holger Yes no that's not what I meant ... whatever :-)
  299. stefandxm if i know of a namespace and i have a schema i would of course enforce it. and that is because of the interoperability not because of lack of it
  300. SamWhited stefandxm: Yes
  301. jonasw for sending it makes sense, and I agree, but for receiving, being strict in most of the cases causes more pain than it does good
  302. SamWhited Except scratch the "sucky" and just say "some clients and services might be doing their own thing and it's common practice to allow them to do so"
  303. SamWhited But what jonasw said; if you know a schema, feel free to enforce it on payloads you send. That's very nice of you.
  304. stefandxm tbh i will enforce it on receiving aswell
  305. SamWhited That's a terrible idea
  306. jonasw stefandxm, from my experience, you won’t like that
  307. Martin has joined
  308. stefandxm no, it makes stuff crash and burn faster
  309. jonasw yes, but it’ll look as if it was your fault
  310. SamWhited Possibly the most basic principle of any network protocol design is to be liberal in what you receive and strict in what you send
  311. Holger https://www.computer.org/csdl/mags/sp/2012/02/msp2012020087.html
  312. SamWhited Also, it's common practice to include custom elements (provided that they're properly namespaced), this has nothing to do with this particular spec.
  313. Holger I.e. I'm not sure that's still the consensus.
  314. SamWhited Holger: That's fair, if I were designing a new protocol I'd probably make it more strict and less extensible than XMPP, but I'm not and it's already common practice in XMPP.
  315. Zash https://tools.ietf.org/html/draft-thomson-postel-was-wrong-01
  316. Guus well, for XML-based systems, it's not uncommon to enforce schema validitry (think of SOAP et al). We've long lost that battle in XMPP though.
  317. stefandxm i dont see anything that would break xmpp because i chose to to use the schemas supplied
  318. Holger Zash: Heh that one was the one I was meaning to reference :-) Mis-searched.
  319. stefandxm only broken xeps will break
  320. stefandxm and the broken xeps should probably be given attention to by xsf
  321. Guus stefandxm: and any implementation that's not yours.
  322. SamWhited Zash: Yah, I do agree with that, but still, not something that makes sense for XMPP unless we want to start over
  323. stefandxm guus, better have error than confusion
  324. SamWhited But yes, my earlier statement should perhapse be softened to be more tightly scoped to existing protocols that have expected that for years
  325. stefandxm if i find elements i cannot parse because it does not exist in the schema it will just generate more sneaky errors
  326. Guus stefandxm: I'd agree with you if this would have been enforced from '99. But it hasn't. There's no saving it now.
  327. stefandxm i'd rather have the explicit error yelled at asap
  328. stefandxm guus, there is. we use xmpp for modern new stuff. xmpp is much bigger than IM
  329. jonasw stefandxm, simple and practical example: RFC 6120 schemas do not define the "code" attribute on stanza errors. however, RFC 3921 does.
  330. jubalh has joined
  331. jonasw stefandxm, some implementations still emit that code attribute
  332. jubalh has left
  333. jonasw if you’re strict about the schema from RFC 6120, you’d not be able to interoperate with implementations still emitting that
  334. stefandxm and thats fine by me
  335. jonasw (which is explicitly allowed by the text of RFC 6120)
  336. jonasw well not allowed, but mentioned
  337. jonasw so you won’t be able to talk to ejabberd IIRC
  338. Holger wat
  339. jonasw (holger may be able to correct me, but LTIC ejabberd emitted that)
  340. jonasw (but it may have been a legacy installation of ejabberd; it also required legacy sessions)
  341. stefandxm ive not seen "code" :o
  342. Holger Recent ejabberd versions are currently trying to validate incoming XML and it's working better as expected, BTW. So I'm not sure the "everything is lost since we didn't enforce things for over a decode" story holds.
  343. jonasw Holger, nice!
  344. SamWhited Either way, moving it into the blocking command XEP would solve this issue for you right stefandxm? (because then it would be a part of the blocking command schema)
  345. Zash Holger: Validate how strictly?
  346. Holger jonasw: It's probably liberal in accepting also 3920, I'll check your example.
  347. SamWhited Holger: Oh? I'd love to know more about that
  348. stefandxm samwhited; i am not commenting on the topic itself. i just dont want broken schemas :)
  349. Guus that's unexpectedly pleasant news.
  350. stefandxm samwhited; as long as the schema is not broken / conforms iam happy :)
  351. jonasw Holger, when I had aioxmpp be strict about inbound stuff (raise errors on unknown attributes and child elements), it broke rather quickly
  352. jonasw stefandxm, schemas as written in XEPs rarely reflect the reality
  353. stefandxm i know, schemas are not perfect :)
  354. stefandxm but if anythign they should be leniant then not give false errors
  355. jonasw stefandxm, sometimes they’re outright in conflict with the text
  356. jonasw and then you’re getting told that they’re not normative
  357. stefandxm i know, and thats funky. i'd call them broken and they should be attended to
  358. jonasw Holger, could you (as ejabberd) maybe write up an XSF blogpost on this?
  359. SamWhited yah, that's a whole different issue, but most of us don't understand schemas and there's no one to attend to them, sadly
  360. jonasw I’d be interested to learn about the scope of the validation you do and the results you see
  361. jonasw stefandxm, patches welcome or so?
  362. jonasw reminds me I wanted to write a tool which uses the schemas in XEPs to validate the code examples.
  363. stefandxm i dont have time, i focus on the schemas for the protocls i am making ;)
  364. stefandxm but i think xsf should encourage to update/fix the schemas rather than saying its best practice to break schemas
  365. jonasw stefandxm, I tend to agree
  366. SamWhited Just to stir the fire a bit more: this is why I think we should remove schemas from existing XEPs and make them optional. In theory they're great, in practice only a few authors actually know what they're doing enough to add them
  367. SamWhited (though if the author does know what they're doing, sure, why not, it's nice when they're right)
  368. Holger jonasw: Here's the definition of 'error', which includes the 'code' attribute: https://github.com/processone/xmpp/blob/1.1.14/specs/xmpp_codec.spec#L655
  369. SamWhited No one's saying it's best practice to break the schemas.
  370. stefandxm i agree with removing/making broken schemas more leniant
  371. Holger So yes this is not enforcing strict 6120 or anything.
  372. Holger Just trying to reject unknown crap.
  373. stefandxm false negatives is stupid. but a false positive will always happen because no xml schema protocol can provide enough business logic rules
  374. jonasw Holger, that’s fine
  375. Zash Holger: Like <message type="I made this up"> and whatever?
  376. jonasw Holger, still, care to write a blogpost with some insights and results and what exactly you’re doing?
  377. Holger Zash: Yes.
  378. Holger Zash: That's the most common case sites with custom stuff seem to stumble over, of course :-)
  379. SamWhited > no xml schema protocol can provide enough business logic rules Is this true? I thought I saw an implementation of a lisp-like language purely in XMLSchema at one point (proving that it was turing complete, and therefore can probably provide as much business logic as you could with anything else you'd be using)
  380. Holger jonasw: I'm not sure ...
  381. SamWhited Not that it matters at all or that you'd want to do that, I'm just curious
  382. Holger jonasw: I'm not a good blog article writer. Takes me ages.
  383. Holger And Evgeniy did all this work.
  384. SamWhited Zash: the message type thing is actually an interesting problem I ran into recently; I can't tell if the RFC is specifically allowing or disallowing custom types
  385. SamWhited There's a weird interconnect between 6120 which doesn't define types and 6121 which defines a few types there
  386. jonasw Holger, if you reject unknown message types, you may be violating RFC 6121: > If an application receives a message with no 'type' attribute or the application does not understand the value of the 'type' attribute provided, it MUST consider the message to be of type "normal" (i.e., "normal" is the default). (<https://tools.ietf.org/html/rfc6121#section-5.2.2>)
  387. ralphm has joined
  388. Zash jonasw: wha
  389. jonasw SamWhited, there’s clear wording on that
  390. stefandxm samwhited; i have many examples of my oppinion "nice" xml that cannot be made robust in xml schemas (or ng relax). for instance when you use inheritance. the only way to make it robust is to put every element in a namespace ;-) other than that there are business logic that only the receiver may now/being able to verify. for instance global uniquness
  391. Zash What about IQ and presence?
  392. stefandxm (in a unique individual namespace that is)
  393. Holger jonasw: Ah yes we're probably not doing that actually. Just <message custom_attr="foo"/> is rejected.
  394. Holger *That's* what people stumble over anyway.
  395. jonasw Zash, IQ is in RFC 6120: > 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST be one of the following; if not, the recipient or an intermediate router MUST return a <bad-request/> stanza error (Section 8.3.3.1). (<https://tools.ietf.org/html/rfc6120#section-8.2.3>)
  396. SamWhited stefandxm: Ah, okay, interesting; I don't know enough xmlschema to even start doing something that complicated, but I guess it's just not possible after a point. Thanks
  397. stefandxm samwhited; ng relax doesnt even support inheritance. but xml schemas does it in what i would call reverse order which is very irritating if you are used to oop
  398. stefandxm samwhited, but for the business logic it cannot be done because the schema only has memory of what data it has in the xml stream not in what happens outside.
  399. Holger jonasw: https://github.com/processone/xmpp/blob/1.1.14/specs/xmpp_codec.spec#L4173 :-)
  400. jonasw Zash, for presence, again RFC 6121: > If the value of the 'type' attribute is not one of the foregoing values, the recipient or an intermediate router SHOULD return a stanza error of <bad-request/>. (<https://tools.ietf.org/html/rfc6121#section-4.7.1>)
  401. jonasw Holger, I fail to be able to understand what this does :)
  402. Holger jonasw: If type is unkown, then type is normal.
  403. jonasw I see
  404. jonasw so you’re actually doing that. neat. aioxmpp throws an error at you.
  405. jonasw *sigh*
  406. Guus has left
  407. jonasw (I find defaulting to "normal" on unknown values a bad style btw.)
  408. stefandxm speaking of shoulds.. does ejabberd route iq messages between entities not sharing presence?
  409. Holger jonasw: ACK.
  410. vanitasvitae has left
  411. jonasw Holger, Zash, wait; maybe my reading of RFC6121 is off, the full paragraph is this: > An IM application SHOULD support all of the foregoing message types. > If an application receives a message with no 'type' attribute or the > application does not understand the value of the 'type' attribute > provided, it MUST consider the message to be of type "normal" (i.e., > "normal" is the default).
  412. jonasw maybe what is meant is that if an application does not implement one of the foregoing, it should be treated like "normal"?
  413. Holger stefandxm: Er I don't think it looks at think at presence subscription when routing IQs. Or does/should it?
  414. Zash jonasw: My head!
  415. Holger (Not sure I'll ever manage to write two correct sentences in a row.)
  416. jonasw Zash, I’m sorry!
  417. stefandxm holger; https://tools.ietf.org/html/rfc6121#section-8.5.3.1
  418. jonasw Holger, you need Last Message Correction :-)
  419. jonasw what.
  420. jonasw stefandxm, didn’t know that existed.
  421. stefandxm we have made some funky way to get around that
  422. stefandxm we have to make our entitled data sessions force the entities to set up presence
  423. stefandxm during a valid session
  424. Holger stefandxm: Ah right. And doesn't it behave that way? :-)
  425. Holger goes reading code.
  426. stefandxm holger, i think not. at least not last time i checked :)
  427. stefandxm jonasw, its not easily spotted but quite sever if you design a protocol and dont know about it
  428. stefandxm "someone" should compile a cheat sheet for xmpp >D
  429. jonasw stefandxm, I think this invalidates quite a few security consideratinos I have thought about recently.
  430. Zash stefandxm: thanks for volonteering ;)
  431. stefandxm iam swamped :p
  432. jonasw who isn’t
  433. stefandxm but i am basically writing such stuff anyhow
  434. jonasw I like it when discussions in xsf@ result in bugreports against myself.
  435. stefandxm for our proffesional campaign. i'll see if i can collect enough of items to make it usefull
  436. stefandxm jonasw, hehe. thats why i try not to read too much here ;)
  437. jonasw I prefer to know about issues instead of having buggy software out there.
  438. Ge0rG has left
  439. stefandxm yeah, but ignorance is bliss if your backlog is too big ;)
  440. efrit has left
  441. jcbrand has left
  442. waqas has left
  443. sonny has left
  444. sonny has joined
  445. Guus has left
  446. Lance has joined
  447. ralphm has joined
  448. Valerian has left
  449. Guus has left
  450. Lance has left
  451. daniel has left
  452. moparisthebest has joined
  453. daniel has joined
  454. moparisthebest has joined
  455. jere has left
  456. jere has joined
  457. waqas has joined
  458. tim@boese-ban.de has joined
  459. goffi has left
  460. tim@boese-ban.de has left
  461. Flow > ‎[16:55:46] ‎Holger‎: stefandxm: But I think the general consensus is that you can throw new stuff into existing XML because you're expected to ignore unknown stuff. You can throw in new stuff if the protocol still works if the recipient ignores it, otherwhise it has to be negotiated prior
  462. daniel has left
  463. Wiktor has joined
  464. daniel has joined
  465. jere has left
  466. jere has joined
  467. Guus has left
  468. Guus has left
  469. Holger has left
  470. Steve Kille has left
  471. Ge0rG But isn't the protocol designed for that, except maybe adding new element values like message type?
  472. tim@boese-ban.de has joined
  473. jonasw Ge0rG, yes and no
  474. jonasw we rarely do that in practice, and when we do, I often feel it is a mistake (see MIX and the Spam Reporting thing)
  475. jonasw and it violates our (non-normative) schemas
  476. MattJ Schemas are per namespace, no?
  477. jonasw yes
  478. jonasw but schemas normally need to include an <xs:any/> if they can contain children from foreign namespaces if I’m not mistaken
  479. Martin has left
  480. Steve Kille has left
  481. Steve Kille has joined
  482. sonny has left
  483. sonny has joined
  484. Flow has joined
  485. andrey.g has left
  486. Guus has left
  487. stefandxm has left
  488. Valerian has joined
  489. Tobias has joined
  490. Steve Kille has left
  491. Steve Kille has left
  492. Steve Kille has left
  493. vanitasvitae has left
  494. la|r|ma has joined
  495. Vaulor has joined
  496. Lance has joined
  497. Yagiza has joined
  498. Zash has left
  499. jjrh has left
  500. Lance has left
  501. jjrh has left
  502. Steve Kille has left
  503. stefandxm has joined
  504. ralphm has joined
  505. Steve Kille has left
  506. Steve Kille has left
  507. tim@boese-ban.de has joined
  508. valo has joined
  509. stefandxm has left
  510. waqas has left
  511. Valerian has left
  512. goffi has joined
  513. fp-tester has left
  514. fp-tester has joined
  515. Guus has left
  516. Flow has joined
  517. Zash has left
  518. Flow has joined
  519. Flow has joined
  520. Tobias has joined
  521. Guus has left
  522. Valerian has joined
  523. emxp has left
  524. emxp has joined
  525. Wiktor has left
  526. Wiktor has joined
  527. sonny has joined
  528. Guus has left
  529. Flow since everyone seems to repeat that schemas are not normative again and again, why not make it offical?
  530. Zash +1, everyone already believes it
  531. andrey.g has joined
  532. SamWhited It is official, isn't it?
  533. Flow SamWhited: then there would be place where it's mentioned
  534. Flow uh, i have a deja vu
  535. SamWhited Oh, is it not? I assumed it was in one of the XEP XEPs somewhere. Guess not.
  536. Flow logs.xmpp.org does work again? what else have I missed while I was on vacation?
  537. jjrh has left
  538. jjrh has left
  539. ralphm has joined
  540. Guus Edwin fixed the logs
  541. stefandxm has joined
  542. Zash Praise be Edwin
  543. sonny has joined
  544. Steve Kille Non-normative schema seems odd to me. I was advised to defer doing the MIX schema, as it was non-normative. Having the schema normative seems to offer significant advantage. Not least, the schema can be validated by a range of available tools, whereas examples and descriptive text cannot.
  545. SamWhited I think that sounds nice in theory, but unless you (or someone who understands schemas) is willing to write one for every new XEP it doesn't seem realistic to me.
  546. SamWhited Especially given that we know a lot of them are actually broken right now. That's not going to get better by making them normative
  547. stefandxm another problem is that unless you make your xml to be compliant with a schema then it may be very difficult to make a good one
  548. stefandxm Ironically i am making a xep (maybe, dunno if xsf will like it) that is self-extending with xml schemas >D
  549. stefandxm but i see no other way to be dynamic with types
  550. jjrh has left
  551. stefandxm schemas makes the most sense if you make the server verify it
  552. Steve Kille New XEPs (and progression beyond experimental is easy. You only allow progress if the schema is good. I suspect that this would be a lot of work for me/MIX, but it feels right to do it.
  553. Steve Kille Current XEPs is harder. The draconian way would be to move to historical anything with a broken schema
  554. valo has joined
  555. stefandxm replace any broken ones with <any> ;-)
  556. Zash Is this like the static vs dynamic typing war?
  557. stefandxm there has never been a static vs dynamic typing war
  558. stefandxm just programmers using static typing and n00bs using dynamic typing =)
  559. SouL stefandxm, brofist
  560. SouL smiles :)
  561. Flow Plus, what has priorityif the normative text and the normative schema contradict each other?
  562. SamWhited Flow: Is that any different from when the normative text and the normative text contradict each other?
  563. Flow I think the normative text eventually has to have priority of a hyptothetical normative schema, which just means we can just say that the schema is not normative
  564. Flow SamWhited: Good question, I think it's different assuming that usually the text is correct and not the schema in my experience
  565. Flow And I rather have a well written normative text instead of a well formed normative schema, because the former is easier to parse for me as human
  566. SamWhited I feel like the text is just as likely to contradict other text, and that's just a mistake that needs to be fixed (same as if the schema contradicts the text). That being said, I don't disagree with you that the text needs to be normative and the schema doesn't, just with the reasoning
  567. jjrh has left
  568. SamWhited Yah, me too; I'm not ever going to read the schema, I will read the text.
  569. ralphm has joined
  570. Steve Kille So, why have the schema??
  571. Flow well schemas come in handy in case the text is not clear, that's the common case where I look at it
  572. SamWhited Steve Kille: exactly
  573. Flow Steve Kille: Because it's an excellent addition to the text
  574. jjrh has left
  575. Valerian has left
  576. Flow and makes it easy to model and implement stanzas and nonzas in the programming language of your choice
  577. SamWhited It's an excellent addition when it's correct. Any schema I write is probably not going to be correct though, so I don't see why I should be required to put one in there
  578. Flow SamWhited: There is only one required for the XEP to enter draft, which is a good tradeof and how I would want it to be
  579. SamWhited "an excellent addition in theory" anyways. I'm not against people who know what they're doing adding a schema section, I just don't think it should be a requirement in general.
  580. ralphm has left
  581. ralphm has joined
  582. tux has joined
  583. magix has joined
  584. tux Hey there!
  585. SouL Sooo... Is now the moment when new applications for XSF members are voted?
  586. magix has left
  587. Alex hey guys, everybody ready for our member meeting?
  588. Alex lets get started
  589. Alex bangs the gavel
  590. stefandxm schemas are great and they have to be correct
  591. stefandxm btu cannot exist if broken
  592. Alex here is our agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12
  593. Alex 1) Call for Quorum
  594. Alex as you can see 38 members voted via memberbot. So we have a quorum
  595. Alex 2) Items Subject to a Vote
  596. Alex we were voting on new and returning applicants. You can see all applicants here: https://wiki.xmpp.org/web/Membership_Applications_Q3_2017
  597. Alex 3) Opportunity for XSF Members to Vote in the Meeting
  598. Alex anyone here who has not voted yet via memberbot?
  599. nyco has left
  600. uc has joined
  601. stefandxm and by broken i mean they give false negatives
  602. stefandxm false positives is imo not a problem
  603. SamWhited stefandxm: the meeting has started, let's hold the discussion we were having until Alex closes it.
  604. Alex I think everbody voted already via memberbot. So let me work on the results
  605. jonasw thanks for your work, Alex :-)
  606. jonasw I’m mostly AFK this time though
  607. nyco has joined
  608. Alex 4) Announcement of Voting Results
  609. Alex when you reload teh page you can see teh results at: https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12#Announcement_of_Voting_Results
  610. Alex all new and retruning members were accepted, congrats to everyone
  611. Alex 5) Any Other Business?
  612. Alex looks like there is none
  613. Alex 6) Formal Adjournment
  614. Alex I motion that we adjourn
  615. SamWhited Seconded
  616. tux +1
  617. Alex bangs the gavel
  618. SamWhited Thanks Alex; much appreciated.
  619. Alex thanks everyone
  620. tux thanks for making me a member. :)
  621. Alex board and council election are coming up
  622. Alex will create the application page ASAP
  623. SouL Suuuper happy to part of the XSF! Thank you all, really!
  624. Lance has joined
  625. Lance has left
  626. SouL Congratulations tux :D
  627. tux SouL: to you, too!
  628. vanitasvitae has left
  629. Zash Thanks Alex
  630. SouL Thanks tux, with the excitement I forgot to write "to be part" in my previous message :D
  631. ralphm has joined
  632. SouL Thank you Alex of course :)
  633. ralphm has joined
  634. lovetox has left
  635. Tobias has joined
  636. ralphm has left
  637. ralphm has joined
  638. Guus Welcome, newbies. 😉
  639. jonasw congrats, SouL et al
  640. Ge0rG today, the number of XSF members I know in person increased, without me meeting any new people. Congratulations :)
  641. tux *g*
  642. edhelas SouL, welcome to the party, we have XEPs, beers and pizzas
  643. ralphm has joined
  644. jabberatdemo has joined
  645. Ge0rG And a free dinner!
  646. tux has left
  647. tux has joined
  648. jcbrand has joined
  649. tux has left
  650. Tobias has joined
  651. Ge0rG has joined
  652. tux has joined
  653. tux has left
  654. tim@boese-ban.de has joined
  655. goffi has left
  656. tux has joined
  657. jabberatdemo has left
  658. Vaulor has left
  659. jere has left
  660. jere has joined
  661. jcbrand has left
  662. Flow has left
  663. jubalh has joined
  664. SamWhited has left
  665. efrit has joined
  666. blabla has joined
  667. fp-tester has left
  668. fp-tester has joined
  669. jcbrand has joined
  670. mathieui Damn, missed the members meeting. Thanks for the work, Alex
  671. Guus has left
  672. emxp Hello, have you heard about this project? https://wiki.xmpp.org/web/Meeting-Minutes-2017-09-12 - As it's harder to get an overview and facts about dezentralised networks (than centralised) this might be helpful in the future to argue (for XMPP) based on statistics. Furthermore, we might get more detailed information about developments which havent been in our view so far.
  673. SamWhited emxp: wrong link, I think
  674. emxp ups
  675. emxp yes
  676. emxp --> https://chaoss.community/
  677. tim@boese-ban.de has joined
  678. Lance has joined
  679. SamWhited has left
  680. Lance has left
  681. tux has left
  682. Ge0rG has joined
  683. jubalh has joined
  684. moparisthebest emxp: confusing l thought it was open source software for healthcare
  685. daniel has left
  686. daniel has joined
  687. jcbrand has left
  688. Alex has left
  689. Tobias has joined
  690. la|r|ma has left
  691. jere has joined
  692. jjrh has left
  693. jjrh has left
  694. jjrh has left
  695. sonny has left
  696. sonny has joined
  697. sonny has left
  698. sonny has joined
  699. jere has joined
  700. jjrh has left
  701. jere has left
  702. jere has joined
  703. la|r|ma has joined
  704. lskdjf has joined
  705. Ge0rG has joined
  706. vanitasvitae has left
  707. Wiktor has joined
  708. Wiktor has joined
  709. nyco has left
  710. nyco has joined
  711. Zash has left