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

Florian Schmaus flo at geekplace.eu
Mon Dec 4 10:18:27 UTC 2017


On 04.12.2017 10:33, Evgeny Khramtsov wrote:
> Mon, 4 Dec 2017 09:29:41 +0100
> Florian Schmaus <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

-------------- 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/c939f384/attachment.sig>


More information about the Standards mailing list