[Standards] UPDATED: XEP-0363 (HTTP File Upload)
flo at geekplace.eu
Mon Dec 4 11:27:17 UTC 2017
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  and the way it is (mis)understood is
considered harmful . I also think that any interpretation of it does
not apply here.
I believe that it is better to fail hard and fast , 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.
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 <flo at geekplace.eu
>>> <mailto:flo at geekplace.eu>> 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: Standards-unsubscribe at xmpp.org <mailto:Standards-unsubscribe at xmpp.org>
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 642 bytes
Desc: OpenPGP digital signature
More information about the Standards