[Standards-JIG] RE: Standards-JIG Digest, Vol 5, Issue 29
jean-louis.seguineau at antepo.com
Wed Jun 30 10:04:57 UTC 2004
IMHO I believe the issue here is to make XMPP a 'reliable' protocol. We are
facing entrenched players (IBM, TIBCO, etc...) that are playing the '...
XMPP is not and industrial grade reliable protocol compared to (insert some
well known brand here)' game.
There have been separate attempts at bringing some kind of control to the
way stanzas can be send to multiple recipients (JEP33) can be acted upon
(JEP79) and how the can be augmented with metadata (JEP131). All this effort
is going in the right direction, but seen from the outside, does not present
a united front against the incumbents.
I have the feeling that XMPP would gain a lot if these were regrouped under
a larger umbrella geared to make XMPP as 'reliable' as the market
incumbents. I also believe while reading the thread about Pub/Sub that this
is also a must have.
Date: Mon, 28 Jun 2004 09:39:17 -0600
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: [Standards-JIG] Re: AMP & deliver condition
To: standards-jig at jabber.org
Message-ID: <pan.2004.06.28.15.39.16.384934 at jabber.org>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, 04 Jun 2004 18:04:25 -0700, Justin Karneges wrote:
> In the past, I discussed the Jabber "black hole" problem:
> It appears as though AMP might be able to solve some of the issues.
> 1) Can the deliver condition be used so that a client knows his sent
> message at least reached his own server (first hop) ?
> 2) Can the deliver condition be used by a server to a client, so that the
> last server in the chain knows if his client received it?
> 3) Can the deliver condition be used for full end-to-end acking, as a
> replacement for JEP-0022?
Exactly what problem are we trying to solve here? Assurance that a message
was (1) received by a client or application, (2) displayed to a user,
or (3) actually read by a user or processed by an application? To me, it
seems that *perhaps* we're trying to use (1) or (2) as a proxy for (3).
But my client could affirm that (1) and (2) happened, yet I still never
read the message because the BSOD intervened or somesuch.
More information about the Standards