I think this conversation boils down to whether XML validation or the
Internet 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?
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]> 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]
> _______________________________________________
--
Beste Grüße,-Marcel Waldvogel University of Konstanz Distributed Systems Laboratory Efficient Secure and Private Collaboration
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
