[Council] XEP-198 1.2 proxy vote

Peter Saint-Andre stpeter at stpeter.im
Wed Mar 2 12:27:19 CST 2011

On 3/2/11 10:40 AM, Dave Cridland wrote:
> 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.

Yes, I think that's much better.

What do the Council members think? Dave and I are just lowly spec
authors. ;-)


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/council/attachments/20110302/f8641b92/attachment-0001.bin>

More information about the Council mailing list