[Standards] XEP-0301 0.5 comments [resetting versus randomizing 'seq' attribute]

Mark Rejhon markybox at gmail.com
Fri Jul 27 18:41:09 UTC 2012


On Fri, Jul 27, 2012 at 1:58 PM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> wrote:
>> Any other ideas / comments?    I think it's not a high priority during
>> LC, because I do say that any seq value can be used, just that
>> randomizing is the best practice here.   More field testing would seem
>> to be required.   It is worded in a way so that changing the standard
>> of resetting seq in the future, will not break compatibility.   So I
>> think the randomization can stay for LC -- unless there's a superior
>> idea (robust and simple for implementers)
>
> <GH>I suggest a random start seq with 30 bits  for each session..

[Comment & Edit Made]
Why specify exactly 30 bits?   It's not rigid like TCP/IP.  I'm trying
to provide only the bare minimum integrity check through seq,
(lower-layer features in a higher-layer), and only because it is
necessary to do so for a variety of reasons.  At least one XSF member
did make the criticism about this aspect, and I'd rather not
'over-strengthen' integrity checks far beyond what's "reasonably"
needed.

Even 30 bits still provides more than 23 years of incrementing room.
And 29-bits has more than 30 years of incrementing room.  Randomizing
to a value in the range of 1 million, is still sufficient, for
practical purposes, eliminate the occasional chance collisions that
occurs with using the same value (e.g. 0).

I already say "Senders MAY limit the size of the new starting seq
value, to keep <rtt/> compact while allowing plenty of incrementing
room without overflow." which already provides the umbrella for this.
It's generic enough, and suggests exactly the same thing.

I have made a minor change, for now:
c/MAY/SHOULD/ -- I've upgraded it to SHOULD.

Thanks,
Mark Rejhon



More information about the Standards mailing list