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