[Standards] Comment to rfc3921 pt 11.1 : handling of messages to ressources with identical priorities

Jérôme Carretero zougloub at gmail.com
Fri Aug 24 09:32:23 UTC 2007


On Fri, 24 Aug 2007 10:35:12 +0200
Robin Redeker <elmex at x-paste.de> wrote:

> On Thu, Aug 23, 2007 at 04:44:38PM -0600, Joe Hildebrand wrote:
> > 
> > On Aug 22, 2007, at 1:16 AM, Robin Redeker wrote:
> > >Will that algorithm be a 100% solution?
> > 
> > There is no such thing.  But it works really well in the real world,  
> > with real customers, in real deployments.  As well, please make sure  
> > that you read the thread that started with JD's priority discussion  
> > here: http://urltea.com/1av0; this is a problem more for client  
> > developers and sysadmins configuring branding files than for end-users.
> 
> This is a cornercase that must be handled in a sane way in servers IMO.
> That thread is interesting but doesn't solve the issue of two resources
> having the same priority. As far as I understood it was about priority
> dances in clients and such. You say sysadmins should configure it, are

For a normal use, the bases of the xmpp protocol are quite simple : "like e-mail", with presence, and a system of resources and priorities that seem to be designed for ultiple resources.
I don't know about JD, XEP, PEP, and all that, I'm supposed to be a regular user.

I just think that at the moment, when having that having >=2 resources with same priority, receiving a message behavior is quite vague.
And that broadcasting incoming messages to all of them is adding determinism in the protocol (*good*), and a FEATURE : it would provide an alternative way than MUCs to contact a bunch of people sharing an URI *that want to be contacted this way by setting the same (highest) priority*.

To me (not involved with xmpp development) who wanted this feature, it was obvious that broadcast happened when you set equal priorities (sounds too logical) but I was shocked that it wasn't handled this way.

I'll explain my use case :
 - IM is faster than mail in case of emergencies
 - Jabber is a clean IM so I'm using it
 - I'm having with my co-workers a MUC for internal conversation, and a shared JID for external contact (like contact at myorg.net ) ; there is contact at myorg.net/joe (3), contact at myorg.net/jeff (3), contact at myorg.net/otherguy (3) ... and I want that people talking to contact at myorg.net for an emergency can be served instantly.
So the guy PMs contact at myorg.net, and everybody receives it.
Then the one who wants to process the call can tell everybody on the MUC.

I can't do that at the moment and I don't think that it's so stupid.

So for me the main point is, what are apart the "sell 50 shares" syndrom, are the arguments AGAINST the "broadcast" rule which is in my opinion desirable because mainly deterministic and adding an interesting feature ?
This is the main question I would like people to focus on in this thread, and if you want I can open another on dynamic priorities or whatever (let's keep the protocol simple please :/ ).

> there configuration variables that enable 'sane' handling of same
> priority resources?
> 
> And yes, I'm sure that heuristics and weird algorithms usually work
> in the real world out there, but if they don't users probably won't
> know what to do or what it could be.

> I actually mostly care about sane and _clear_ and simple semantics for
> handling cornercases. It clearly defined what users, developers and
> admins can expect in such cases.

And until we find a reason against it I thing that broadcasting is the simplest way to handle this case :)

> 
> R


-- 
cJ



More information about the Standards mailing list