[Standards] XEP-0198 status

Peter Saint-Andre stpeter at stpeter.im
Sat Feb 12 13:17:27 UTC 2011

All I have so far is:


The <enabled/> element MAY include a 'location' attribute to specify the
receiving entity's preferred IP address or hostname (optionally with a
port) for reconnection; if reconnection to that location fails, the
standard XMPP connection algorithm specified in XMPP Core [9] applies.


Further details in Section 5 would indeed be a good idea.

On 2/11/11 10:33 PM, Joe Hildebrand wrote:
> I don't see any description of the syntax or semantics of the location
> attribute yet.  XMPP URI seems like overkill, but since we need to support
> IPv6, colon-separated probably isn't right.  Perhaps we could just split
> host and port into two separate attributes?
> For semantics, there needs to at least be a mention in section 5.
> On 2/11/11 1:56 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
>> OK folks, I've made a first attempt at updating the spec, including
>> Dave's patch. The results are here:
>> http://xmpp.org/extensions/tmp/xep-0198-1.2.html
>> Please review and comment.
>> (IMHO the document doesn't provide a super-clear explanation of what the
>> protocol does and why it matters -- I'll try to add a paragraph like
>> that to the introduction.)
>> /psa
>> On 1/12/11 12:56 PM, Peter Saint-Andre 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/20110212/e04e6aa8/attachment.bin>

More information about the Standards mailing list