Re: [DNSOP] draft-liman-tld-names-04

[Andrew Sullivan <[e-mail]>]

On Wed, Nov 24, 2010 at 10:48:19AM -0800, Doug Barton wrote:

>> IETF is supposed to be about interoperability, and if stuff breaks
>> because we have decided, "We don't care lalalalalala I can't hear
>> you there isn't a problem," then we ought to be ashamed of ourselves.
>
> I am rather specifically NOT claiming that there is no problem, and your  
> attempt here to paint me (and others who agree with this view) as  
> childish/foolish is a borderline ad hominem attack.

You have claimed that there is not a technical problem here, but
"merely" a policy one.  I am arguing that, given that some people
apparently read 1123 differently than you do, we have a technical
problem in the narrowest meaning of that term, and that we therefore
ought to address it.

Also, if you're going to start throwing around complaints about
fallacies, you'll want to describe them correctly.  If you really
think I'm misdescribing your position, it's not an _ad hominem_
anyway.  It's a straw person.  Moreover, while we're talking about
fallacies . . .

> I will once again point out that if your criteria is "We can never  
> deploy anything new in DNS because something in the installed base will  
> break" then the issue with this draft is moot. We simply will not do  
> IDNs at all, and therefore there is no need for the draft to clarify  
> anything. Oh and btw, are you going to notify Jari and Ralph that we're  
> closing down dnsext, or would you like me to do it?

. . . this is just a slippery slope argument, and not a very good one.
Engineering decisions involve trade-offs.  It is quite correct that
there may well be deployed software that will break when exposed to
on-the-wire DNS top-level labels that don't strictly conform to the
RFC 1123 "alphabetic" description.  That doesn't mean that we don't
deploy such labels: it means we have to make a decision about whether
the feature is worth the potential cost.

I think it is, and I also think that the right thing to do is to
specify exactly what we are changing and how so that, if something
breaks, people have something they can read in order to understand
what is going on.

Moreover, the class of applications that might be using the heuristic
about the top-level labels extends far beyond just those things
actually talking to the DNS.  It's actually that class of software I
am most concerned about.  That's what makes me think it is worth
specifying first the smallest variation from historical practice that
we can specify while still permitting the new use.

> I've already lodged this objection more than once, but since you have  
> repeated your side again, I'll do the same. We do not have a protocol  
> restriction now, and your attempt to assert one in a "clarify" draft is  
> at best, bogus.

Well, I'm not attempting anything: I didn't write the draft.  But I
think the draft tries to say that the 1123 language may be interpreted
(by some) as entailing a restriction, not that there is in fact such a
restriction:

   Some implementers may have understood the above phrase 'will be
   alphabetic' to be a protocol restriction.

It seems to me that if you want to make clearer that the text of 1123
ought not to be so interpreted, you could send text to that effect.

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.