Re: Update of RFC 2606 based on the recent ICANN changes ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Update of RFC 2606 based on the recent ICANN changes ?



> On Thu, Jul 03, 2008 at 09:23:58AM +1000,
>  Mark Andrews <Mark_Andrews at isc.org> wrote 
>  a message of 32 lines which said:
> 
> > 	No sane TLD operator can expect "http://tld"; or "user at tld"
> > 	to work reliably. 
> 
> [Mark, you used non-RFC2606 names, the IESG will put a DISCUSS against
> you.]
> 
> I agree but it is not the point: an email adress like
> bortzmeyer+ietf at nic.fr is legal and works but not reliably (there are
> many stupid broken Web forms which refuse it and tell me it's not
> valid).
> 
> http://example is legal and should work. If it does not, it may
> indicate a broken implementation.

	But where should it resolve to?  "example.example.net."
	or  "example."?  Under what circumstances?

> >       I suspect there are still mail configuations
> > 	around that will re-write "user at tld" to "user at tld.ARPA".
> 
> There are many broken mail configurations.
> 
> > 	Should we be writting a RFC which states that MX and address
> > 	records SHOULD NOT be added to the apex of a TLD zone?
> 
> No. A TLD is a domain like any other and we should not write special
> rules for them.

	Names with and without dots already have different semantics.
	
> > 	Should we be writting a RFC which states that single label
> > 	hostnames/mail domains SHOULD NOT be looked up "as is" in
> > 	the DNS?
> 
> I hate special cases.

	TLDs are already a special cases in so many ways.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.