[standards-jig] NEW: Message Delivery Semantics (JEP-0079)

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Wed Apr 16 15:53:33 UTC 2003

On Tue, 2003-04-15 at 21:09, Robert Norris wrote:
> > If you can think of a need for prefixes it's not that easy to think of 
> > one for suffixes or substrings either. Or at least, easyer than 
> > thinking of uses for subset matching ;) 
> Fair enough. Its trivial to implement either way :)

I had not fully considered the ramifications of prefixes and suffixes,
being biased by the jabberd 1.4.2 implementation's handling (-:

If we are to consider prefixes and suffixes (which, now thinking on it,
should be done), we need to consider in what "direction".  The current
"match-resource" value flags make this distinction, and I still feel it
is an important one.  If we are to take into consideration the concepts
of prefix/suffix, I would see a total of five values:

*  "prefix-subset" would be the existing "subset" definition.
*  "prefix-superset" would be the existing "superset" definition.
*  "suffix-subset" would be "Destination resource exactly matches, or is
a suffix of the specified resource" (e.g. "home/laptop" matches "laptop"
and "top", but not "home/desktop" or "work/laptop").
*  "suffix-superset" would be "Destination resource exactly matches, or
is suffixed by the specified resource" (e.g. "laptop" matches
"home/laptop" and "work/laptop", but not "home/desktop" or
*  "exact" would remain as-is.

I am open other suggestions, though.[1]

> > That does bring up a question though. If a presence with lower priority 
> > matches my sub-/super-set exactly, and one with higher priority 
> > partially, it still goes to the highest priority resource? 
> I would say that exact matches trump partial matches. But this sort of
> thing really should go into this JEP.

It's there, but maybe not explicit enough (see "exactly matches, or is
..." in section 7.1.3, table 3, rows 2 and 3) (-:

> Alternatively, we could just say that if a packet arrives with delivery
> semantics on it, then those semantics are processed in isolation. Only
> when there are no matching sessions do the "traditional" (XMPP-IM) rules
> come into effect.

That's the intention:  If none of the <rule/>s apply, the existing
semantics are used.  I can add a section about this to the
"Implementation" section.

> Rob.

[1] I had deliberately left out "regex", as I felt this would overly
complicate and burden implementations.  It's starting to sound like this
*might* be worth reconsidering, though...

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)

More information about the Standards mailing list