Erik Nordmark wrote:
> The result could be an overcooked or burned cake, or the people that > originally wanted to eat the cake might have gone elsewhere for > norishment. Hmm, or the people get served wet dough under the pretense of cake, and go somewhere else for the cake they really wanted. > Ignoring the analogy, I don't think we can delay this work forever until > it is viewed to be perfect. I don't think any of us expect anything to be perfect (lack of uppercase non-ASCII is an obvious example of trade-offs already encountered). The problem we have at this point is that there isn't even a "good enough" specification. I mean, on the surface we have something that may work for IDN zone delegation with legacy servers, but SRV owners, legacy ASCII mixed case in PTR, valid mailboxes in SOA, legacy eight-bit domain names are all invalid in the model. This is without even discussing potential future problems. Incredible. As to whether or not a requirements document is necessary, note that several modifications were suggested which would have made it relevant, the suggestions were ignored, and then the document was shelved by an external committee. Well yeah, it's irrelevant without the changes, but why exactly are we prohibiting the changes that would make it relevant? If the only reason is to allow the advancement of an early solution that is incompatible with existing and future usage models, well, that's a bad call on multiple fronts, imo. If people want to go some other path, let them. My guess is that the squeaky wheels have sunk a considerable amount of time and capital into a single likely outcome, and that anything outside of the head-start advantage afforded by that outcome is going to be problematic for them. Too bad, So sad, should have waited. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
