[Standards] XEP-0301 0.5 comments [resetting versus randomizing 'seq' attribute]
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"
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.
More information about the Standards