Subject: [xmpp] 3920bis: reliability

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Sep 2009 12:41:32 -0600

I propose adding the following informational (and self-explanatory)
paragraph to the section on TCP Binding in 3920bis...

4.6.  Reliability

   The use of long-lived TCP connections in XMPP implies that the
   sending of XML stanzas over XML streams can be unreliable, since the
   parties to a long-lived TCP connection might not discover a
   connectivity disruption in a timely manner.  At the XMPP application
   layer, long connectivity disruptions can result in undelivered
   stanzas.  Although the core XMPP technology defined in this
   specification does not contain features to overcome this lack of
   reliability, an XMPP extension for doing so is defined in [XEP-0198].

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 10 Sep 2009 21:23:55 +0200

>    reliability, an XMPP extension for doing so is defined in [XEP-0198].

This sounds like a good idea to me.
I was wondering whether it might be a good idea to mention XEP-0184 too
though.
Possibly in a different context, maybe even in 3921bis.
It seems much more useful for the normal Instant Messaging case as long
as XEP-0198 is not widely deployed IMHO. OTOH not mentioning 184 might
be a way to increase 198 deployment...

---

From: Justin Karneges <[email-masked]>
Date: Thu, 10 Sep 2009 13:11:10 -0700

> be a way to increase 198 deployment...

My (biased) opinion is that XEP-0184 should certainly not be suggested as a 
solution to basic delivery problems.  Let's encourage fixing that problem in 
the right place (XEP-0198, at the xmpp-core level).

XEP-0184 could be mentioned as a solution to certain special needs, such as 
the need to know 'when' (as opposed to 'if') a message was received by the 
final endpoint, or the need to send a message of high importance when the 
delivery capacity of the hops is not known or cannot be trusted.  But please, 
I don't think people should be implementing 184 to get around wi-fi drops, 
and we should be careful not to encourage or promote this.

-Justin

---

From: Jiří Zárevúcky <[email-masked]>
Date: Thu, 10 Sep 2009 22:31:24 +0200

>     reliability, an XMPP extension for doing so is defined in [XEP-0198].

Such note is a good idea, but I wouldn't address a specific XEP in an 
RFC document. Although unlikely, these can be obsoleted and replaced 
with new ones, while RFC is kind of long-lived and difficult to update. 
Also, there are more extensions that address reliability. I'd suggest 
changing the last sentence to something like this:

Although the core XMPP technology defined in this specification does not 
contain features to overcome this lack of reliability, XMPP extensions 
exist to rectify this problem (for example [XEP-0198]).

---

From: Fabio Forno <[email-masked]>
Date: Thu, 10 Sep 2009 22:33:53 +0200

> and we should be careful not to encourage or promote this.

I'm just adding my less biased POW: at the beginning I wasn't
convinced of a XEP-0184 like approach, since it requires cooperation
at the stream and session level, with some obvious drawbacks like a
messier server implementation (session management must be reworked in
order to keep alive dropped connections for a while, we must count and
aknowledge packets), resume still requires a long handshake in the
stream initialization (see the other thread about fast stream resume).
In few words: the approach sounded reasonable, but unlikely to be
implemented soon for these complications. I therefore was more keen to
follow a transport based approach (BOSH like solutions have all we
need for recovering from lost connections). There is only a problem:
it is easy to implement, but if we separate session recovery from
session management (as it happens in BOSH) it is likely to end in
situations in which your peers don't know you are offline, you won't
recover soon, and they send packets to a sink eating out packets  (the
BOSH like client connector, or the transport). Same considerations
apply to a more sophisticated SCTP binding: when the connection is
temporary dropped packets run the risk to be lost in the transport, if
the client isn't able to resume the session. Perhaps a trasnport based
solution, like a SCTP binding, has still benefits, since it minimizes
the need to restart the stream, but XEP-0198 at the top of it remains
essential for complete reliability.

bye

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [email-masked]

---

From: Pedro Melo <[email-masked]>
Date: Thu, 10 Sep 2009 21:41:11 +0100

>   reliability, an XMPP extension for doing so is defined in  

I agree with general idea, but I do wonder if we should include XEP  
numbers in a RFC.

My concern is that we might want to use a new number for a new  
protocol and the RFC would be out-of-date.

Maybe we should a registry for best current practices, that we could  
update without having to change the RFC.

Just a though.

Best regards,

---

From: Florian Zeitz <[email-masked]>
Date: Fri, 11 Sep 2009 00:33:19 +0200

> and we should be careful not to encourage or promote this.
I definitely agree (also replying to what Peter Saint-Andre send to the
standards list (by accident I assume)) that this has a different scope
and would (if at all) be included in 3921bis with a different use case
attached to it, but currently XEP-0184 is much more useful for knowing
'if' a message has been delivered.
It is implemented in Miranda, Gajim and Pidgin right now (AFAIK) and it
really tells you if the message got to the other end. XEP-0198 can only
tell you if a stanza made the hop (if I understand it correctly) which
means I can get an ACK from my server, but the message gets lost after
that (e.g. my friend's wi-fi drops) and I'll never know (the assumption
here is that only my server and client support XEP-0198 in that chain).

- - Florian

---

From: Justin Karneges <[email-masked]>
Date: Thu, 10 Sep 2009 17:40:49 -0700

On Thursday 10 September 2009 15:33:19 Florian Zeitz wrote:
> Justin Karneges wrote:
> > XEP-0184 could be mentioned as a solution to certain special needs, such
> > as the need to know 'when' (as opposed to 'if') a message was received by
> > the final endpoint, or the need to send a message of high importance when
> > the delivery capacity of the hops is not known or cannot be trusted.  But
> > please, I don't think people should be implementing 184 to get around
> > wi-fi drops, and we should be careful not to encourage or promote this.
> >
> > -Justin
>

Yes, XEP-0184 is a more practical solution today, especially if clients are 
already using it.  Unfortunately it's just such a bad one.  Imagine if SMTP 
were unreliable and we all had to use end-to-end email message receipts in 
order to not lose mail.  I don't mind 184 as an interim solution, but I hope 
all this client support of it doesn't cause people to be lazy about 198.  
That would just be really sad.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Sep 2009 19:19:55 -0600

> and we should be careful not to encourage or promote this.

Agreed!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 Sep 2009 19:23:12 -0600

On 9/10/09 2:41 PM, Pedro Melo wrote:
>> sending of XML stanzas over XML streams can be unreliable, since
>> the parties to a long-lived TCP connection might not discover a 
>> connectivity disruption in a timely manner.  At the XMPP
>> application layer, long connectivity disruptions can result in
>> undelivered stanzas.  Although the core XMPP technology defined in
>> this specification does not contain features to overcome this lack
>> of reliability, an XMPP extension for doing so is defined in
>> [XEP-0198].
> 

If we don't provide specific references, how will developers learn about
things like the stream management protocol? As long as the URLs are
stable, we can always publish pointers from something like XEP-0198 to
whatever the replacement protocol is (the IETF doesn't have that kind of
flexibility because they cannot change an RFC once it has been
published, whereas the XSF can modify published XEPs in place).

> protocol and the RFC would be out-of-date.

So we reference the new from the old, which gets superseded or
obsoleted. No big deal.

> update without having to change the RFC.

Overkill, IMHO.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Sep 2009 12:21:36 +0100

On Thu Sep 10 21:31:24 2009, Jiří Zárevúcky wrote:
>> application
> Such note is a good idea, but I wouldn't address a specific XEP in  
> an RFC document

I would - even though a XEP can change, it's entirely reasonable to  
reference them, as the reference is equivalent to the equally valid  
STD reference. It's referencing a technology, not the specific  
version of it.

> Although the core XMPP technology defined in this specification  
> does not contain features to overcome this lack of reliability,  
> XMPP extensions exist to rectify this problem (for example  
> [XEP-0198]).

This is reasonable too, and reads more informatively - I don't think  
we need a normative reference here. (Indeed, we shouldn't have any  
normative references from the core XMPP RFC to any XMPP Extension  
Proposals...)

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Sep 2009 12:21:42 +0100

On Thu Sep 10 21:41:11 2009, Pedro Melo wrote:
>> the

A completely new extension for achieving the same goals might have a  
new XEP, but we can place a pointer from XEP-0198 to it, if we feel  
that's appropriate. It's far more flexible than referencing an RFC,  
where even an update will cause the reference to be outdated.

Dave.

---

From: Remko Tronçon <[email-masked]>
Date: Fri, 11 Sep 2009 14:42:47 +0200

>> contain features to overcome this lack of reliability, XMPP extensions exist
>> to rectify this problem (for example [XEP-0198]).
>
> This is reasonable too, and reads more informatively - I don't think we need
> a normative reference here. (Indeed, we shouldn't have any normative
> references from the core XMPP RFC to any XMPP Extension Proposals...)

 I think that's what Pedro meant by 'not referencing XEPs'. The
software engineer in me also feels uncomfortable with a direct
dependency on XEPs from the RFC, so I prefer this version (with or
without the explicit XEP-198 reference)

cheers,
Remko

---

From: Fabio Forno <[email-masked]>
Date: Fri, 11 Sep 2009 14:50:48 +0200

> references from the core XMPP RFC to any XMPP Extension Proposals...)

As I've said I prefer this formulation since it just says:
- we are aware of the problem
- we intentionally left out the solution
- solutions exist and a possible one is xep-198

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Sep 2009 11:46:08 -0600

> without the explicit XEP-198 reference)

This is not a dependency, it is an informational pointer. How are people
supposed to find out that XEP-0198 is the place to look (for now)? I
like this text:

   Although the core XMPP technology defined in this
   specification does not contain features to overcome this lack of
   reliability, there exist XMPP extensions for doing so (e.g.,
   [XEP-0198]).

3920bis also contains informational references to XEPs 1, 16, 30, 45,
60, 71, 77, 124, 156, 165, 174, 175, 178, 191, 199, 205, 206, 220, and
271. All of those *might* change at some point in the future. IMHO that
doesn't mean it's a bad idea to reference them informationally. In fact
I think it's a bad idea to shy away from referencing specifications that
might prove helpful to developers when they read 3920bis for the next X
years (until we publish 3920ter, that is ;).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Kevin Smith <[email-masked]>
Date: Fri, 11 Sep 2009 22:20:20 +0100

Sorry, I jumped into this thread far too late to influence it. I'd
prefer the informational reference to '198' rather than to 'e.g. 198',
but I'm happy with the text I just saw get checked in.

/K