[Standards] LAST CALL: XEP-0220 (Server Dialback)

Philipp Hancke fippo at goodadvice.pages.de
Wed Aug 21 19:21:12 UTC 2013


Am 21.08.2013 21:07, schrieb Peter Saint-Andre:
[...]
>>> This = mid-session stream feature negotiation?
>>
>> Yes. Basically I would expect all stream feature negotiation to
>> happen immediately in response to <stream:features/>. Not after
>> doing something else (like dialback).
>
> Well, we can't negotiate everything at once. :-) So you might
>negotiate Feature1 and then Feature2.

Right, but are there cases where you feature1 doesn't require a stream 
restart? If there are such cases, shouldn't you negotiate them in a 
single step?
Practically, I don't think it matters. We would have run into that 
problem otherwise. Let's just fix 0170.

> And dialback is weird because it
> predates the whole stream features framework.

yes. Unfortunately, I didn't manage to kill it last year :-/

>> I do not think that the receiving server would enforce such a rule
>> however. And we have just removed two features that would have
>> required a stream restart, which is certainly a bad idea
>> mid-session, so no objection from me.
>
> I definitely agree about mid-session feature negotiation and stream
> restarts.

Great.

>> [...]
>>>> http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-flowchart
>>>>
>>>>
> doesn't return from DONE
>>>
>>> Erratum reports are always welcome. ;-)
>>
>> No, I think that the flowchart makes sense. We might want to keep
>> this discussion in mind for 6120bis though.
>
> Agreed! Not that I'm looking forward to that work (although I think
> the eventual diff will be relatively small -- certainly a lot smaller
> than the changes between 3920 and 6120).

can we make it a STD then? It's a pity xmpp isn't considered under the 
2-step process.



More information about the Standards mailing list