[Standards] XEP-0198 status

Ben Schumacher bschumac at cisco.com
Sat Feb 12 09:46:24 UTC 2011

I think using RFC3986 (2732) formatting rules for supporting IPv6 
address/port in a single attribute would be fine. Any software that 
intends to communicate over IPv6 is probably going to need to understand 
that format at some point.

One other important clarification on the address might be a 
recommendation regarding address resolution. Is the intention for 
clients to fallback to an SRV lookup on the provided location, or should 
the information provided give them another hint as to how to use it.

What I mean is, is the "location" also simply an address/hostname and 
port combination, or might it be an HTTP URI if this protocol is being 
used in connection with BOSH?

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

More information about the Standards mailing list