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

Evgeny Khramtsov xramtsov at gmail.com
Mon Dec 4 09:33:36 UTC 2017


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.

Well this approach is wrong. Why would we need other namespaces then?
We can put everything inside 'jabber:client'. Or, otherwise, what stops
me from putting my own invented elements (and attributes) inside
existing registered namespaces? Do we really need this mess?

> 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?

> 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).


More information about the Standards mailing list