> At 15:40 02-07-2008, John C Klensin wrote:
> >Now, for example, I happen to believe that "one-off typing error
> >is guaranteed to yield a false positive", is a more than
> >sufficient _technical_ basis to ban single-alphabetic-letter
> >domains at either the top or second levels and to advise
> >lower-level domains against their use. Those are technical
> >grounds based on human interface design and information
> >retrieval principles, not "the network will break if that is
> >done". But few of the recommendations or reservations we might
>
> Some people may question a technical recommendation that is not based
> on "the network will break".
>
> >make fall into that network-breaking latter category. Even some
> >of those that fall closest to the line involve cases that we
> >could "fix" by modifying our applications protocols to lexically
> >distinguish between domain names and address literals
> >(http://[10.0.0.6]/ anyone?).
>
> Or wait for http://[2001:1890:1112:1::20]/ to catch up.
>
> >But, should those of us who believe that single-letter domains
> >are bad news refrain from advocating for that rule because those
> >who oppose it could use it to discredit other IETF
> >recommendations that might be more important? I don't know
>
> That's a question to consider before getting into any rule-making.
>
> >The rather odd phrasing there has been the source of a lot of
> >discussion in the past in both selected IETF and ICANN circles.
> >Some of us read it as "TLDs will be alphabetic only -- no
> >digits", not just "cannot be all digits". The former was
> >certainly the IANA intent when we were discussing RFC 1591.
> >But does it apply today? Can ICANN override it? I can assure
> >you that there are groups within ICANN who believe that they can.
>
> RFC 1591 has been swept away by the changes that have taken placed
> since then. By making a few changes to RFC 5241, we could have a
> document relevant to this topic. :-)
>
> At 16:23 02-07-2008, Mark Andrews wrote:
> > No sane TLD operator can expect "http://tld"; or "[EMAIL PROTECTED]"
> > to work reliably. I suspect there are still mail configuations
> > around that will re-write "[EMAIL PROTECTED]" to "[EMAIL
> > PROTECTED]".
>
> http://museum/
The key word word is "reliably". http://museum/ can never
be guarenteed to work.
I can have museum.example.net with a search list containing
example.net. Which one would you expect to match? Note
changing the search order to try single labels "as is" first
is not safe from a security perpective (see RFC 1535 for why
not) as the introduction of a new TLD will break things.
Getting rid of search lists is also a show stopper.
> > Should we be writting a RFC which states that MX and address
> > records SHOULD NOT be added to the apex of a TLD zone?
>
> The above TLD has an address record.
It still does not make it a good thing.
> > Should we be writting a RFC which states that single label
> > hostnames/mail domains SHOULD NOT be looked up "as is" in
> > the DNS?
>
> There was a ccTLD operator who expressed the wish for such mail domains.
And I can wish for a million dollars to be added to my
savings account. It doesn't mean I'll get it or that the
ccTLD operator should get it.
Mark
> Regards,
> -sm
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
