Any design the requires a new RR type is not deployable anytime soon. As I said before, if a new RR type is the path we are going down, then we may as well quit and go home now.
To put it in requirements language, I think it is a requirement that SSP be deployable with the same DNS infrastructure that supports base (this is independent of where in the namespace the record goes - as long as it's somewhere in TXT we can design the details later). Scott K On Monday 16 October 2006 08:51, Michael Thomas wrote: > From a requirements standpoint, I'd just assume we not go into this level > of detail. The high level bits of deterministic number of lookups and other > things seem fairly uncontroversial, but the engineering/deployment > considerations > of the RR problem require a lot more detail and/or experimental evidence > to be > examined. I don't think that a requirements document is the right venue > to run > that debate. > > Mike > > Jim Fenton wrote: > >Eliot Lear wrote: > >>Jim, > >> > >>Fair points. One possibility, by the way, is that we use the SAME > >>prefix but simply with new attributes. That way you get the whole thing > >>in one shot. > > > >I'm not sure what you have in mind here. One of the benefits of using a > >new RR type is that it may allow us to get away from the use of a prefix > >entirely, which in turn may shorten the search process by detecting > >nonexistent domains more easily. I'm not certain how well this > >mechanism works, but you can see what I'm talking about in > >draft-allman-dkim-ssp-02. > > > >-Jim > >_______________________________________________ > >NOTE WELL: This list operates according to > >http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
