[JDEV] JavaJabber Server Docs

[Al Sutton]

David,

I've come accross some features which I couldn't find a reference to in the
protocol documentation. This may be because I looked in the wrong place, but
the two I've seen so far when working with JIM are;

- When a client tries to subscribe to another user via a presence message,
an iq message of type set holding the new roster entry reflecting this needs
to be sent back to the client.

- Messages comming from the client in the  jabber:iq:roster namespace can
have an undocumented value in its subscription attribute of "remove" which
indicates they should be removed from the users roster.

I'm basing the second comment on reading the "Roster Management" document in
the "Protocol - standard" section of docs.jabber.org which states

"An example item from the roster with all possiblities:

<item jid="user at server" name="Some User" subscription="to|from|both|none"
ask="subscribe|unsubscribe">
  <group>friends</group>
  <group>school</group>
</item>"

and a message trace from JIM which, when attempting to remove a contact from
the roster sends

<iq type="set" from="alx at cloud/Work" id="JCOM_4"><query
xmlns="jabber:iq:roster"><item name="al at cloud" jid="al at cloud"
subscription="remove"><group>Friends</group></item></query></iq>

I'll post any new ones when I seem them.

Al.


----- Original Message -----
From: "David Waite" <dwaite at jabber.com>
To: <jdev at jabber.org>
Sent: Monday, July 09, 2001 9:05 PM
Subject: Re: [JDEV] JavaJabber Server Docs


> I would actually agree here. Nothing like a radically different
> implementation to point out things which are implementation-specific
> which were taken for granted. One of the fears I had was that the
> 'newer' server developer would hit a lot of problems trying to implement
> something like 'presence' based on existing docs, and implementation
> just based on docs would create something which a lot of clients which
> have hacked against the implementation would not agree with. It would be
> a really bad if trying to do a different implementation caused them to
> get flak for implementing things in an incompatible way.
>
> Luckily, I believe that Jabelin is considering starting a new server
> implementation and architecture themselves, meaning that it won't
> necessarily be 'us vs. them' when it comes to something that is
> implemented differently due to lack of specs. I really hope that people
> doing the actual implementation work are disciplined enough to document
> things they misunderstand :-)
>
> -David Waite
>
> Iain Shigeoka wrote:
>
> >--- Jay Lorenzo <jlorenzo at uswest.net> wrote:
> >
> >>One thing I'd like to throw out here is the possibility of using a
> >>common
> >>design with the Jabelin folks. I think we may be best served by
> >>participating in the design process with the Jabelin folks, which I
> >>believe
> >>is just starting this process. We may want to consider having a 'subsig'
> >>under Jabelin, using an 'org.jabber' namespace.
> >>
> >
> >I actually think it would better serve the Jabber
> >community if the two servers were developed
> >independently.  One of the more interesting things
> >I'd be looking for is what is implementaton specific
> >and what is standard Jabber.  This has been
> >exceedingly difficult to determine with just jabberd.
> >Something very different in implmentation could be
> >extremely useful...
> >
> >-iain
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Get personalized email addresses from Yahoo! Mail
> >http://personal.mail.yahoo.com/
> >_______________________________________________
> >jdev mailing list
> >jdev at jabber.org
> >http://mailman.jabber.org/listinfo/jdev
> >
>
>
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev