[interop] day 1 summary

[JD Conley]

Yes, definitely. Dialback (or some trusted SASL mechanism) is a MUST if
TLS does not yield mutual trust.

-JD

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

Hi,
  The reason I was asking was that without TLS being used , dialback
kind of becomes mandatory ... unless both the server already have some
sort of private auth mechanism that is.
Which might make supporting dialback a slightly stronger requirement for
s2s - if no tls or untrusted cert == dialback MUST ?

Mridul

JD Conley wrote:
> 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
>>
>>   
>>     
>
>