[Standards] Re: compliance levels for 2008

Nathan Fritz nathanfritz at gmail.com
Fri May 4 23:53:02 UTC 2007

These compliance XEPs make some assumptions; they assume the goal and
purpose of a client to a minor extent, and then seem to fall short in
committing completely to these assumptions.

Basic Client includes Service Discovery which is probably essential to any
client that wants to deal with different clients other than it's own exact
version.  Probably a safe assumption.  But it also includes Entity
Capabilities, which seems to assume that a Basic Client needs to go to extra
efforts to conserve bandwidth.  If this is the assumption, why exclude
XEP-0138 Stream Compression?  If that's too much to expect of a Basic
Client, and assuming that an Intermediate Client has the same goals, then
shouldn't it include Stream Compression?  Perhaps the assumed goal or ideal
behind a client isn't that it's conserving bandwidth in general, but in that
it conserves bandwidth for the jabber network, which Stream Compression
would do little to help, where as Entity Capabilities cuts down not only on
c2s but s2s traffic as well.  If that's the case, then I see the point of
not going that far, but I think an argument could be made that it would be
ideal for an Advanced Client, should there ever be compliance spec for one.

Intermediate Client makes the leap to assume that an XMPP client is a GUI
based IM client by including XHTML-IM.  This seems like a Jabber Client
ideal rather than an XMPP client ideal, which may totally be the point.
Perhaps it is simply assumed that clients seeking compliance certifications
will be limited to GUI and/or IM clients.  I've personally used XMPP in
integration and automation models as well, although I can see the argument
that such clients do not need to be certified because they are solving
specific problems while IM clients are solving the more broad problem of
helping two people interact over the Internet.

Basic Server makes the assumption that they should work with legacy
clients.  Not a bad assumption, and it merely recommends that it meet the
ideal, and doesn't go as far as to require it.

My point is not that these are bad compliance specs.  My point is that they
should be thought through.  I imagine that Peter made some assumptions and
filled in the blanks based on those, and that is a good approach.  However,
I believe that we should document and discuss those assumptions so as to
give these specs critical thought.

The first step is to make a list of goals and ideals that we believe a
client and server should uphold.
The second step is to assign RFCs and XEPs to those ideals and goals,
limited by, perhaps, whether the XEP is draft and other such requirements.
The third step is to assign weight to these XEPs by percieved difficulty to
implement so that we may assign them to "Basic," "Intermediate", and
Finally, we should evaluate how important to these ideals are to a client
and server to determine whether they are REQUIRED or RECOMMENDED.

Any thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070504/9e33f1cd/attachment.html>

More information about the Standards mailing list