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 https://lxml.de/parsing.html#modifying-the-tree
  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 https://github.com/movim/movim/tree/master/lib/moxl#payload
  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 Sadly.
  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 +1
  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