Subject: [DNSOP] request for early feedback: NAPTR or SRV records in top-level domains?

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Aug 2008 16:24:08 -0400

Dear colleagues,

<background detail=long-winded>

In the IDNAbis working group, the current proposals alter the way IDN
work.  One important feature of this is a great deal more flexibility
on what might be registered at any domain.  Moreover, the current
proposals allow for local mapping at the client side.  Some of us are
uncomfortable with this plan, but the reasoning behind it is to allow
for flexibility in areas that have been controversial in the past
(many of the controversies occur at layer 9), and to allow the new
protocol not to break the existing "IDNA2003" behaviour.

It is plain, however, that reasonable zone operators will have to
implement several restrictions on what will be allowed to be
registered.  Moreover, it will aid interoperation and user experience
if clients can, in corner cases, learn what rules the server has in
place so that clients can perform mappings consistently.  (Otherwise,
the risk is that different clients will map things differently and end
up with results that are different in important respects, like
resolving differently.)

In what I am increasingly coming to think of as a moment of complete
insanity, I proposed to come up with a mechanism by which clients
could query the policies of a given registry (and remember "registry"
doesn't always mean "TLD" or equivalent) to find out what the
operator's policies are.  That would allow the client to take
meaningful advantage of the local-mapping capability.

</background>

To provide clients with a convenient way of learning about the policy
statements, I think I'll need a facility that I can be fairly sure the
client could use.  One that has occurred to me is the S-NAPTR
approach, as defined in RFC 3958.  My model in that case is roughly
that of IRIS.  (A variant is the simpler SRV record, but the problem
is the same.)

I am aware that there are some who think non-delegation records in
zones at the top level at least are a really bad idea.  (There are
obvious alternatives, of course, such as static lists compiled into
clients, or a static site that is well-known where people can look up
the policy.)  If you have strong feelings about any of these
approaches, and want to share them with me, I'd appreciate an email
about it.  Ideally off-list, I think, since I haven't actually put a
real proposal together, so there are no real technical details to hash
out.

Best regards, and thanks for your indulgence,

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop