On 04.12.2017 11:37, Marcel Waldvogel wrote: > I think this conversation boils down to whether XML validation or the > Internet robustness principle > <https://en.wikipedia.org/wiki/Robustness_principle> ("Be conservative > in what you send, be liberal in what you accept"?) have higher > precedence. Has this been discussed (and maybe decided upon) before?
Postel's Robustness Principle comes up once in a while. As far as I can tell it is often misunderstood [1] and the way it is (mis)understood is considered harmful [2]. I also think that any interpretation of it does not apply here. I believe that it is better to fail hard and fast [3], instead of being "liberal in what to accept". Hence validation is usually always a good idea. But here we have to decide if every tiny change requires a new schema and namespace bump so that one can do server side schema verification. For me, the case is clear: The benefits of the server side verification do not justify additional namespace bumps. - Florian 1: https://news.ycombinator.com/item?id=9829253 2: https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ 3: Which, BTW, is Smack's default, but it can be changed so that invalidated stanzas are simply ignored. > On Mon, 2017-12-04 at 11:18 +0100, Florian Schmaus wrote: >> On 04.12.2017 10:33, Evgeny Khramtsov wrote: >>> Mon, 4 Dec 2017 09:29:41 +0100 Florian Schmaus <[email protected] >>> <mailto:[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 >> >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> <mailto:[email protected]> >> _______________________________________________ > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
