> The DISCUSSION portion of 2.1 is explaining why relaxing RFC 952's > restriction is safe. The safety flows exclusively from the premise > that the highest-level component label of a domain name "will be > alphabetic"; this guarantees that a syntactic check for an IP address > will fail due to at least one label being made up only of letters. It > may be, therefore, that the "alphabetic restriction" is in fact > policy, and is not strictly a protocol issue. The problem is that it > is policy on which other technical decisions rest. Change the policy, > and the justification for those other technical decisions is > undermined. In this sense, the claim in the DISCUSSION portion of 2.1 > is not just a policy: it is also the foundation of other protocol > issues, and is therefore normative on the protocol even if it _is_ a > policy matter.
Okay, I agree with this line of logic. 1. We agreed that the TLD restriction is therefore a policy one, and we derive other technical specification (e.g. allowing digits label at 2LD) based on the assumption of the policy one. 2. However, IDNA does not change that technical assumption, since A-label will never be all digit, or start with a digit or end with one. > The 2001 introduction of a number of new TLDs was > rockier than necessary partly because of those checks, even though > there was never an RFC that suggested such was a good check. Agreed > 1123 _does_ suggest that it is reasonable to check for top-level labels > being alphabetic, and I'd bet a pretty good lunch that we can find > implementations that decide whether something is a "domain name" based > on whether the top label starts with a letter. Therefore, even if we > don't think that 1123 does in fact restrict the top-level label to > letters only, it is prudent to treat such a restriction as a _de > facto_ part of the protocol. This is where we differ. 1. RFC 1123 do not suggest that top-level labels be check for alphabetic. RFC 1123 assumed TLD is alphabetic and therefore made certain technical assumption of what is considered valid or not. But I agree with you that there will be implementation that decide what TLD should be but it is a problem with the implementation, not with RFC 1123 or RFC 952, esp on what it did not say. 2. IDNA do not change it either again, since A-label is always LDH, or at least valid according to RFC 1123. > To the extent we want to change that de facto part of the protocol, we > want to do as little damage as possible. An argument in favour of > John Klensin's suggestion to make an explicit exception for IDNA2008 > A-labels is that it is the smallest change that can be made that still > accommodates the new feature we want. What I failed to see is why we need an update to RFC1123...but I can accept the small change as proposed by John if thats what the group think it is best moving forward. -James Seng _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
