jdev - 2021-11-03

  1. marc0s has left

  2. marc0s has joined

  3. antranigv has left

  4. antranigv has joined

  5. debacle has left

  6. Kev has joined

  7. paul has left

  8. wurstsalat has left

  9. Kev has left

  10. Kev has joined

  11. antranigv has left

  12. antranigv has joined

  13. Kev has left

  14. Kev has joined

  15. Kev has left

  16. Kev has joined

  17. Kev has left

  18. Kev has joined

  19. FireFly has left

  20. antranigv has left

  21. Kev has left

  22. antranigv has joined

  23. antranigv has left

  24. mac has left

  25. mac has joined

  26. Kev has joined

  27. atomicwatch has joined

  28. sonny has left

  29. sonny has joined

  30. sonny has left

  31. sonny has joined

  32. sonny has left

  33. sonny has joined

  34. antranigv has joined

  35. Kev has left

  36. Kev has joined

  37. Kev has left

  38. Kev has joined

  39. Yagizа has joined

  40. rafasaurus has left

  41. rafasaurus has joined

  42. Kev has left

  43. Kev has joined

  44. Kev has left

  45. Kev has joined

  46. Kev has left

  47. Kev has joined

  48. me9 has joined

  49. paul has joined

  50. Kev has left

  51. Kev has joined

  52. Kev has left

  53. Kev has joined

  54. kikuchiyo has left

  55. kikuchiyo has joined

  56. Kev has left

  57. kikuchiyo has left

  58. kikuchiyo has joined

  59. mac has left

  60. mac has joined

  61. me9 has left

  62. atomicwatch has left

  63. atomicwatch has joined

  64. dezant has joined

  65. msavoritias has joined

  66. sonny has left

  67. sonny has joined

  68. marmistrz has joined

  69. atomicwatch has left

  70. sonny has left

  71. sonny has joined

  72. sonny has left

  73. sonny has joined

  74. kikuchiyo has left

  75. huhn has left

  76. sonny has left

  77. sonny has joined

  78. sonny has left

  79. sonny has joined

  80. pulkomandy has left

  81. pulkomandy has joined

  82. malthe has joined

  83. atomicwatch has joined

  84. emus has joined

  85. wurstsalat has joined

  86. kikuchiyo has joined

  87. atomicwatch has left

  88. pulkomandy has left

  89. marmistrz has left

  90. goffi has joined

  91. atomicwatch has joined

  92. emus has left

  93. emus has joined

  94. Kev has joined

  95. sonny has left

  96. sonny has joined

  97. sonny has left

  98. sonny has joined

  99. malthe has left

  100. mac has left

  101. mac has joined

  102. sonny has left

  103. sonny has joined

  104. sonny has left

  105. sonny has joined

  106. FireFly has joined

  107. Kev has left

  108. marmistrz has joined

  109. Kev has joined

  110. dezant has left

  111. Kev has left

  112. Kev has joined

  113. kikuchiyo has left

  114. Kev has left

  115. Kev has joined

  116. jgart has left

  117. marmistrz has left

  118. Kev has left

  119. marmistrz has joined

  120. Kev has joined

  121. kikuchiyo has joined

  122. Syndace has left

  123. Syndace has joined

  124. pasdesushi has joined

  125. marmistrz has left

  126. Trbl has left

  127. Trbl has joined

  128. marmistrz has joined

  129. paul has left

  130. debacle has joined

  131. Trbl has left

  132. Trbl has joined

  133. rafasaurus has left

  134. rafasaurus has joined

  135. marmistrz has left

  136. atomicwatch has left

  137. rafasaurus has left

  138. inky has joined

  139. inky has left

  140. atomicwatch has joined

  141. pasdesushi has left

  142. debacle has left

  143. antranigv has left

  144. rafasaurus has joined

  145. marc0s has left

  146. marc0s has joined

  147. debacle has joined

  148. marc0s has left

  149. marc0s has joined

  150. marc0s has left

  151. marc0s has joined

  152. kikuchiyo has left

  153. Alex has left

  154. Alex has joined

  155. goffi has left

  156. lovetox has left

  157. atomicwatch has left

  158. lovetox has joined

  159. atomicwatch has joined

  160. pasdesushi has joined

  161. sonny has left

  162. sonny has joined

  163. sonny has left

  164. kikuchiyo has joined

  165. sonny has joined

  166. paul has joined

  167. atomicwatch has left

  168. x51 has joined

  169. atomicwatch has joined

  170. marmistrz has joined

  171. mac has left

  172. lovetox

    on the topic of xml parsers

  173. lovetox

    python has a xmlpullparser

  174. lovetox

    but i think it will keep the whole xml document in memory

  175. lovetox

    i think this is a problem .. i dont know how much data is exchanged between client and server, but i guess if a client runs for some days, that could be problematic

  176. flow

    lovetox, smack uses an xml pull parser but splits the top level stream elements, so that at most one is kept in memory

  177. flow

    also pull parser tend to not keep the whole document in memory

  178. flow

    since you typically can't rewind, the unreachable parts of the document can be dropped

  179. jonas’

    lovetox, xml.sax! :)

  180. spectrum has left

  181. flow

    IIRC pull/push parsers can operate on streams, unlike DOM based parsers

  182. flow

    of course, this may vary from parser implementation to parser implemention

  183. flow

    having said that some xml parsers can operate on streams, I believe that in XMPP it's best to not parse on the stream but to split the top-level stream elements, as it, amongst other things, allows you to enforce a top-level stream element size limit

  184. jonas’

    you can also enforce that with a parser which can tell you where in the stream it currently is

  185. jonas’

    splitting sounds like implementing half on an XML parser which I definitely cannot recommend you doing

  186. jonas’

    (I know that moparisthebest loves that kind of pain though :))

  187. flow

    My personal experience is that the developing the splitter implmentation was not painful

  188. flow

    but yes, it's basically an xml parser, or, i'd rather say, an xml state machine

  189. flow

    and yes, if the parser is able to tell you the current position in the stream, then you probably do not need to do that

  190. flow

    unfortunately, that was not true for in my case

  191. Wojtek has joined

  192. Kev has left

  193. Kev has joined

  194. phikoen has left

  195. phikoen has joined

  196. spectrum has joined

  197. Kev

    We more or less use a streaming dom parser, by using a stream parser and then constructing a pseudo-dom on individual stanzas. I imagine we're not alone in that.

  198. PapaTutuWawa has joined

  199. Sam

    That's more or less what I do as well if I understood you correctly. It's all streaming until we need to do something with a stanza or an element, then the user has an option of parsing the whole element into a DOM or similar and operating on that instead of the streamed tokens.

  200. lovetox

    jonas’, of course i can use sax, but then i have to write code to build the xml elements myself

  201. jonas’

    or port to aioxmpp :-X

  202. jonas’

    lovetox, actually, no, lxml.etree has a SAX -> etree thing

  203. jonas’

    I use that in aioxmpp to capture unschematized elements

  204. jonas’

    or used it anyway, I don't think I still do.

  205. lovetox

    thats exactly what i need

  206. jonas’

    lovetox, https://lxml.de/sax.html#building-a-tree-from-sax-events

  207. jonas’

    then you just need a shim thing which handles the stream header and then delegates to that

  208. marmistrz has left

  209. marmistrz has joined

  210. goffi has joined

  211. antranigv has joined

  212. kikuchiyo has left

  213. pasdesushi has left

  214. pasdesushi has joined

  215. marmistrz has left

  216. goffi has left

  217. lovetox


  218. jonas’

    hurts to look at :)

  219. lovetox

    yeah lxml build the same pullparser and added a method to delete elements when not needed anymore

  220. jonas’

    I'd rather go the sax way where I can be sure of what's what

  221. debacle has left

  222. atomicwatch has left

  223. debacle has joined

  224. moparisthebest

    yea I tend to agree that sax parsers are painful, and it's better to split the stream into stanzas without parsing, and only parse individual stanzas as a whole/with a DOM parser if needed

  225. antranigv has left

  226. antranigv has joined

  227. Zash has left

  228. zash has joined

  229. lovetox

    i want a parser, that simply dispatches stanzas to my handlers. with that pullparser, i can just look for the "end" event, and at depth 1, i displatch the element that parser gives me.

  230. lovetox

    thats a xml parser in probably 50 lines of code

  231. flow

    lovetox, that sounds similar to what smack does

  232. jonas’

    lovetox, and hope that the delete actually works as you wish :)

  233. flow

    although what you really want to is something like jaxb, which matches the XML elements to types of your programming languages, with additional verification

  234. lovetox

    jonas’, i will test this now

  235. flow

    so much possibility to optimize the process, so little free time :)

  236. lovetox

    and also how vulnerable this parser is against attacks

  237. flow

    so much possibilities to optimize the process, so little free time :)

  238. lovetox

    because there is zero settings here that i could configure to make it more secure

  239. Zash has joined

  240. moparisthebest

    lovetox, this is a stand-alone file that splits a stream on stanza boundaries without an xml parser, so you'd get notified of individual stanzas https://github.com/moparisthebest/xmpp-proxy/blob/master/src/stanzafilter.rs#L255

  241. antranigv has left

  242. lovetox

    yeah im not sure i should do this with python

  243. lovetox

    its probably slow

  244. lovetox

    but yeah i think this approach is cleaner

  245. flow

    given that its a client application, I doubt that this particular overhead will be an issue

  246. pasdesushi has left

  247. pasdesushi has joined

  248. moparisthebest

    I wouldn't think it'd be slow in python, there aren't any string copies or anything, it's just running a switch on 1 character at a time, surely faster than an XML parser

  249. kikuchiyo has joined

  250. stpeter has joined

  251. lovetox

    but its additional, its not like i spare myself the xml parsing

  252. kikuchiyo has left

  253. moparisthebest

    you spare yourself the streaming sax parsing

  254. lovetox

    Oo, maybe i missing something, all your filter is doing is cutting the stream into pieces and feeding it to the parser

  255. lovetox

    oh you mean i dont need to care then about sax events

  256. lovetox

    just give me the finished element after you parsed everything

  257. atomicwatch has joined

  258. lovetox

    that lxml lib is amazing, you can even register custom element classes, that will be used when it encounters a certain tag / namespace or event attribute combination

  259. lovetox

    this thing is made for xmpp

  260. edhelas

    lovetox funny, it's roughtly what I did for my XML library in Movim :D

  261. edhelas


  262. goffi has joined

  263. marmistrz has joined

  264. marmistrz has left

  265. stuart.j.mackintosh has left

  266. aram has joined

  267. malthe has joined

  268. marmistrz has joined

  269. mac has joined

  270. kikuchiyo has joined

  271. emus has left

  272. kikuchiyo has left

  273. stuart.j.mackintosh has joined

  274. marmistrz has left

  275. emus has joined

  276. kikuchiyo has joined

  277. goffi has left

  278. lovetox

    hm parsing 1 million xml elements and creating custom python classes for it, in 2 seconds

  279. lovetox

    xml parsing is indeed not the bottleneck in a gui app

  280. antranigv has joined

  281. sonny has left

  282. sonny has joined

  283. Zash has left

  284. sonny has left

  285. sonny has joined

  286. sonny has left

  287. sonny has joined

  288. Link Mauve

    Want me to test on my server? o:)

  289. Link Mauve

    In poezio it is very much the bottleneck.

  290. Link Mauve


  291. sonny has left

  292. sonny has joined

  293. lovetox

    why that?

  294. Link Mauve

    Due to the way slixmpp converts DOM-like structs into XMPP-specific structs.

  295. sonny has left

  296. sonny has joined

  297. sonny has left

  298. sonny has joined

  299. kikuchiyo has left

  300. antranigv has left

  301. kikuchiyo has joined

  302. rafasaurus has left

  303. rafasaurus has joined

  304. zash has left

  305. antranigv has joined

  306. Zash has joined

  307. nephele has joined

  308. jgart has joined

  309. Kev has left

  310. Kev has joined

  311. antranigv has left

  312. antranigv has joined

  313. mac has left

  314. antranigv has left

  315. antranigv has joined

  316. stpeter has left

  317. marmistrz has joined

  318. debacle has left

  319. Wojtek has left

  320. Wojtek has joined

  321. antranigv has left

  322. sander has left

  323. me9 has joined

  324. malthe has left

  325. sander has joined

  326. flow

    Link Mauve, please tell use more :)

  327. flow

    maybe with an example code

  328. antranigv has joined

  329. antranigv has left

  330. antranigv has joined

  331. Link Mauve

    https://lab.louiz.org/poezio/slixmpp/-/blob/master/slixmpp/xmlstream/stanzabase.py#L672 mostly.

  332. Link Mauve

    This happens on each element['sub-element'] call, and is quite slow.

  333. Link Mauve

    I once started to work on a JIT for that, but never managed to make poezio start.

  334. 9lakes has left

  335. 9lakes has joined

  336. antranigv has left

  337. goffi has joined

  338. marmistrz has left

  339. dezant has joined

  340. lovetox

    what is the opinion on validating stanzas against a schema?

  341. lovetox

    is this even possible?

  342. lovetox

    can xml schemas be "open" in they allow elements not defined in the schema

  343. lovetox

    and only validating MUST haves?

  344. Link Mauve

    In my experience, XML Schema was too poor to be used for both validation and extraction of the data to be more machine-usable.

  345. Link Mauve

    lovetox, yes, you can have <xs:any namespace='##other'/> in a schema.

  346. Link Mauve

    I’ve been trying to fix our schemas every time I encounter something invalid or not restricted enough, but they clearly aren’t used for validation (or their users never contributed back their fixes).

  347. Link Mauve

    In xmpp-parsers, I have drafted a DSL to represent the most common constructs we have in XMPP, but I translate manually from the XML Schema as well as from the XEP’s examples and text.

  348. Link Mauve

    And I still can’t represent everything.

  349. me9 has left

  350. Link Mauve

    It made me discover a whole bunch of invalid things people do in the wild.

  351. Zash

    DSL eh?

  352. Link Mauve

    And led to fixes in clients and servers.

  353. Zash

    I wonder if it maps to the OpenAPI JSON Schema XML stuff

  354. marmistrz has joined

  355. pulkomandy has joined

  356. marmistrz has left

  357. nephele has left

  358. pulkomandy has left

  359. pulkomandy has joined

  360. jgart has left

  361. lovetox

    Link Mauve, what i would like to do is just basic stuff like, checking that a presence type attribute is one of the allowed strings etc

  362. lovetox

    right now i have to do this all in python

  363. lovetox

    right now i have to do this all in python, manually

  364. lovetox

    that would allow me later to have much cleaner code

  365. Zash

    and if not, what would you do?

  366. lovetox

    i would only validate MUST

  367. lovetox

    so invalid type on a presence, ignore stanza

  368. lovetox

    or am i again to strict, and have to later add not failing on that because someone sends wrong values all the time :D

  369. cyril has left

  370. cyril has joined

  371. Zash

    And if you already have that in Python, do you really gain much by having it in XML instead?

  372. lovetox

    yes much cleaner code

  373. Kev has left

  374. Kev has joined

  375. lovetox

    now everywhere i have to be ready to catch exceptions, every attribute i query i have to be prepared for it to be None etc

  376. lovetox

    parsing 4 attributes into enums, is then 30 lines of code

  377. lovetox

    but true much is probably not possible to validate

  378. lovetox

    many things have implicit defaults, so i need to check afterwards anyway if its there or not

  379. Link Mauve

    lovetox, have a look at slixmpp or aioxmpp, they both already do so and in Python.

  380. Link Mauve

    They validate, and also make a more ergonomic API.

  381. larma

    I don't really see cleaner code. When you do pre-validation, you only safe the one "else" case for all invalid values which needs to throw an exception. In proper languages that's about one line of code, in python maybe three.

  382. stpeter has joined

  383. jonas’

    larma, catching obviously invalid stanzas early (and returning an error to the sender early) makes for cleaner code than doing it from random places all over the code

  384. larma

    jonas’, I was thinking we parse as early as possible to not carry around heavy lifting strings when an enum value would've been enough...

  385. jonas’

    yes, enumification is also a nice thing of doing things early

  386. jonas’

    yes, enumification is also a nice opportunity you get when doing things early

  387. Zash

    Cleaner code... /me looks at https://hg.prosody.im/prosody-modules/file/58a20d5ac6e9/mod_rest/res/schema-xmpp.json

  388. Zash

    I made this monstrosity. Fear me!

  389. malthe has joined

  390. sonny has left

  391. sonny has joined

  392. dezant has left

  393. dezant has joined

  394. dezant has left

  395. dezant has joined

  396. sonny has left

  397. sonny has joined

  398. malthe has left

  399. antranigv has joined

  400. nephele has joined

  401. antranigv has left

  402. stpeter has left

  403. flow

    lovetox, you can validate schema and should, if it's not obviously broken, with the one exception that XML schemas IIRC do not allow unspecified elements and attributes. but in XMPP we allow those everywhere (I believe some may disagree with me about that, but IMHO it's the only sane thing to do)

  404. Kev has left

  405. Kev has joined

  406. lovetox

    flow so how do i validate then? if someone adds a element, my validation fails ..

  407. lovetox

    but its not invalid per xmpp definition

  408. flow

    so basically you can validate XML for which an schema exists, but not XML for which no schema exists. those should be simply ignored, as you obviously know nothing about them and did not negogiate it either

  409. lovetox

    but thats very extension unfriendly

  410. flow

    well if a schema specifies the 'priority' attribute to be unsignedByte, you can validate that

  411. lovetox

    i mean often XEPs start with someone just putting something additionally in there

  412. Kev has left

  413. Kev has joined

  414. lovetox

    flow i can only validate everything or nothing

  415. lovetox

    not only one attribute

  416. flow

    that was just an example ;)

  417. flow

    > lovetox> flow i can only validate everything or nothing

  418. flow

    I don't that that's true

  419. flow

    In fact I know that this is not true :)

  420. flow

    but maybe we are talking past each other

  421. malthe has joined

  422. Zash

    Does XML schema validators not ignore unknown things?

  423. flow goes looking for a simple schema example from the XEP

  424. flow

    Zash, I don't think so no

  425. flow

    that's the one thing where we in XMPP vary from how XML schemas are validated

  426. flow

    IIRC you have to add some magic schema thingy in the elements schema to allow for arbitrary further child elements

  427. Kev has left

  428. flow

    that are not part of the schema

  429. Kev has joined

  430. flow

    and IIRC we mostly don't do that in our XMPP schemas

  431. flow

    lovetox, look for example at https://xmpp.org/extensions/xep-0203.html#schema

  432. flow

    surely you can validate stamp

  433. flow

    you can validate that it's value is in the correct format and that the required attribute actually exists

  434. flow

    <delay xmlns='urn:xmpp:delay' from='juliet@capulet.com/balcony' stamp='2002-09-10T23:41:07Z'/>

  435. flow

    but let's assume I add a child element into <delay/>

  436. flow

    and you don't have a schema about it, it's purely optional and does not need to be negotiated

  437. flow

    then you cann still verify 'stamp', but not the child element

  438. flow

    then you can still verify 'stamp', but not the child element

  439. flow

    so, it's not a all or nothing validation situation

  440. flow

    so, it's not an all or nothing validation situation

  441. flow

    lovetox, does this help?

  442. Link Mauve

    flow, it would help in that case to add an <xs:any namespace='##other'/> in the delay element.

  443. flow

    sure, but let's just pretend that this is everywhere in our schemas

  444. Zash

    sprincle those everywhere 😕

  445. Link Mauve

    Please no. ^^'

  446. Link Mauve

    It makes validation (of the whole stanza) much harder.

  447. flow

    what makes validation much harder?

  448. Link Mauve

    In xmpp-parsers I add Option types for each known sub-element defined elsewhere, slixmpp doesn’t do that and instead keeps the extensibility everywhere, at the expense of performances.

  449. Link Mauve

    flow, let’s say I want to assert that delay won’t be extended, or it is an error.

  450. Link Mauve

    (For instance because I don’t support it to be extended.)

  451. Link Mauve

    Leaving an extension point in it will take more memory and void the type safety of it.

  452. stpeter has joined

  453. Link Mauve

    While with the current schema, we can take it as OOP languages use the final keyword.

  454. flow

    I think my general point is that in XMPP, unknown things should typically be simply ignored, as otherwise, the eXtensability in XMPP becomes unnecessary hard

  455. flow

    servers can still filter unknown elements/attributes if they determined that those have not be negoiated between sender and recipient (but I am not sure if this is feasible)

  456. flow

    unnecessary hard and even impossible in some situations

  457. Link Mauve

    I’m ok with that in the generic public network case, but for specific implementations it does make sense to reject extensions you don’t know about.

  458. Link Mauve

    Even if just for validation of other implementations.

  459. flow

    Link Mauve> flow, let’s say I want to assert that delay won’t be extended, or it is an error. I may be misunderstanding the meaning of 'error' here, but I believe that mindest is harmful

  460. flow

    it shouldn't be an error, it should simply be ignored

  461. flow

    and it's fine if your native types don't allow the user to access those ignored elements/attributes

  462. flow

    Link Mauve, define 'reject' here

  463. rafasaurus has left

  464. Link Mauve

    Either ignore the whole delay element and only account for the other payloads, or ignore the whole stanza and reply with an error, stuff like that.

  465. flow

    why would you igniore the whole delay element if it's perfectly fine otherwise?

  466. flow

    why would you ignore the whole delay element if it's perfectly fine otherwise?

  467. Kev

    I would recommend more or less completely ignoring the schemas, personally.

  468. Zash

    when we say "validate", do we mean `validate(schema, stanza) : boolean` ?

  469. flow

    if someone send you additional data within the delay element, without obviously negoiating it, then the sender has to assume that you may ignore it (because he doesn't know if you understand it)

  470. flow

    Kev, in my personal experience, schemas in XEPs haven proven to be very helpful when implementing said XEP to clarify things that aren't clear from the text

  471. malthe has left

  472. flow

    Zash, I think so, yes, the stanza is either valid or not

  473. Zash

    What would a client do with this boolean?

  474. flow

    the question is: what consitutes a valid stanza in the presence of unknown elements/attributes?

  475. Kev

    Fair enough. Having gone through some experience of people trying to use schemas for validating traffic, I feel confident in saying using them normatively can also lead to pain.

  476. Zash

    Sorry, something put an invalid delay tag in your message, so we threw the whole message into the trash

  477. flow

    Zash, configurable, could be ignoring the stanza completely

  478. flow

    Zash, define "invalid delay element" here?

  479. Zash

    Isn't what you actually want something that takes a schema and extracts the bits you care about, and ignores any undefined extras?

  480. Zash

    A data mapper, rather than a schema

  481. Link Mauve

    Zash, what I do currently is `validate(schema, RFC-parts-of-the-stanza; foreach payload in stanza: validate(schema, payload)`.

  482. flow

    is it like stamp='invalid'? or with an unknown child extension element?

  483. Link Mauve

    Although that’s not completely correct as it is a transformative operation, not just a validation.

  484. Zash

    and I don't see how XML schema is particularly helpful for making such a thing

  485. Link Mauve

    In the current example, I end up with a struct Delay { from: Jid, stamp: DateTime } for instance.

  486. Kev

    (And we *do* have a product that does validation of XMPP traffic across security boundaries, so I'm not saying "Don't do this", merely "Here there be dragons")

  487. Link Mauve

    And I also agree with Kev, ignore schemas (or extract information useful to you) and write your own DSL.

  488. flow

    Zash> Sorry, something put an invalid delay tag in your message, so we threw the whole message into the trash I think it is safer to throw the whole message in the trash, as ignoring parts of the elements of an stanza could modify the stanzas semantics

  489. flow

    even though I am not aware of a concrete example

  490. flow

    but I rather be defensive per default

  491. sonny has left

  492. sonny has joined

  493. Link Mauve

    I’d really like to have a server plugin to validate every stream, and report issues it finds to the developers of the relevant violating implementations.

  494. Zash

    flow: So a new XEP comes along and now you can't read any messages anymore because they have a new tag?

  495. flow

    Zash, that's not what I had in mind

  496. flow

    It's not even what I tried to express

  497. aram has left

  498. rafasaurus has joined

  499. Zash

    I may be too tired today for properly reading anything, sorry if I misunderstand

  500. flow

    trying to come up with a slightly related example

  501. Sam

    I read it that way too, fwiw *shrug*

  502. flow

    I do this on the fly so it is maybe not good

  503. flow

    if someone sends you an *invalid* stanza, e.g. an attribute which value 'foo' but it's specified to be an integer

  504. flow

    I think then you can only ignore it

  505. flow

    because the sender may wants to tell you something

  506. Kev

    Although I think it's been lost to the mists of time, we did have a DSL processor for Swiften to create the various parsers/serialisers/elements, but it wasn't XSD-based.

  507. flow

    but you have no idea what, hence you can only guess what it is, and that leads to issues, because you may have guessed wrong

  508. Zash

    not treat it as if that child tag or extension was simply gone?

  509. flow

    presense status with an invalid priority are probably a good example

  510. Link Mauve

    flow, then you have a choice: either you work around it and still try to interpret it somehow, carry this tribal knowledge forever, and laugh at other implementations which didn’t make the same choice or carry it there too; or you report it to them so that they can stop sending the invalid value.

  511. flow

    Zash, that's the tricky question

  512. Link Mauve

    I’m firmly in the latter camp.

  513. flow

    as I said, I could imagine that the semantic of a stanza is made up of multiple of its child elements

  514. Zash

    priority is a core thing, so uh

  515. Kev

    There's definitely, to my mind, a difference between unexpected, and expected-but-invalid content.

  516. flow

    and then, if you ignore the existence of one of the child elements, the semantic may be different

  517. Link Mauve

    Zash, yet I’ve received invalid ones, IIRC it was Gajim which didn’t validate what the user could input there.

  518. stpeter has left

  519. Link Mauve

    It allowed numbers fewer than -128 or bigger than 127.

  520. flow

    assume a client has set the highest priority 99999

  521. flow

    he may then assumes that messages are routing according to this pirority

  522. flow

    but servers may cap it?

  523. Link Mauve

    Someone sent me a priority 500, my program rightfully rejected the stanza, I reported it and it got fixed.

  524. flow

    or servers may treat it as 0?

  525. Link Mauve

    So no one has to handle that case.

  526. Link Mauve

    (flow, highest priority is 127.)

  527. flow

    Link Mauve, I know :)

  528. flow

    but the client wo set it to 99999 didn't

  529. Link Mauve

    Right, so exactly my example. ^^

  530. flow

    in the end, I believe it's the best for the open source community ecosystem of XMPP if implementations validate and reject invalid stanzas as a whole, and emit a visible error message in such a case, ideally pointing to the sending entity, with an request to report an issue to the vendor

  531. Link Mauve


  532. jubalh has left

  533. pulkomandy has left

  534. pulkomandy has joined

  535. flow

    Link Mauve, :)

  536. flow

    Link Mauve, btw, is there an equivalent of <xs:any namespace='##other'/> for attributes?

  537. Link Mauve

    Yes, <xs:anyAttribute namespace="##other"/>.

  538. Link Mauve

    We already use both in our XEPs.

  539. Link Mauve

    But AFAIK we still disallow namespaced attributes.

  540. Link Mauve

    There is still no XEP for an entity to advertise it properly supports XML namespaces.

  541. flow

    not sure if we officially disallow them, it just seems that some seem to be afraid of them

  542. Link Mauve

    Or that yeah.

  543. stpeter has joined

  544. qrpnxz has left

  545. qrpnxz has joined

  546. Kev

    We definitely have guidance not to use them, I'm just not sure where.

  547. qrpnxz has left

  548. qrpnxz has joined

  549. nephele has left

  550. jubalh has joined

  551. nephele has joined

  552. stpeter has left

  553. Wojtek has left

  554. jubalh has left

  555. Trbl has left

  556. Trbl has joined

  557. jgart has joined

  558. x51 has left

  559. goffi has left

  560. goffi has joined

  561. stpeter has joined

  562. me9 has joined

  563. jubalh has joined

  564. PapaTutuWawa has left

  565. rom1dep has left

  566. Yagizа has left

  567. msavoritias has left

  568. malthe has joined

  569. rom1dep has joined

  570. msavoritias has joined

  571. malthe has left

  572. msavoritias has left

  573. me9 has left

  574. msavoritias has joined

  575. sonny has left

  576. sonny has joined

  577. malthe has joined

  578. dezant has left

  579. homebeach has left

  580. Matrix Traveler (bot) has left

  581. Server Stats Discoverer (traveler bot) has left

  582. Server Stats Discoverer (traveler bot) has joined

  583. Matrix Traveler (bot) has joined

  584. homebeach has joined

  585. dezant has joined

  586. stpeter has left

  587. debacle has joined

  588. malthe has left

  589. inky has joined

  590. malthe has joined

  591. pulkomandy has left

  592. pulkomandy has joined

  593. atomicwatch has left

  594. test1 has joined

  595. Kev has left

  596. Kev has joined

  597. msavoritias has left

  598. marmistrz has joined

  599. Kev has left

  600. nephele has left

  601. marmistrz has left

  602. Trbl has left

  603. raghavgururajan has joined

  604. dezant has left

  605. dezant has joined

  606. goffi has left

  607. emus has left

  608. emus has joined

  609. spectrum has left

  610. Kev has joined

  611. marc0s has left

  612. marc0s has joined

  613. malthe has left

  614. qrpnxz has left

  615. qrpnxz has joined

  616. qrpnxz has left

  617. qrpnxz has joined

  618. inky has left

  619. pasdesushi has left

  620. xecks has left

  621. xecks has joined

  622. sonny has left

  623. sonny has joined

  624. Kev has left

  625. emus has left

  626. test1 has left

  627. raghavgururajan has left