On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote:
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.
OK, fine. And I see what you're getting at in your other mail. So
we'd do this:
S: <stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<required/>
</bind>
<sm xmlns='urn:xmpp:sm:0' max='15' stanzas='4'>
<optional/>
</sm>
</stream:features>
C: <iq id='bind_1' type='set'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</iq>
S: <iq id='bind_1' type='result'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>
jul...@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb
</jid>
</bind>
</iq>
C: <enable xmlns='urn:xmpp:sm:0'/>
S: <enabled xmlns='urn:xmpp:sm:0' resume='1' id='some-long-id'/>
Then I think all that is needed is couple of sentences in section 2
that says something like:
"All other stream features offered along with the stream management
feature which the initiating entity wishes to process MUST be
processed before the stream management feature. This will typically
mean that you bind your resource BEFORE you initiate stream management
on client-to-server streams."
And then a section that talks about the id, how it's opaque to the
initiating entity, that any characters allowed in an XML attribute may
be used, it must not be reused, and that it has a max size of say...
4k. If Mickael wants to encode his id as the full JID plus a nonce,
he can.
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.
Got it.
- 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).
If the server doesn't specify, then yes, SHOULD connect back to the
same IP/port. When you're deployed behind a load balancer, the
client doesn't have enough info to do that, however.
- 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?
Oops. I missed that. There should probably be a little more text that
describes the consequences of max. Is minutes enough resolution? I
don't have a strong opinion about that.
- 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.
Hm. Why do we need the pings as separate protocol, then?
--
Joe Hildebrand
