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
