[Council] XEP-198 1.2 proxy vote

Dave Cridland dave.cridland at isode.com
Wed Mar 2 11:40:34 CST 2011

On Wed Mar  2 16:56:04 2011, Peter Saint-Andre wrote:
> On 3/2/11 9:45 AM, Nathan Fritz wrote:
> > In section 5 "In addition, this allows entities to establish
> > definitively which stanzas require resending and which do not,
> > eliminating replay issues." seems to be a bit over-promising. It  
> will,
> > in fact, not prevent all replay depending on the frequency of the  
> ack.
> > I suppose it is up for interpretation.
> >
> > Regardless, I believe that to be a very minor nitpick that does  
> not
> > affect the spec itself.
> I'm copying Dave Cridland, from whose patch that text emerged.
> In the Council chatroom after the meeting just now, I proposed the
> following text:
>    In addition, this enables entities to establish which stanzas
>    might need to be resent, thus reducing the likelihood that an
>    entity will send duplicate stanzas.
> I tend to agree with Nathan that "eliminate" is a bit strong here.  
> I'd
> rather underpromise and overdeliver than overpromise and  
> underdeliver.

The reason this text is there is to underline the inherent  
interrelatedness of acking and resumption, and in addition answer  
XEP-0198's critics who have claimed that it has replay issues.

It could be phrased better, but there's no over-promise there.

When resumption occurs, there is in effect a super-ack, after which  
both ends of the connection fully understand the state of the peer;  
that is, each end definitively knows which stanzas got through on the  
previous connection (and thus do not need resending) and which  
stanzas failed to get through (and therefore require resending).

In the absence of resumption, then a client can't tell if a stanza  
wasn't received, or whether the ack hadn't been sent yet - in this  
case unacknowledged stanzas need careful handling, and there is a  
window where there is a grey area, where clients are likely to  
retransmit on reconnect and potentially duplicate the stanzas. This  
grey area is resolved fully by resumption, and this is why resumption  
and acking are so firmly interlinked.

Now I do notice that the phrasing on this was really sloppy.

What about:

In addition, this protocol exchanges the sequence numbers of the last  
received stanzas on the previous connection, allowing entities to  
establish definitively which stanzas require retransmission and which  
do not, eliminating duplication through replay.


More information about the Council mailing list