[Standards] Re: compliance levels for 2008
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...
More information about the Standards