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

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 13:02:29 -0400

***************
*** 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.

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Aug 2006 11:12:13 -0700

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.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Aug 2006 13:42:20 -0700

Paul Hoffman wrote:

> 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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 10 Aug 2006 08:58:58 -0400

> protocol carves out a piece of the namespace like DKIM did, as well as
Mike,

Are you making a change to the spec to change impossible to a more realistic 
standard?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 10 Aug 2006 10:46:27 -0400

On Thursday 10 August 2006 10:26, Michael Thomas wrote:
> Scott Kitterman wrote:

> >Mike,
> >
> >Are you making a change to the spec to change impossible to a more
> > realistic standard?
>
> How about:
> ><t>Discovery mechanism MUST NOT overload semantics of existing
> >  DNS resource records where name space collisions are plausible. For the
> >  purposes of this requirement, neither an underscore prefixed namespace
> > or a new resource record type are considered plausible.</t>

Sounds good to me.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 Aug 2006 07:26:25 -0700

How about:

>  purposes of this requirement, neither an underscore prefixed namespace or a new resource
>  record type are considered plausible.</t>
>  
>

       Mike