[Standards-JIG] [Fwd: [interop] day 1 summary]

[Peter Saint-Andre]

Some results from the first day of the XMPP interop test event being
held this week....

/psa

-------- 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.

******

TESTING....

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.

******

DISCUSSIONS....

1. Hostname mismatches

- client can force specific host via config
- pop-up warning about mismatch, use must approve

2. SRV

- SRV preferred but not widespread so need a fallback
- do TXT (JEP-0156) to get domain to do SRV or other against

For example:

1. SRV "example.com" -> NAME
2. TXT "example.com" -> example.net
3. SRV "example.net" -> ?
4. A "example.net"
5. A "example.com"

3. see-other-host

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

6. Kerberos

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

9. Dialback

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
validation

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).

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml


-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20060725/7aa50c51/smime.bin