[Standards] Re: compliance levels for 2008

Boyd Fletcher boyd.fletcher at je.jfcom.mil
Fri May 11 16:26:47 UTC 2007

So what if it can be federated out? so can lots of other server features.
The point if you are going to have a requirement for intermediate clients to
support MUC then you need you have a requirement that intermediate servers
support MUC. Whether it implements MUC directly in the server code, in a
component, in a separate server behind the main XMPP router are all
irrelevant from the perspective of the users.

I think it is completely reasonable that any person purchasing or
downloading an XMPP solution should expect a basic client and basic server
are functionally comparable and they would rightly assume that an
intermediate server and intermediate client are functionally comparable. If
user can¹t make that type of reasonable assumption then the compliance level
stuff is worthless from the perspective of a customer.


On 5/10/07 3:35 PM, "Nathan Fritz" <nathanfritz at gmail.com> wrote:

>> One point against having MUC as a requirement is that MUC can be
>> federated out. users on hawkesnest.net <http://hawkesnest.net>  can access
>> MUC at
>> conference.jabber.org <http://conference.jabber.org> . So the implemented
>> services of hawkesnest.net <http://hawkesnest.net>
>> arguably include MUC, regardless of whether it's a part of that server.
>>   This is distinct from a mere plugin like starttls.
> This is exactly the reason why it makes sense to have MUC as a client feature
> and not as a server.  Just because your server doesn't support MUC doesn't
> mean that you can't use conference.jabber.org <http://conference.jabber.org>
> or any other MUC service.

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

More information about the Standards mailing list