[standards-jig] NEW: Message Delivery Semantics (JEP-0079)
Matthew A. Miller
linuxwolf at outer-planes.no-ip.com
Thu Apr 17 16:35:08 UTC 2003
On Wed, 2003-04-16 at 17:55, David Waite wrote:
> A few brief comments:
> - The resource is defined in the XMPP spec as being opaque - I should
> not depend on a prefix/suffix actually meaning anything, or structured
> in any style. (For an example in terms of another protocol: I shouldn't
> assume http://example.com/cgi-bin/ refers to the parent document of
The intention of this JEP was not to add meaning to the resource, but to
perform substring matches against the resource. Would adding additional
rules, specifically "suffix-based" and "anyfix-based", help prevent this
So far, there does not seem to be objections by anyone else, but then
only three people have voiced their opinions.
> - Section 3 (Implementation Notes) is very odd; a client cannot perform
> any of the routing semantics, and the expiry semantics are not defined
> in application terms/client UI terms. Does it exire if not delivered by
> X time or if not displayed/processed by X time?
The intention here was that clients MAY wish to extend the behavior into
their user experience, by dropping/failing the message if it had not
been displayed within the expiration timeframe. For servers (that
understand this JEP), this values always denotes delivery time.
I can make that section clearer on this point, or remove it altogether.
> - Do you see additional rules being defined later? Perhaps the rules
> supported should be reported in a disco query response? A client would
> need to do a disco query of the remote server before requesting any of
> these delivery semantics anyways.
At this point in time, I don't see more rules, but others do. Making
the specific rules supported somehow discoverable would be nice, but I'm
not sure how exactly to incorporate that into disco.
I suppose one method would be to have a <feature/> for each condition
and action, in the following general forms?
actions == "http://jabber.org/protocol/msg-delivery?action=<action
The presence of the feature "http://jabber.org/protocol/msg-delivery"
would imply support for only those conditions and actions defined in
> - Would a client ever want to request certain rules be used when
> responding to a message, or within a thread?
The semantics are only intended for the sender to make. Is there a
use-case that the recipient would want senders to use certain semantics?
> - Scoping larger than a single message (such as a whole thread) opens a
> whole can of worms. Does a by-thread scope apply to all resources or
> just the current one? How does the server prevent a user from doing a
> DoS by adding a few million thread IDs and eating up all memory? When
> does the thread scope end (when the local user goes offline? when the
> remote user goes offline?) I'm not saying whether the bandwidth it
> would save is worth the the complexity in the proposal and
> implementations or not, just that it needs to be taken into account :-)
The more I think of thread-level scope, the more I can see problems.
These semantics need to be distributed to all routes on the chain
between any two entities, and can have a larger scope of problems.
While today that would mean at most two servers, the reduced stanza size
this provides as a convenience, it creates a different, widespread
Thanks for convincing me that thread-level scope is bad (-:
> -David Waite
> Peter Saint-Andre wrote:
> >Matthew Miller has submitted a JEP for message delivery semantics. This
> >JEP addresses the recent discussions on this list. You can find it here:
> Standards-JIG mailing list
> Standards-JIG at jabber.org
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