[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Extending gethostbyname()
- To: idn@ops.ietf.org
- Subject: Re: [idn] Extending gethostbyname()
- From: "D. J. Bernstein" <djb@cr.yp.to>
- Date: 29 May 2001 04:47:34 -0000
- Delivery-date: Mon, 28 May 2001 21:48:24 -0700
- Envelope-to: idn-data@psg.com
- Mail-Followup-To: idn@ops.ietf.org
Did the RFC 1123 authors worry about some badly written programs having
trouble with names like 3com.com? Yes, they did. Did that stop them from
extending the host name syntax? No, it didn't.
Those programs were declared buggy, and they were fixed, and now we can
use 3com.com without trouble. Programmers don't have to encode 3com.com
as ACE-GARBAGE-DIGIT-THREE-LETTER-C-LETTER-O-LETTER-M.com.
Now, do we want to follow the model of RFC 1123's easy syntax extension?
Or do we want to follow the model of RFC 1342, which is continuing to
annoy users and programmers a decade after its introduction, and which
promises to continue annoying us for decades to come?
Mark.Andrews@nominum.com writes:
> Relaxing the requirements to allow a digit as the first character of a
> label broke some applications
Extending gethostbyname() didn't break anything. In fact, extending
gethostbyname() made it vastly _easier_ for applications to support the
new syntax. Most applications worked perfectly, no effort required.
In contrast, if gethostbyname() had enforced the old syntax, and if an
idiotic new gethostbyextendedname() function had been introduced for the
new syntax, nothing would have worked. Every application would have had
to switch from gethostbyname() to gethostbyextendedname(). Ridiculous!
---Dan