On Mon, Jul 07, 2008 at 12:25:09PM -0400, John C Klensin wrote: > > > --On Monday, 07 July, 2008 10:30 +1000 Mark Andrews > <Mark_Andrews@xxxxxxx> wrote: > > >... > > If / when MIT stop using ai.mit.edu, "user@ai" will not longer > > mean user@xxxxxxxxxxx This will mean that any configuration > > file that has "user@ai" will now, suddenly, get a different > > meaning. This is a latent security issue. > > Mark, > > While I'm basically sympathetic to the position you are taking > on this, we have recommended for years and years (since the CS. > incident, if not earlier), that things like configuration files > use FQDNs and only FQDNs. SMTP imposes the same requirement on > addresses in MAIL and RCPT commands. > > If user@ai is in a config file with the intent of identifying > user@xxxxxxxxxx then the config file is broken. Conversely, > if the config file format is intended to permit references to > TLDs, I would hope that it would be possible to write "ai." if > the TLD were intended. > > Personally, I'm very concerned about what users type and what > happens after that. For configuration files and the like, I > believe that we have a case of bad design if the interpretation > of the configuration is dependent on things outside the scope of > that file and, in particular, if there is a dependency on DNS > search procedures rather than one explicit FQDNs. > > Quoting from your comment about Firefox, "Two wrongs don't make > a right. They just make two things that need to be fixed." > > john > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf John, do you beleive that DNS host semantics/encoding that form the bulk of the IDN work (stringprep, puny-code, et.al.) are applicable -only- in the context of zone file generation or are they also applicable in configuration and acess control for DNS? path/alias expansion/evaluation will be interesting if "." is not what 7bit ASCII thinks of as "." -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf