Subject: [xmpp] 3921bis: delivery of messages addressed to bare JIDs

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jan 2010 16:18:08 -0700

Currently some XMPP services broadcast messages addressed to a bare JID
instead of delivering those messages only to the highest-priority
resource(s). The highest-priority rule is a legacy of the original
jabberd 1.x codebase and I don't see a strong reason to forbid other
message delivery styles. Therefore I propose a change to Section 8.3.1.1
of 3921bis.

The relevant text in -03 reads:

   For a message stanza of type "chat" or "normal", the server SHOULD
   deliver the stanza to the highest-priority available resource.

(Followed by text about delivery ties.)

I propose the following text for -04:

   For a message stanza of type "chat" or "normal", the server MUST
   either (a) deliver the stanza to all available resources or (b)
   deliver the stanza to the highest-priority available resource.

(Again followed by text about delivery ties in case (b).)

Thoughts?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Roach <[email-masked]>
Date: Thu, 28 Jan 2010 17:27:05 -0600

> (Again followed by text about delivery ties in case (b).)

For what it's worth, I really like this change. Speaking merely as a 
user of XMPP (not an implementor), I have often wished it possible to 
configure XMPP servers to perform message broadcast instead of priority 
routing for messages sent to my bare JID. Initial message routing among 
the several devices I may be logged in on has been a constant thorn in 
my side.

/a

---

From: Jack Moffitt <[email-masked]>
Date: Thu, 28 Jan 2010 17:01:21 -0700

> message delivery styles. Therefore I propose a change to Section 8.3.1.1

Why not remove priorities altogether? Are they used for anything else
but this? This seems like a biggish change. Perhaps the thing to do is
just make delivering to all tied resources a SHOULD, which would fix
the current ambiguity.

jack.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 29 Jan 2010 00:04:12 +0000

> message delivery styles. Therefore I propose a change to Section  

I'd prefer to maintain it, but I would be happy if servers could  
choose to override a client's priority, perhaps making them all equal.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jan 2010 19:44:25 -0700

On 1/28/10 5:04 PM, Dave Cridland wrote:
> I'd prefer to maintain it, but I would be happy if servers could choose
> to override a client's priority, perhaps making them all equal.

That's effectively what I'm saying, and what existing services are doing.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jonathan Schleifer <[email-masked]>
Date: Fri, 29 Jan 2010 13:39:33 +0100

> (Again followed by text about delivery ties in case (b).)

Hm, this sounds to me like killing resources all together. Why not let  
the user decide? For example, if the user gives all resources the same  
priority, all resources get the message. If the user decides to use  
different priorities, only the one with the higehst gets it (if 2 are  
sharing the highest prio, both should get it).

I think priorities and resources are one of the killer features of  
XMPP and should not be removed or crippled.

--
Jonathan

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 29 Jan 2010 17:52:45 +0500

>> (Again followed by text about delivery ties in case (b).)
The proposed text seems to suggest delivering to all available resources is
recommended (it's the first option). Is that intentional?

I would have thought something like "SHOULD deliver the stanza to the
highest-priority available resource, but MAY deliver to all available
resources" would have done the trick.

>
> Hm, this sounds to me like killing resources all together. Why not let the
> user decide? For example, if the user gives all resources the same priority,
> all resources get the message. If the user decides to use different
> priorities, only the one with the higehst gets it (if 2 are sharing the
> highest prio, both should get it).
>
>
This doesn't kill resources, this just explicitly allows servers to be
configured such that priority doesn't affect message delivery.

--
Waqas Hussain

---

From: Jonathan Schleifer <[email-masked]>
Date: Fri, 29 Jan 2010 13:57:02 +0100

Am 29.01.2010 um 13:52 schrieb Waqas Hussain:

> The proposed text seems to suggest delivering to all available  
> resources is recommended (it's the first option). Is that intentional?

This is exactly why it sounded to me like an afford to kill priorities  
all together.

> This doesn't kill resources, this just explicitly allows servers to  
> be configured such that priority doesn't affect message delivery.

I'm not so sure whether this should be configurable by the server.  
This might confuse users which expect one but get the other. For  
example I know someone who was really pissed about how Google Talk  
handles priorities.

IMO, the only thing that would make sense is to make it user- 
configurable. And to have a default in the standard. Everything else  
is just confusing users.

--
Jonathan

---

From: Maciek Niedzielski <[email-masked]>
Date: Fri, 29 Jan 2010 14:33:08 +0100

(sorry for sending off-list first, I changed email clients)

On 2010-01-29 13:52, Waqas Hussain wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>     Hm, this sounds to me like killing resources all together. Why not
>     let the user decide? For example, if the user gives all resources
>     the same priority, all resources get the message. If the user
>     decides to use different priorities, only the one with the higehst
>     gets it (if 2 are sharing the highest prio, both should get it).

And then it kills resources for me if my server admin decides one day to
change the way it works.

-- 
Maciek
 xmpp:[email-masked]

---

From: Maciek Niedzielski <[email-masked]>
Date: Fri, 29 Jan 2010 14:33:55 +0100

> sharing the highest prio, both should get it).

And this already works in current draft, because section 8.3.1.1 says:

If there is not one highest-priority available resource but instead the
highest priority is asserted by two or more available resources, these
resources are said to form a "delivery tie". In the case of a delivery
tie, a server SHOULD deliver the message to all of the tied resources.

while old 11.1 said:

If two or more available resources have the same priority, the server
MAY use some other rule (e.g., most recent connect time, most recent
activity time, or highest availability as determined by some hierarchy
of <show/> values) to choose between them or MAY deliver the message to
all such resources.

So with current draft, user can decide if they want to get message
delivered to all resources (by setting same priority), or to only one
resource (by setting different priorities).

If most people think that delivering everywhere is a better default,
then recommend clients to use priority 0 / no priority by default.

> I think priorities and resources are one of the killer features of XMPP
> and should not be removed or crippled.

+1

-- 
Maciek
 xmpp:[email-masked]

---

From: Maciek Niedzielski <[email-masked]>
Date: Fri, 29 Jan 2010 14:39:05 +0100

On 2010-01-29 01:01, Jack Moffitt wrote:
> but this?

Negative priority has special meaning.

-- 
Maciek
 xmpp:[email-masked]

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 29 Jan 2010 18:53:42 +0500

> message delivery styles. Therefore I propose a change to Section 8.3.1.1
On further consideration, the proposed text is more restricting than the
existing text.

I don't see a strong reason to forbid other message delivery styles, but the
highest-priority rule is a SHOULD, not a MUST, so other message delivery
styles are not forbidden, just this one is recommended. The proposed change
seems to require broadcast (first) or priority based delivery (second),
which seems like the wrong thing to do. It's a "MUST", which does
effectively forbid any other message delivery styles except those two.

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Jan 2010 23:36:44 -0700

On 1/29/10 6:53 AM, Waqas Hussain wrote:
> On Fri, Jan 29, 2010 at 4:18 AM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I don't see a strong reason to forbid other message delivery styles, but
> the highest-priority rule is a SHOULD, not a MUST, so other message
> delivery styles are not forbidden, just this one is recommended. The
> proposed change seems to require broadcast (first) or priority based
> delivery (second), 

There is no order of preference here.

> which seems like the wrong thing to do. It's a
> "MUST", which does effectively forbid any other message delivery styles
> except those two.

What other styles do you have in mind?

I'm not opposed to allowing other styles (so make broadcast or
presence-based delivery SHOULD), but those are the only two styles I've
ever seen. And we definitely want to explicitly mention the broadcast style.

/psa

---

From: "Ben Schumacher" <[email-masked]>
Date: Fri, 29 Jan 2010 15:21:19 -0800

> XMPP and should not be removed or crippled.

Priorities and resource-based routing are killer features only if you 
happen to be a member of the relatively small XMPP developer community 
-- for IM users it's just confusing and unnecessary. They want to login 
a client and get instant messages.

Missing IMs because you accidentally left yourself logged in on another 
machine, or because Client X has different default priority settings 
than Client Y is inconvenient, annoying and prone to error. These is 
nothing in the wording change that's going to _force_ implementations 
into a different behavior, but with luck it'll encourage servers and 
clients to move towards more explicit solutions to choosing sessions for 
message delivery, i.e. privacy lists, SIFT and Mine-ing.

My opinion, anyhow.

Ben