On 04.12.2017 07:34, Evgeny Khramtsov wrote: > Sun, 03 Dec 2017 19:01:58 -0000 > Jonas Wielicki (XSF Editor) <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
