On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote:
I actually think that moving stream management after the bind is a
good thing. Much more flexible, and a relatively minor change.
I think moving sm-id generation - which is the real issue - until
after resumable sessions are enabled, and explicitly making sm-id a
one-use resume ticket, is certainly a good idea. I think restricting
the protocol to C2S is a bad idea.
I didn't get what you said after this, because the first part
didn't really make sense to me. Are you suggesting that we do
XEP-198 on S2S connections? Why bother? They're close enough to
stateless that we shouldn't perturb -198 will new requirements.
Reliability, not optimization.
- When the server gives stream features for resumption, it MAY
include a hostname/IP and port on which to reconnect. This allows
some flexibility of deployment.
Right, that's possible, although I'd suggest we actually made the
default to reconnect on the same address as before (ie, the same IP
address and port).
- Server gives the client a max number of stanzas between
acknowledgements. That way the server can have some control over
what it needs to buffer.
Good point.
- Server tells the client the maximum amount of time it will keep
the session around after disconnection, in seconds. If the client
can't get reconnected in that timeframe, it can drop its state.
I think we do this already?
- Clients SHOULD NOT send ack requests back-to-back, without
intervening stanzas.
It's equivalent to a ping, I don't see the harm here.
Specifically, while I can see reasons not to do this, I can't see
what would cause interop problems.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
