Re: msg-id

[John Stanley <stanley@xxxxxxxx>]

Seth Breidbart <sethb@xxxxxxxxx>:

>You are making the assumption that a new domain owner will continue to
>use the same algorithm. 

No, I don't care what the "new domain owner" decides to do. We cannot 
prevent people from choosing to duplicate message ids, we can only specify 
that they MUST NOT do so. And we can point out non-conforming 
implementations, like those that are designed to do so. And we can look at 
conforming algorithms, like the one I showed.

>> There is no other owner at that epochtime. 

>So what?

So that algorithm will not duplicate message ids. Some other algorithm 
might, but that does not make mine broken.

>>>...and gets his pids randomly from 32-bit space (to avoid potential
>>>attacks based on known-pids).  Oops.
>>
>> I'm interested in hearing which operating system allows two different 
>> processes to have the same process id at the same time.

>You might read my example more carefully.  

I read your example. Since the pid is part of the id, the only way that my 
algorithm could duplicate message ids is for TWO processes to have the 
same message id at the same epochtime AND for the locking mechanism that 
prevents duplicate sequences to fail. I know of NO operating system that 
assigns the same pid to two different processes, so even if the sequence 
number fails, the pids will be different.

>Because the new owner used a _different_ algorithm,

What new owner? What so what if he uses an algorithm that will duplicate 
message ids? We are talking about THIS algorithm, which does not.

>> The question was about a MUST be unique clause, which doesn't actually
>> need to be unique.

>It does need to be unique.  The protocol fails when it isn't unique.

Well, the algorithm that brought this up doesn't guarantee unique ids. 
Thus it does not meet the "MUST" requirement. If it is "good enough", then 
you are saying that the MUST really isn't a must, and thus the "unique" 
doesn't really need to be unique.

>I'm saying that I'm not worried about sufficiently-low failure
>probabilities. 

Yep. Got that. Unfortunately, "MUST" and "unique" combine to zero. Either 
you don't mean "unique" or you don't mean "MUST". Which is it?

>You say that you won't accept them, except that your
>examples of what is acceptable to you still have non-zero failure
>probabilities.

Until you can show me an operating system that assigns the same pid to two 
different processes, I'd say that the odds of a duplicate using my 
algorithm are zero.

>> If mozilla creates message ids for a domain that may never see the
>> message at all, then it cannot guarantee it will be unique.

>I own a domain that does not run a news server. That domain will never 
>see a usenet message. 

That's nice. What does it have to do with the news system?

>Yet use of it in the RHS of a Message-Id
>by me can certainly guarantee uniqueness (modulo other people doing
>stuff they're not entitled to, which can break any algorithm).

That's very nice. Also completely irrelevant. The issue you are 
responding to here is a client creating message ids IN SOME OTHER DOMAIN,
which may never see the message at all. Your client creating ids in
YOUR domain is not the same thing, obviously. Please pay attention.

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>there also appears to be an assumption that "domain" is the same as
>"host" 

Yes, and I should have corrected that earlier. Instead of 
fully.quallified.domain.name, I said "domain". I thought it would be 
understood. My mistake.

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Consider the two message-ids:

>   <12345678@xxxxxxxxxxxxxxx>
>   <12345678@xxxxxxxxxxxxxxx>

>They are DIFFERENT message-ids. Yes?

Not as far as I can tell.