[Interop] online testing environment

[Gaston Dombiak]

Hey StPeter,

Good to hear that we are moving in this direction. :)

1) Wildfire 3.2 allows managing certificates from the admin console.
Therefore, I was thinking that it would be nice to test the process to
sign new certificates with the new ICA. Is there any documentation that
we can read about this?

2) The ICA will be a trusted CA so I think that we should add the root
cert of the ICA to the trusted certs provided by each server (this
comment applies to those servers that provide their own list). Where can
we get the ICA cert? It would be cool to add it to Wildfire 3.2 to be
released on January 31st.

3) I think that besides organizing the testing environment (step 0) :)
we also need to organize the list of tests to run and (ideally) log the
results so we can get the overall situation on where we are standing and
progress we are making. May be we can use a wiki to organize and keep
track of this info?

Regards,

  -- Gato


-----Original Message-----
From: interop-bounces at xmpp.org [mailto:interop-bounces at xmpp.org] On
Behalf Of Peter Saint-Andre
Sent: Friday, January 19, 2007 1:19 PM
To: interop at xmpp.org
Subject: [Interop] online testing environment

At the 1st XMPP interop event last July, we talked about building an 
online environment for ongoing testing of XMPP-based software. I think 
it's time to start making that a reality, especially since I mention it 
at http://www.xmpp.org/xsf/roadmap.shtml :-)

Here's what I think the next steps are:

1. Define an agreement that members of the online testing system will 
sign and adhere to. This will involve things like non-disclosure of bugs

found, use of the system only for protocol compliance testing (not for 
scalability testing or whatever), etc. I will work up a draft of this
soon.

2. Define who may join. I see this being limited to developers (or QA 
testers) of XMPP-based software. No marketing people. No customers. Etc.

3. Define how it will work. I see two aspects:

a. Server instances will be hosted by the relevant project or company 
and the XSF will simply point DNS at the IPs provided. So let's say that

the ejabberd team participates -- at the XSF we will point something 
like ejabberd.interop.xmpp.org at an IP address that the ejabberd team 
tells us about, and the ejabberd team will run that server on their own 
hardware. Nothing will be hosted at the XSF infrastructure unless that's

absolutely necessary.

b. Client developers (and for that matter server developers) will 
register at a website like https://interop.xmpp.org/ (no, that doesn't 
exist yet). They will choose a preferred username to be set up at each 
server instance. That way a given developer on, say, the Psi project 
will be able to log in as psidev at ejabberd.interop.xmpp.org and so on. 
We'll need to figure out some algorithm for password creation.

4. Make it secure. All connections (c2s and s2s) will be protected via 
TLS. To make that easier, the XSF will issue certificates (both domain 
and, in the future, end-user) through its intermediate certification 
authority. Only authorized users (registered as above) will be allowed 
to use the system. No in-band registration. Etc.

Anything else?

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml