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

Florian Schmaus flo at geekplace.eu
Mon Dec 4 08:29:41 UTC 2017

On 04.12.2017 07:34, Evgeny Khramtsov wrote:
> Sun, 03 Dec 2017 19:01:58 -0000
> Jonas Wielicki (XSF Editor) <jonas at wielicki.name> wrote:
>> Version 0.4.0 of XEP-0363 (HTTP File Upload) has been released.
> The new element <retry/> is added within *existing* namespace.

Which is sensible, given that its backwards compatible.

> Also, I remind, that RFC6120 Section 11.4 says:
>> An implementation MAY choose to accept or send only data that has been
>> explicitly validated against the schemas provided in this document,
>> but such behavior is OPTIONA>
> So, this rule doesn't apply to XEPs schemas?

I think so, given that it explicit says "schemas provided in this document".

> In the case it does, what
> schema version should a server use to validate the content? In the case
> it doesn't, what a server should do with unknown element within
> *known* namespace (sic): dropping element?

> remain it untouched?

This ^

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.

> The
> latter case is meaningless, because the idea of server-side validation
> is to prevent sending garbage to clients.

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. And you want to enforce a maximum
top-level stream element size early in the processing chain. But if you
have that, what is the gain in validating against a schema?

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

More information about the Standards mailing list