On Mon, Oct 28, 2013 at 5:54 PM, Peter Waher <peter.wa...@clayster.com>wrote:
> > How do we define "important"? There's the challenge. :-) > > True. But not only "how", but also "where" it is defined. The received can > define what it wants, the xmpp server can define what to forward under > certain conditions, and the sender can define the priority of a message. > > Many network protocols have solved this by letting the sender determine a > priority or QoS level for each message. The sender normally knows if > something is "important" (for instance an alarm, or a call or control > command) or "normal" (informational message) or "less important" (recurrent > status update), for instance, and so no complex logic for this is required. > > An objection could be made that an application could then choose to send > all messages as "important" messages, overriding any throttling logic. But > in practice, this would be counterproductive since users would quickly find > out what service/device/address works badly and stop using it or > unfriending misbehaving contacts. > > The above solution could then hypothetically be complemented by a simple > subscription mechanism on the client, or an automatic rule on the xmpp > server determining what messages to forward and when, and perhaps also with > bandwidth limits on different types of messages, and if messages not being > forwarded should be treated as offline messages or thrown away (based on > message priority). > I think this is XEP-0334, Messaging Processing Hints. Or ought to be, at any rate.
