[Council] XEP-198 1.2 proxy vote
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
> > in fact, not prevent all replay depending on the frequency of the
> > I suppose it is up for interpretation.
> > Regardless, I believe that to be a very minor nitpick that does
> > 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.
> rather underpromise and overdeliver than overpromise and
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.
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