[interop] day 1 summary

[Peter Saint-Andre]

Er, now that I look at this thread more, I see that this is a bit
misleading. For mostly political reasons, we'll never say in rfc3920bis
that dialback is a must implement. However, practically speaking it is.
As noted separately, I intend to make it easier for server admins to
obtain certificates for their XMPP servers.

Peter Saint-Andre wrote:
> 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/20060803/8ac8aa6d/smime.bin