[interop] day 1 summary

[Peter Saint-Andre]

Yes, and we need to write more examples for that.

JD Conley wrote:
> 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
>>>
>>>   
>>>     
>>   
> 
-------------- 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/interop/attachments/20060727/c1a7ab08/smime-0001.bin