Re: [Internetgovtech] off topic: labels (was Re: Documents from the ICG Meeting Last Week are Available)

[Eric Brunner-Williams <[e-mail]>]

Yeah, that was a mistake. If you ever get around to responding to the 
main point that would be ... well, too late at this point.

On 7/21/14 1:08 PM, Andrew Sullivan wrote:
> Since you asked on list, I'll reply, but I don't think this is the
> right list to pursue this discussion and if we're going to have to do
> that I suggest perhaps DNSOP or the dns-operations OARC list or
> perhaps [e-mail] (which is still open), depending on whether
> you want to talk about protocol or operations.
>
> On Mon, Jul 21, 2014 at 12:40:44PM -0700, Eric Brunner-Williams wrote:
>
>> P.S. Exactly what is wrong with 5 octet labels? With 4 octet labels?
>> With 3 octet labels? And finally, with 2 octet labels?
> Nothing, in principle.  In practice, it depends.  You might want to
> have a look at RFC 6912.  Even though it was particularly about
> Unicode code points for U-labels, the general principles outlined
> there are useful in other ways too.
>
>> P.P.S. Exactly what is wrong with a terminal label consisting only
>> of characters in the 0-9 range, that is not completely cured by a
>> requirement that the next subordinate label contain one or more
>> characters from the range g-z?
> Well, the actual terminal label cannot contain any characters at all,
> but I think you knew that and meant the second-to-last label
> (conventionally called a TLD).  So, first, there's actually no
> technical way to require what you're saying, really.  That's what
> "delegation" means.  You could do it with contracts, though.
>
> But what you're really saying is that the heuristic implied in RFC
> 1123 might break.  That seems like an extremely incautious thing to
> do, and therefore a responsible operator of the root zone wouldn't do
> it.  Technology is not infinitely plastic: once you have deployed
> something, it affects the world.  In the case of the DNS, the way it
> has affected the world is partly based in the assumptions people have
> about what their software may depend on.
>
> Best regards,
>
> A
>