[interop] day 1 summary

[Mridul Muralidharan]

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