[standards-jig] Essence of Jabber

Thomas Muldowney temas at box5.net
Thu Mar 7 04:37:26 UTC 2002

Well I didn't want to make the SSL debate any deeper so I'll put my
thoughts on that at the end.

On Wed, 2002-03-06 at 15:00, DJ Adams wrote:
> Hi all
> well, I read through the IETF proposal with a view to extracting extra
> bits (in addition to the namespace-orientated list at 
> http://www.pipetree.com/jabber/sc-jig/ns-usage.html) which seemed to 
> characterise the essence of what Jabber is, and more specifically, what
> a Jabber server (I'm concentrating on server implementations, here) needs
> to implement to be a Jabber server. 
> I'll just jot down the notes I made, here:
> - must the server support TCP connections (as opposed to other network
>   type connections)? (I think the answer may be obvious but the question
>   needs to be asked)

I want to say no at first, because that's what we've always said is
possible, but then I read Diz's post.  If we don't have some base it's
hard to be able to use any server.

> - it is fundamental that the JID address format be supported and honoured
> - the part providing user session services must employ the spoof-
>   prevention service of stamping jabber:client incoming packets
> - DNS SRV record lookup must be supported for s2s connections
> - server should ignore PIs, comments, pre-defined entities, etc
> - UTF8?
> - how about ignoring any unknown (non iq, message, presence, or route)
>   packets?
> - don't break on unknown extensions - just ignore

Yes to the above set

> - presence management (availability tracker, diffusion, invisibility, etc)
>   (I'm including these, as they're basic JSM features, but not represented
>   by a namespace (i.e. 'presence management' isn't really in the other list)
> - routing : resource-based matching

Gut says no

> - SSL connection support? 

Ahhh SSL.  This is a big fat NO.  Yeah, it's beneficial on many levels,
but it's definately not needed for a common benchmark.  Plus I don't
think it's as beneficial to the security as we like to think, especially
without proper certs.  We need more time on a real XML security spec
(probably based on the XML Encryption Standard), than just saying SSL
covers it.  Hopefully I'll have some time this weekend to work on that


More information about the Standards mailing list