[standards-jig] UPDATED: Message Delivery Semantics (JEP-0079)
rcb at ceruleanstudios.com
Mon Apr 21 22:50:22 UTC 2003
>> David Waite has said resource matching (most likely) violates XMPP
> 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
Size: 187 bytes
Desc: not available
More information about the Standards