[ietf-dkim] Requirements clarification: Standard for resource record name space collision

[Michael Thomas]

Paul Hoffman wrote:

> At 1:02 PM -0400 8/9/06, Scott Kitterman wrote:
>
>> ***************
>> *** 474,480 ****
>>             expectation is "few".]
>>
>>      3.  Discovery mechanism MUST NOT overload semantics of existing DNS
>> !        resource records where name space collisions are possible.
>>
>>   5.2.  Transport requirements
>>
>> --- 479,485 ----
>>             expectation is "few".]
>>
>>      3.  Discovery mechanism MUST NOT overload semantics of existing DNS
>> !        resource records where name space collisions are reasonably 
>> likely.
>>
>>   5.2.  Transport requirements
>>
>> ***************
>>
>> Making name space collision impossible (the written requirement) is a 
>> high
>> bar.  Higher than was used for DKIM base.  Reasonably likely seems 
>> like a
>> better standard.  Impossible would seem to require a new RR.
>
>
> Actually, that's not true. For -base, there was no chance that a host 
> name (as compared to a domain name) would collide with a name that had 
> the chosen label. I think saying "impossible" is reasonable if you 
> clarify the difference. It would be really nice not to revisit the 
> wars that erupted when the IDN WG picked a label prefix. 

I agree with Scott that impossible is probably too high a barrier -- 
mainly because there
doesn't exist any way to reserve part of the namespace. Note that the 
requirement didn't
say anything about hosts. The main thing I'm trying to get across here 
is that overloading
TXT, say, at the top level like SPF did is a no-no. I think it's 
probably fine if a candidate
protocol carves out a piece of the namespace like DKIM did, as well as 
using its own
custom top level RR.

       Mike