[standards-jig] UPDATED: Message Delivery Semantics (JEP-0079)
crabbkw at nafai.dyndns.org
Mon Apr 21 22:07:18 UTC 2003
On Mon, Apr 21, 2003 at 11:17:21AM -0700, Matthew A. Miller wrote:
> CONTROVERSY #1: "match-resource"
> I've proposed:
> * changing "subset" to "prefix-subset"
> * changing "superset" to "prefix-superset"
> * adding "suffix-subset"
> * adding "suffix-superset"
> Tijl has asked for:
> * adding "substring-subset"
> * adding "substring-superset"
> 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.
> CONTROVERSY #2: "disco"
> I've proposed the following for reporting support for a specific
> <feature var='http://jabber.org/protcol/msg-delivery?condition=<new
> I've proposed the following for reporting support for a specific action:
> <feature var='http://jabber.org/protcol/msg-delivery?action=<new
> Announcing the "bare" namespace implies support for those conditions and
> actions defined in the JEP.
> CONTROVERSY #3: "expiration times"
> Better language needs to be applied for this, in the "Implementation
> Notes" section or the "'expire-in' Condition" section. What I'd like to
> say is something like "servers start the expiration counter when a delay
> is anticipated, such as moving the message to offline storage" or some
> such. I'm not sure if this is still not explicit enough for everyone's
This helps, but it also needs to be made clear which server along the path we're talking about.
Client --Message--> Server1 --Message--> Server2 --Message--> Recipient
What happens if Server1 cannot contact Server2 (I haven't read the
IETF docs to know what is supposed to happen currently), does Server1
bounce the message, does it spool it for delivery later? Does this
start the clock ticking?
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards