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.
