[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.
> > 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
 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