[Standards] XEP-0198 status

Peter Saint-Andre stpeter at stpeter.im
Wed Jan 12 20:26:52 UTC 2011

That seems mostly reasonable to me. I see a possible edge case if the
reconnecion address (ip:port or host:port or whatever) isn't actually
there by the time the initiating entity tries to reconnect, i.e., the
server tells me the reconnection address and a few days later when my
session dies I finally try to reconnect but the address that the server
*thought* was going to work a few days ago isn't so much alive anymore.
Do we need to worry about that? If so, does the initiating entity just
follow the rules from 3920bis regarding the connection process? (See for
instance the rules for <see-other-host/> in 3920bis...)

On 1/12/11 1:20 PM, Joe Hildebrand wrote:
> We would like to see another attribute on the <enabled/> element that tells
> you where to reconnect if you get disconnected.  If you're using a load
> balancer in front of a large number of front-end boxes, getting back to the
> same one (instead of getting load balanced again) would be a nice way to
> find the session state that you need in order to resume.
> On 1/12/11 12:56 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
>> In preparation for the XMPP Summit in a few weeks, I'm reviewing the
>> status of several XEPs and preparing summaries so that we can quickly
>> come to agreement regarding open issues. First on my list is XEP-0198.
>> Many moons ago (last June, July, and September) there was a discussion
>> thread about this spec:
>> http://mail.jabber.org/pipermail/standards/2010-June/023512.html
>> http://mail.jabber.org/pipermail/standards/2010-June/023525.html
>> http://mail.jabber.org/pipermail/standards/2010-June/023526.html
>> http://mail.jabber.org/pipermail/standards/2010-July/023647.html
>> http://mail.jabber.org/pipermail/standards/2010-July/023649.html
>> http://mail.jabber.org/pipermail/standards/2010-July/023655.html
>> http://mail.jabber.org/pipermail/standards/2010-July/023656.html
>> http://mail.jabber.org/pipermail/standards/2010-July/023648.html
>> http://mail.jabber.org/pipermail/standards/2010-September/023770.html
>> http://mail.jabber.org/pipermail/standards/2010-September/023768.html
>> http://mail.jabber.org/pipermail/standards/2010-September/023769.html
>> http://mail.jabber.org/pipermail/standards/2010-September/023797.html
>> http://mail.jabber.org/pipermail/standards/2010-September/023846.html
>> I see two main points...
>> 1. Dave Cridland helpfully sent in a patch based on implementation
>> feedback in M-Link and Psi, analyzed here:
>> http://mail.jabber.org/pipermail/standards/2010-September/023769.html
>> I don't disagree with anything in the patch, so I think it can be
>> applied, and will plan to do that soon if there are no objections from
>> my co-authors. I'll also add Dave as a co-author, naturally.
>> 2. Folks seem to think it would be good to replace the current rule
>> (based on number of stanzas) with a time-based rule. For example,
>> Matthew Wild wrote:
>>    I think the unacked stanza count should be switched for a time-based
>>    algorithm. Perhaps something along the lines of the BOSH timeout
>>    handshake...
>> IMHO that is a good topic for discussion at the Summit, or of course
>> here on the list before then. It's not reflected in Dave's patch, unless
>> I'm missing something obvious.
>> Are there any other issues we need to discuss regarding XEP-0198?
>> Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110112/3318013a/attachment.bin>

More information about the Standards mailing list