On Wed, Mar 11, 2009 at 11:36 PM, Andrew Sullivan <a...@shinkuro.com> wrote: > On Wed, Mar 11, 2009 at 10:56:10PM +0800, James Seng wrote: >> By the same logic, the whole IDN would be pointless because RFC 1035 >> restrict labels to "alphabetic letter" only. > > I'd like the reference to where 1035 says that, please. In > particular, the following passage in §3.1 of RFC 1035 seems to say > something different:
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] ... <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case > you seem to be making my argument for me. The reason IDNA is > preferable to some of the alternatives is that some resolver software > indeed understood 1034 and 1035 to mean that the "preferred syntax" > ought to be enforced (in what seems to me a plain violation of those > RFCs). We have to live with those widely-deployed resolvers, and > therefore we need to design other protocols as though the additional > restrictions that are _not_ part of the DNS protocol are in fact part > of it. Designing the protocols for the actually existing conditions > in the network is what makes the design activity "engineering" rather > than "research", I think. Preciesly. Punycode instead of UTF-8 was selected because widely deployed implementation despite theortically DNS should be 8-bit clean. My point is that RFC 1123 statement on alphabetic requirement a) is highly debatable because it is not an explicit requirement since it is mention in a section called "DISCUSSION" in a passing that "since at least the highest-level component label will be alphabetic", in the context that TLD is alphabetic only as a matter of fact at that time, not as a matter of technical requirement b) even it is an explicit requirement, it should be taken in context in the spirit as much as RFC 1035 forbid non-alphabetic characters in labels. -James Seng _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
