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

Rachel Blackman rcb at ceruleanstudios.com
Mon Apr 21 22:50:22 UTC 2003

>> David Waite has said resource matching (most likely) violates XMPP
>> specs.
> Philosophically: I mostly agree with David; resource matching by
> substring violates XMPP spec, resource matching by exact match does
> not however, as we are already doing it for IQ.
> Realistically: I see substring matching (particularly if we get full
> regexp) to be very useful in a large number of cases; especially in
> specifically designed corporate jabber applications.
> Personal preference is towards only exact matching though.

I'm inclined to agree with David and Casey in this; I think substring
matching violates XMPP, if not in specification at least in philosophy.

I do agree in some cases it could be useful, but I think it'd make more
sense to use a sort of hierarchical resource system; it would cover most
situations, and would avoid some of the really scary situations substring
matching could create.

As an example, consider 'work/desk' and 'work/lab' for a work resources,
'homework' for a resource I use from a mobile device while at a study hall,
and 'workshop' for a mobile device in my garage or basement where I might
be tinkering with hardware.  I realize this is a bit of a stretch, but bear
with me. ;)

'work' now will suffix-match 'homework', and prefix-match 'workshop',
creating issues.  This is most evident if I try to use the prefix-match to
make 'work' match either 'work/desk' or 'work/lab', and end up matching

If it's made hierarchical, then you could look for specific elements.  For
instance, 'work' would match 'sparks at jabber.org/work',
'sparks at jabber.org/work/desk' and 'sparks at jabber.org/work/lab' but not
'sparks at jabber.org/workshop'.  Since we /do/ have a resource element
delimiter, it seems to make sense to use it in a situation like this.  

However, I'm certainly willing to be proven wrong; does anyone have any
particular reason why elements would be insufficient compared to string

> Related to this, which servers should evaluate expire-on?  Should
> clients be able to query the path the message will take? This would
> enable the client to pick an appropriate timestamp for expiring a
> message in 5 minutes, which is easily in the threshhold of mis-set
> computer clocks, or clock-drift. (My personal feelings on this are ICK
> ICK ICK BAD, only the final server should check the rules).

Totally agree that it should be the final server as a default.  

However, maybe we should also define a method to specify that the /local/
server expire if it can't contact the remote server?  After all, the
delivery semantics stuff is partly inspired by a desire to work through the
message issues exposed by the IBB discussion, and if there's a (for
instance) five minute expiration on the packets, and the remote server goes
down and comes up six minutes later, the originating server should've
probably expired it by now. :)

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030421/afa03925/attachment.sig>

More information about the Standards mailing list