Sorry, just catching up on the thread. An interesting discussion. :) On 3/7/09 10:45 AM, Joe Hildebrand wrote: > 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'/>
Yes, that seems reasonable. For s2s the sm-id would be generated after
SASL EXTERNAL, for c2s after resource binding.
> 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."
Something like that, yes. I can wordsmith.
> 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.
Mickael, does that work for you?
>>> 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.
Ditto.
>>> - 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.
Agreed.
> When you're deployed behind a load balancer, the client
> doesn't have enough info to do that, however.
So then the server needs to be smart.
>>> - 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.
I think seconds is better. It seems to me that it might be less than a
minute.
>>> - 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?
We don't. We wrote the XMPP Ping stuff because people weren't as
friendly to Stream Management ("Stanza Acking") back then.
I will endeavor to update XEP-0198 today or tomorrow so that we all have
a clearer vision of the protocol.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
