On Wednesday 09 August 2006 16:42, Michael Thomas wrote:
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,
Are you making a change to the spec to change impossible to a more realistic
standard?
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html