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

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Mon Apr 21 23:27:39 UTC 2003


Comments inline...

On Mon, 2003-04-21 at 15:50, Rachel Blackman wrote:
> >> 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
> 'workshop'.  
> 
> 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
> matching?
> 

At this point, I'm thinking it best to just drop all condition values
but "exact", and let a later proposal come up with a better/fuller
mechanism.  The only thing currently required by other JEPs is "exact"
vs. "any" matching, which the JEP (minus "superset" and "subset")
fulfills.

> > 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. :)

In every case, the burden is on at least the recipient's server.  Some
additional burdens that MAY be applied follow. 

When it comes to the expiry, I was seriously considering this to be
validated by at least the "edge" servers, both the sender's and
recipient's. This seems to me to be acceptable and desirable behavior,
at least for now, while we really only have two servers involved.  For
one, it cuts down on the network traffic (although this may not be a
real problem), and secondly, it makes the overall system more responsive
to each individual.

In the specific case of "expire-in", the counter is intended to start
when the message cannot be immediately delivered (currently, that seems
to mean when the message would go to temp storage), and end either when
it hits 0 or when the message is sent, whichever is first (obviously).

That was my thoughts on it, at least.  If the above sounds acceptable,
I'll add it to at least the "Implementation Notes".  If not, well, let's
discuss further! (-:


-- 

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