[Standards-JIG] [Fwd: [interop] day 1 summary]
stpeter at jabber.org
Tue Jul 25 18:49:04 UTC 2006
Some results from the first day of the XMPP interop test event being
held this week....
-------- Original Message --------
Subject: [interop] day 1 summary
Date: Tue, 25 Jul 2006 10:39:50 -0600
From: Peter Saint-Andre <stpeter at jabber.org>
Reply-To: XMPP interop discussions <interop at jabber.org>
To: interop at jabber.org
Before the memories fade, here is a quick summary of day 1 at the XMPP
interop testing event...
Participants: Jacques, Mridul, Joe, Travis, Gato, Matt, Mickael, Alexey,
Artur, JD, Gary, Sean.
Servers tested: ejabberd, Jabber XCP, SoapBox, Sun Java System IM, Wildfire
Clients tested: Adium, iChat, JBother, Spark, TKabber, etc.
Basic results: we had successful client-to-server and server-to-server
communications between all clients and servers, including the following:
- stream headers
- authentication via SASL
- server dialback
- non-ASCII characters in XMPP node identifiers
- presence subscriptions
- roster management
- messaging and IQs
Please amplify or correct as appropriate.
1. Hostname mismatches
- client can force specific host via config
- pop-up warning about mismatch, use must approve
- SRV preferred but not widespread so need a fallback
- do TXT (JEP-0156) to get domain to do SRV or other against
1. SRV "example.com" -> NAME
2. TXT "example.com" -> example.net
3. SRV "example.net" -> ?
4. A "example.net"
5. A "example.com"
clarify what happens with ports in see-other-host
- use whatever port you were using and whatever method
- if fail, try SRV etc. against that hostname
4. Client reconnection algorithm
clients should (not must) re-resolve DNS before re-connecting
TTL should take care of concerns
honor TTLs even if caching DNS results
randomize reconnect time
back off exponentially on subsequent reconnects
5. Mandatory to implement
Section 14.7 of RFC 3920bis include PLAIN over TLS
Remove kerberos examples from RFC 3920
7. Extensions in presence subscriptions
There may be an extension in presence subscriptions, should pass it on
(don't just toggle subscribe bit)
8. Stream features
all stream features must have the <required/> child so know when it's OK
to start sending stanzas
need to define dialback stream feature
define SASL mechanism for "dialback"? no
if get the right kind of cert, present SASL-EXTERNAL mechanism
if cert not trusted, present dialback stream feature to at least do weak
10. Resource binding
need a way to do unbind resources and need better description of binding
more than one resource
sending client SHOULD set from address
if no 'from' set by client, server SHOULD stamp 'from' as first resource
11. Privacy lists
ick, too complex, few have implemented, no one is using
let's remove this from rfc3921bis (put it back in JEP-0016) and add a
simple blocking mechanism since that's all we really need to conform
with RFC 2779
I have notes on some other stuff (in-band registration, quick re-auth,
best practices for auto-away, pubsub/pep, invisible presence, etc.). I
will send separate messages about that (not necessarily to this list,
probably to standards-jig or jdev as the case may be).
Jabber Software Foundation
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards