[interop] day 1 summary

[JD Conley]

Though I'm not Peter, I would say so, yes. It is certainly an option in
our server that some extremely bandwidth conscious people choose to
disable.

-JD

-----Original Message-----
From: interop-bounces at jabber.org [mailto:interop-bounces at jabber.org] On
Behalf Of Mridul Muralidharan
Sent: Wednesday, July 26, 2006 1:27 AM
To: XMPP interop discussions
Subject: Re: [interop] day 1 summary


Hi Peter,

  This is something I should have brought it up today ... forgot about
it.
Is TLS also a "MUST implement" but not necessary to deploy/expose
feature ?


Regards,
Mridul

Peter Saint-Andre wrote:
> 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
>
>