[standards-jig] Essence of Jabber

David Waite mass at akuma.org
Thu Mar 7 00:50:46 UTC 2002


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)
>
as a minimum, yes.

>
>- it is fundamental that the JID address format be supported and honoured
>
yes

>- the part providing user session services must employ the spoof-
>  prevention service of stamping jabber:client incoming packets
>
no

>
>- DNS SRV record lookup must be supported for s2s connections
>
yes

>- server should ignore PIs, comments, pre-defined entities, etc
>
should, yes. required, no.

>- UTF8?
>
as a minimum. UTF-16 should work, but isn't required (I don't really 
have a way of testing that it does)

>- how about ignoring any unknown (non iq, message, presence, or route)
>  packets?
>
extra top-level packet types are undefined. The current implementations 
return errors on these.

>- don't break on unknown extensions - just ignore
>
already specified.

>- 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)
>
the actual logic expected was not specified, AFAIK.

>- routing : resource-based matching
>
I thought this was defined. Behavior of routing to resources which do 
not have a match is pretty much undefined.

-David Waite




More information about the Standards mailing list