Subject: Re: msg-id

From: John Stanley <[email-masked]>
Date: Wed, 8 Dec 2004 10:28:57 -0800 (PST)

Seth Breidbart <sethb@xxxxxxxxx>:

>> It does not mean it cannot happen tomorrow or the day after. It does
>> not mean it will only happen in one thousand years.

>I understand that.  It means it will happen, on average, one thousand
>time in one million years.

No, it does not. It means that has an X percent chance of happening FOR
EVERY ID GENERATED, which, assuming a rate of Y ids generated per thousand
years, multiplies out to 1. It can happen one thousand times in the next
two days, for all you know.

What is important is that the ERROR is known and can be avoided completely
by fixing it now.

>> Then you would know that "once per thousand years" is 1) a pretty 
>> meaningless statistic

>It has a clear meaning (providing the details are spelled out: how
>many users posting how often, etc.)

You would have to know how many users there will be TOMORROW and every day 
for the next thousand years, AND how many articles they will be posting 
tomorrow and every day after that for the next thousand years. Since that 
cannot be known, it is a meaningless statistic. Now, "X % chance" has some 
meaning. "Once per thousand years" does not.

>It's a flawed implementation.

Sorry, I guess for the truly pedantic I should have said it is not in any 
way a correct implementation of "MUST NOT". Yes, it is flawed. It can be 
fixed. We ought not to support flawed implementations.

>So is any other, since whatever method
>you use might generate a Message-ID that was previously used by a
>previous owner of the domain (or might sometime in the future be used
>by a subsequent owner).

Hmmm. Let's see. I use "sequence number dot epoch time dot process id dot
month dot day dot year @ domain". Since THIS epoch time will never
reoccur, it cannot be the same as what any other owner of my domain would
use. Guaranteed unique.

>>>They both cause the same violation of the same MUST.
>> No, they don't,

>They both cause a non-unique Message-ID.  

Your wife has a baby. It could either be caused by YOUR romantic actions, 
or the romantic actions of the milkman. There is no difference because the 
result was the same.

The breakdown in the piece of hardware causes a mangled or non-existant 
message id. How can a broken-down computer generate anything? A flawed 
implementation generates a valid-looking but non-unique message id. 
There's a significant difference between the two.

>> and even were that true, they are still very different things.

>I didn't say they were the same thing, I said they had the same
>effect.

No, you said they caused the SAME violation of the same MUST. Even were
that true, the two causes are very different. "We shouldn't require
adherance to a MUST because something else might break and violate the
MUST" is just silly.

>You don't think ISPs will know what software they're running?  Maybe
>you should avoid such ISPs.  I do.

I don't think many ISPs know what software their outsourced news servers 
run.

>> You are choosing to bother by participating in this discussion. Make up 
>> your mind.

>I am not at all bothered by the expected once in the next thousand
>years Message-ID collision.

I know. Your error.

<thorfinn@xxxxxxxxxxxxxx>:

>> The "error" is not whether you think that is "good enough", but on the
>> meaning of "once per thousand years". It does not mean it cannot happen 
>> tomorrow or the day after. It does not mean it will only happen in
>> one thousand years.

>You seem to not get it.

Casinos make millions off of people like you. "I'll bet '20' on the
roulette wheel because it hasn't shown up for a long time and it must show
up once every thirty-something spins." "I'll not bet '20' on the next spin
because it hit this time, and it cannot show up for another thirty spins."

>> Then you would know that "once per thousand years" is 1) a pretty 
>> meaningless statistic

>Err, no, it's not meaningless.  It means that it's an extremely low
>probability event.  

No, actually it doesn't. It someone tosses one coin per thousand years and 
you say it has a once per thousand year chance of coming up heads, you've
just said it is a certainty to come up heads.

>> and 2) not in any way an implementation of "MUST 
>> NOT".

>"The computer crashes" isn't an implementation of MUST NOT, either.

Ah, yes, this old "we cannot specify MUST because a computer somewhere 
might crash and violate it anyway."

Hey, I know. Let's stop mandating seat belt use, because you know, a 16 
ton weight might fall on the car and you'd be dead anyway!

>Or, how about the probability that a meteor will land on your head? 

And I thought MY example was being ridiculous. Ok, you win. Remove any 
mention that the message id MUST be unique, obviously a meteor might fall 
on my head and cause me to create one that is not, and it is more 
important that the message get posted than the system be able to prevent 
duplicates.

---

From: Seth Breidbart <[email-masked]>
Date: Thu, 9 Dec 2004 14:36:24 -0500 (EST)

> years, multiplies out to 1.

Where X varies, because the chance of collision is different each time
a new ID is generated.

> What is important is that the ERROR is known and can be avoided completely

No, it can't be avoided completely.

> reoccur, it cannot be the same as what any other owner of my domain would

Except that another owner of the domain (or another piece of client
software in use in that domain) used (or will use) "sequence number
dot process id dot epoch time dot day dot month dot year @ domain",
and gets his pids randomly from 32-bit space (to avoid potential
attacks based on known-pids).  Oops.

> or the romantic actions of the milkman. There is no difference because the 

Genetic testing shows that the results were not the same.

Duplicate Message-IDs are duplicate Message-IDs.

> The breakdown in the piece of hardware causes a mangled or
> non-existant message id. How can a broken-down computer generate
> anything?

Remember the Pentium multiply bug?  A broken chip can still work
correctly most of the time.

> A flawed implementation generates a valid-looking but non-unique
> message id.

A good implementation on flawed hardware generates a valid-looking but
non-unique message id.

> There's a significant difference between the two.

"non-unique"

> No, you said they caused the SAME violation of the same MUST. Even
> were that true, the two causes are very different.

So what?

> "We shouldn't require adherance to a MUST because something else
> might break and violate the MUST" is just silly.

We shouldn't worry about one potential cause of violating a MUST
because its actual real-world probability is low enough not to matter.

> I don't think many ISPs know what software their outsourced news servers 

Then either don't use one that outsources news, or ask them who they
outsource it to and ask the outsourcer what it runs.

Or generate your own.

>>years Message-ID collision.

Do you avoid all risks greater than those duplicate Message-IDs during
your lifetime?

> just said it is a certainty to come up heads.

No, he didn't.  If a coin is expected to come up heads once per
thousand years, then either it's extremely biased, or it's expected to
be tossed twice in a thousand years.  (Or it's a little biased and
expected to be tossed a little over twice, or has only heads and
expected to be tossed once, etc.)

You keep claiming that other people don't understand what "expected"
means, with no evidence other than your own statements.

> might crash and violate it anyway."

Another red herring.  Who said we shouldn't or can't specify "MUST"?

We can't _implement_ it perfectly, because we can't implement
_anything_ perfectly.  That doesn't mean it shouldn't be in the spec.

Seth