[Standards] SUMMARY: compliance levels

Mridul Muralidharan mridul at sun.com
Tue May 8 21:45:29 UTC 2007

Peter Saint-Andre wrote:
> This message attempts to summarize the recent thread about compliance 
> levels. I see consensus on the following:
> 1. The Basic levels address more generalized XMPP functionality whereas 
> the Intermediate Client level includes features that are specific to IM 
> and presence clients. This probably should be reflected in the name of 
> the intermediate level ("XMPP Intermediate IM Client 2008" or whatever).
> 2. We need an Intermediate Server level. This probably should include 
> PEP (XEP-0163). It should also include the ability to support add-on 
> components (whether internal or external) for things that are required 
> by the Intermediate Chat Client level (e.g., MUC).
> 3. Start TLS in Basic. (In fact this is required by RFC 3920 so I don't 
> understand the confusion.)
> I don't see consensus (yet) on the following:
> 1. Stream Compression (XEP-0138) in the Basic levels. (ISTM that this 
> should not be necessary, since Transport Layer Security includes a 
> compression option and there should be support for it in common SSL 
> libraries.)
> 2. JID Escaping (XEP-0106) in the Basic levels. (This seems like a good 
> idea to me.)
> 3. Removing Entity Capabilities from the Basic levels. (Lots of 
> objections on the list, the main argument in favor is that there are 
> some reputed security concerns w.r.t. poisoning, but IMHO if you follow 
> the spec these are not very threatening. But the spec could be beefed up 
> in this regard if desired.)
> 4. Including communications blocking (XEP-0016 and XEP-0191) in the 
> Intermediate levels. (This seems like a good idea to me.)
> 5. Avatars. (Which approach?)

Good point.
The old method or the newer pep way ?
We support pep based avatar as of now ...

> 6. vCards. (No major objections to date.)
> 7. XMPP URIs. (What does this mean for clients? Just register the client 
> as a helper app and off you go.)
> 8. Bookmarks. (Introduces a dependency on iq:private and in any case I 
> am not convinced that iq:private is the right place to store JIDs 
> anyway, see [1].)

[1] would be great.
To address some of the queries (which nick to use, what if password 
protected, etc) - maybe those could be metadata to the roster entry ? 
This way, as part of initial presence broadcast - the corresponding 
metadata indicates that it is a conference room and provides required 
info to the server for autojoin.
It would be great if you can spec this Peter, imo it is a neat idea !

> 9. File Transfer. (Which approach? XEP-0096? But it doesn't work well, 
> NATs suck etc., use the non-existent Jingle FT? IMHO this belongs in the 
> "XMPP Multimedia Client 2009" level...)

We support ibb for precisely this reason, throttle traffic and allow ibb 
- works in all usecases.
oob is supported but p2p cant be always reliably set up - especially in 
face of firewall.

> 10. MUC: all or only part for Intermediate? (An "Advanced IM Client" 
> level might include all the room admin stuff.)

If clients need to support it, then there should be some way to specify 
the corresponding server side support also ... could be within server or 
through component - either way it must be possible to support it.
Existance of external conference components does not mean those should 
work with a server.


> /psa
> [1] http://mail.jabber.org/pipermail/standards/2007-March/014646.html

More information about the Standards mailing list