[standards-jig] Presence priority finetuning

Sami Haahtinen ressu at ressukka.net
Tue Jul 2 14:59:47 UTC 2002

On Mon, Jul 01, 2002 at 04:07:02PM -0400, Julian Missig wrote:
> On Mon, 2002-07-01 at 15:57, Sami Haahtinen wrote:
> > On Mon, Jul 01, 2002 at 03:45:20PM -0400, Julian Missig wrote:
> > > On Mon, 2002-07-01 at 15:41, Sami Haahtinen wrote:
> > > > before the server sends the offline messages, it needs to know wether
> > > > the client will accept them, if you think about it this way, the client
> > > > has to negotiate the accepted messages before sending it's first
> > > > <presence/> to make sure that the server only sends the messages that
> > > > this client accepts certain types of messages.
> > > 
> > > ... so?
> > > There's nothing saying a server can't browse you right after you
> > > connect, before you even send a presence packet. Or the server could
> > > wait on sending the messages until after it attempts to browse you.
> > 
> > this brings us to yet another problem.. how long should the server wait
> > for a reply from the client, atleast a quick check with gabber revealed
> > what i was expecting.. nothing is returned when a query is sent to the
> > client which it does not understand.. (and to me, Gabber behaved as
> > expected)
> > 
> > how long should the server wait for a valid reply before dumping the
> > data according to default rules?
> Well, technically clients should be returning a Not Supported iq if they
> don't support a particular namespace. We could always move to enforce
> this. Or the browse could be before the <presence/> is sent, like I
> said. So if a client sends presence, it is assumed it doesn't support
> browse unless it says otherwise.

when done this way, how long should the client wait for a valid
request? I'm guessing now, but there must still be 1.2 (or earlier)
servers out there, this will be the casea long time after the first
release of a server that supports this. how would the client know that
tis server actually doesn't support browse/disco and will never send the

> The true solution is to get browse/disco standardized (and pick one over
> the other) and required...

also, this morning while i was in the shower (what a excellent place to
think =) i came to think that disco or browse wouldn't actually work too
well with this.. browse works with namespaces and disco works with
aliases, we are back with the original problem where the server had to
know all possible packets that can be passed through it..

i came to think of something like this (adapt this to some JEP if you
find one)

Client connects and sends this to the server to check that it supports
message rules..

<iq id='r1' to='server' type='get'>
  <query xmlns='jabber:iq:rules'/>

ofcourse, the server would reply with either an error or with the
current rulesets.

<iq id='r1' to='user at server/resource' type='result'>
  <query xmlns='jabber:iq:rules'>

next the client tells the server that it wants (all) headlines and chats
if there are no clients with a higher priority , but no normal messages
and the set queries with the FOOBAR namespace.

<iq id='r2' to='server' type='set>
  <query xmlns='jabber:iq:rules'>
    <message type='headline' priority='inf'/>
    <message type='chat' priority='5'/>
    <message type='normal' prority='none'/>
      <query xmlns='FOOBAR' priority='5'/>
    <default priority='1'/>

and the server would ofcourse reply to that..

<iq id='r2' to='user at server/resource' type='result'/>
(is there a need to repeat the query?)

after this is done the client will send the <presence/>, This way the
server does not have to know all data that is passed through the server
and the client would be left with full control how to delegate the


			  -< Sami Haahtinen >-
      -[ Notify immediately if you do not receive this message ]-
	-< 2209 3C53 D0FB 041C F7B1  F908 A9B6 F730 B83D 761C >-

More information about the Standards mailing list