[Standards] Re: compliance levels for 2008

Boyd Fletcher boyd.fletcher at je.jfcom.mil
Mon May 7 20:08:30 UTC 2007


It simply makes no sense to me to have an Intermediate Client spec that
mandated MUC and not have an equivalent Intermediate  Server spec that
matches up with the client spec. Talk about sending a mixed message to the
users.

I think MUC is important enough and so universally implemented that it
deserves to be in an intermediate spec. I definitely agree that testing
should be against a distribution not just the pure XMPP server.

On 5/7/07 3:44 PM, "Rachel Blackman" <rcb at ceruleanstudios.com> wrote:

>>>> >>> Implementation is different from deployment. Compliance levels
>>>> >>> are for
>>>> >>> software implementations, not service deployments.
>>> >> Hmm, but can't just about anything be componentized?  How would a
>>> >> MUC module
>>> >> be distinct from, say, a StartTLS module in terms of compliancy?
>> > And from the other side: some features in clients could be implemented
>> > as plugins.
> 
> Arguably, the compliance levels should test against a given
> distribution.  It does not matter if the server implements TLS as a
> plugin or not, so long as it does so /in the distributed version/.
> It could be implemented by telepathic carrier pigeons running data
> back and forth to an Enigma machine, for all the other side cares;
> they just want to know that it speaks TLS.
> 
> It seems to me that there does not necessarily need to be feature
> parity between the client and server compliance levels, either; MU-C
> is nice, but is not necessarily a required feature on every single
> server situation.  But whether or not a given server has MU-C or not,
> it's useful for the CLIENT to support it (since you can, after all,
> use MU-C on other servers).  So for the client, sure, MU-C can be in
> a plugin rather than in the core, but that plugin then has to be part
> of both the tested installation and part of the distribution package
> if you want that package to be able to claim compliance.
> 
> For MU-C, that is not something which MUST be in a server; there are
> lots of different implementations for it, and it's not worth the time
> to test every implementation/server pairing.   But it /is/ important
> for general end-user clients to have it.
> 
> (Arguably, there's a good place for a 'XMPP Conference Server 2009'
> specification down the line, for MU-C server implementations to be
> tested against.)
> 
> And to stave off the argument I can already sense incoming on the
> 'but you said servers may not need it'... CLIENTS, however, have an
> obligation to run in a wider variety of situations.  Sure, someone
> may have a corporate client used in one situation which does not need
> MU-C and XHTML-IM and so on.  But then arguably they don't /need/
> Intermediate compliance anyway and will find Basic sufficient. :)
> 
> --
> Rachel Blackman <rcb at ceruleanstudios.com>
> Trillian Messenger - http://www.trillianastra.com/
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070507/da41b88f/attachment.html>


More information about the Standards mailing list