On 04.12.2017 10:33, Evgeny Khramtsov wrote: > Mon, 4 Dec 2017 09:29:41 +0100 > Florian Schmaus <[email protected]> wrote: > >> That is what we always did when extending XMPP in a backwards >> compatible way. I'm not aware of a case where we did something >> different. And given that we want to avoid namespace bumps whenever >> possible, I'm happy with that. Even if it means that live schema >> validation is not feasible. > > Why would we need other namespaces then?
For changes that are are not backwards compatible. >> Serous question: I wonder where do you see the benefit in schema >> validation? You (always) need a parser which ensures that protocol >> requirements like "this attribute must exist", or "this attribute must >> be a uint32_t" are fulfilled. > > I have this validator in ejabberd, yes. And if it's enabled, the stanza > with <retry/> element will be rejected. And I consider this as a correct > behaviour. > >> And you want to enforce a maximum top-level stream element size early >> in the processing chain. > > I didn't understand the stuff about top-level stream element size, > how this relates to validation? Input sanitation. >> But if you have that, what is the gain in validating against a schema? > > Have what? Again, in my case server validation is needed to avoid > sending garbage to clients (i.e. x='abc' when it should be an integer). While I am a fan of validation, for the reasons mentioned, I don't think that the approach you are going with the server side validator, as far as I understand it, is possible, needed nor a good idea. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
