[Standards-JIG] proto-JEP: Flagging the Primary Resource

Peter Saint-Andre stpeter at jabber.org
Thu Sep 29 22:32:46 UTC 2005

Ian Paterson wrote:

> I was just discussing the possibility of doing without the XML of a
> primary extension and documenting a simple convention instead:
> I suggested:
>>"If two resources have the same priority then subscribers 
>>SHOULD consider the primary resource to be the one that they 
>>last received a <presence/> stanza from."

That doesn't solve the problem. What if the resource from which you last 
received presence sent "dnd" and the other one sent "chat"? What if the 
resource from which you last received presence is connected to the 
server via an intermittent WAP connection (known to the server but not 
to the subscribers) and the server never considers such a connection to 
be primary because of the connection type? The problem is that a simple 
convention won't do because determining the most available / primary 
resource is not always simple, and we prefer to leave that complexity to 
the server rather than foisting it on the client (even if the client had 
all the appropriate information, which in this case it would not).

>>Another advantage of this approach (in addition to not 
>>requiring new <presence/> content) is that whenever the primary 
>>resource changes (to another resource with the same priority) 
>>the server only needs to send a single <presence/> stanza. 
>>(The current proposal requires two stanzas to be sent, one 
>>with and one without the <primary/> element.) 

This does not always require two pushes. See business rule 7:


If the primary resource changes, a server MUST push presence (including 
the primary resource flag) for the new primary resource. If the change 
in primary resource occurs because of a presence broadcast from the 
current primary resource, the server MUST push presence from the current 
primary resource (without the primary resource flag) before pushing 
presence from the new primary resource (including the primary resource 


If the change was caused by a presence broadcast from the non-primary 
resource, only a push from the new primary resource is necessary (not 
the old primary resource).


Peter Saint-Andre
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3511 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20050929/3265dec1/attachment.bin>

More information about the Standards mailing list