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

Kevin Smith kevin.smith at isode.com
Tue Dec 5 09:34:31 UTC 2017


On 5 Dec 2017, at 09:31, Jonas Wielicki <jonas at wielicki.name> wrote:
> 
> On Dienstag, 5. Dezember 2017 08:30:38 CET Kevin Smith wrote:
>> On 4 Dec 2017, at 09:33, Evgeny Khramtsov <xramtsov at gmail.com> wrote:
>>> 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.
>> 
>> I think that’s ok, isn’t it?
>> 
>> I think the two options (as-is, or new namespace) are equivalent from your
>> validator’s point of view: 1) As-is: previous version payloads are allowed
>> through, new versions won’t be allowed through until the validator is
>> updated 2) New namespace: previous version payloads are allowed through,
>> new versions won’t be allowed through until the validator is updated
>> 
>> So I don’t think that on it’s own is necessarily a reason to bump the
>> namespace, is it?
> 
> I don’t think that’s ok. ejabberd would violate the expectation of the user 
> that either a type="result" or type="error" is returned, if they simply filter 
> out the "erroneous" stanza.

I think you’re responding to a different point than I was making. I’m saying that bumping or not makes no difference here. In both cases a validator that doesn’t understand the new elements won’t accept them.

> Also, I still don’t believe that intermediate servers should validate content 
> which doesn’t concern them.

This is a real use case. You won’t typically see it much on the Internet, but it’s a real use case.

/K



More information about the Standards mailing list