[Standards] UPDATED: XEP-0363 (HTTP File Upload)

Florian Schmaus 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 [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 <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...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171204/0ca3727b/attachment.sig>

More information about the Standards mailing list