[JDEV] 0.7 Proposed Protocol Changes

[neil whitaker]

Jeremie

You mention the server auto forwarding via a transport to other devices. Can
presence information be feed (from transports) to a central points for
determination of what to do. Is the server designed to handle determination
of best method of contactability. I leave my PC on all day (hence maybe
logged in) but I'm not always at mydesk but I have my mobile with me.(also
SMS enabled)  The client may notify of an instant contactability timeout
period .

Also given the above. I was taking nickname to be like  someone's "role" ie
work or home and hence different levels of contactability for each rather
than a contactability device / resource. There may be different rosters for
each of these roles.
I see this as important particularly in line with IMPP model and ubiquitous
IM. All of this requires serverside processing.

Regards Neil

> -----Original Message-----
> From: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org]On Behalf Of
> Jeremie
> Sent: Monday, 27 September 1999 16:46
> To: jdev at jabber.org
> Subject: [JDEV] 0.7 Proposed Protocol Changes
>
>
> Here are some changes I'd like to propose or bring up for
> discussion for
> 0.7.  Some are minor, and some major, but the essence of the
> changes are
> to "tidy" up a bit and streamline things for understanding and
> implementation of 0.7.
>
>
> Minor:
>
> => (already discussed) Additional message "types" where type
> is mostly for
> display: error, chat, groupchat.
> => Connections (client to server and server to server) are XML Streams
> (see protocol section at http://docs.jabber.org/).
>
>
> Major:
>
> Rework "presence" model (renaming "status" to "presence").  See the
> updated presence doc at http://docs.jabber.org/ in the
> protocol section.
> It doesn't break the old model, just builds on it in a slightly more
> generic way.
>
> Rename "nick" to "resource" and generalizing the use of
> resources.  Each
> user can have multiple generic "resources" underneath them, a 3-tuple
> system: server>user>resource.
>
> --> Session resources: Each connection from a client becomes a session
> resource, identical to the nickname setup in 0.6.
>
> --> Remote resources: A user can tell a server to create a "remote"
> resource.  The server would map/proxy this new resource to a remote
> address and handle forwarding traffic to/from it.  For
> instance, there is
> a pager transport and any user can create a "my pager"
> resource that maps
> to uin1234 at pager.jabber.org.
>
> Start utilizing Info/Query(IQ) as a fundamental part of the
> system. These
> would replace the existing <login> and <roster> packets.
>
> --> Query the server to authenticate: extensible for future
> uses, returns
> receipt of success or failure. Example use of IQ to
> authenticate with the
> server and create a session resource:
>   <iq>
>     <target>server</target>
>     <type>auth</type>
>     <set><user>jeremie</user><pass>foobar</pass><res>Jer</res></set>
>   </iq>
>
> --> Roster queries: Use IQ to fetch and manage the roster
> stored on the
> server.  Example, client asking server for a group:
>   <iq>
>     <target>user</target>
>     <type>roster</type>
>     <query><group name="Work Buddies"/></query>
>   </iq>
> Response:
>   <iq>
>     <type>roster</type>
>     <result>
>       <group name="Work Buddies"><user
> name="Jon">jjames at isp.net</user></group>
>     </result>
>   </iq>
>
>
> In the end, we have 3 consistent types of data everywhere in Jabber:
> Messages, Presence, and Info/Query, all fundamentally
> extensible and have
> clearly different purposes and modes of operation.
>
> Much of this has been making it's way into the draft documentation at
> docs.jabber.org.  Most of the docs are incomplete yet, but
> please take a
> look at what's there and feed comments/suggestions back to
> docs at jabber.org.
>
> Jer
>
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>