Subject: [dnsext] Re: Request for input and participation

From: Andrew Sullivan <[email-masked]>
Date: Mon, 8 Mar 2010 14:54:08 -0500

On Mon, Mar 08, 2010 at 02:22:06PM -0500, Michael Richardson wrote:
> So you mean, something like:
>     example.co.uk
> and esempio.it
> (google tells me that esempio is example in Italian)
> 
> need to be "the same", and this is somehow hard to do by some mechanism
> on the primary DNS server, a la bind9's $INCLUDE.

Well, it'd be impossible if some of the operators you were attempting
to use that with didn't run bind.  Or even use zone files.  So yes.

> It seems like a problem that some operators have with the software they
> are running, rather than a problem for the IETF DNSEXT to solve.

That was one conclusion available to us during the interim meeting,
and we didn't get anyone willing to make the argument that everything
was taken care of yet.  The materials from the meeting might be
helpful as background here.  They're on the WG wiki pages.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Mar 2010 14:22:06 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

{I'm way behind on namedroppers emails}

>>>>> "Andrew" == Andrew Sullivan <[email-masked]> writes:
    Andrew> Here is what the DNSEXT chairs believe so far.

    Andrew> The immediate stimulus for this work is Internationalized
    Andrew> Domain Names for Applications, and particularly the IDNA2008
    Andrew> work.  In the context of IDNA, some operators apparently
    Andrew> have a need to operate "variant" zones, with two different
    Andrew> DNS names apparently working as though they are "the same".
    Andrew> There are some other obvious contexts, however, in which
    Andrew> similar functionality could be useful.

    Andrew> It is not entirely clear what "the same" means in the above.

need to be "the same", and this is somehow hard to do by some mechanism
on the primary DNS server, a la bind9's $INCLUDE.
I do this for sandelman.ca and sandelman.ottawa.on.ca.

Why is it useful for a cache to know that www.sandelman.ca and
www.sandelman.ottawa.on.ca are the same thing?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2010 16:50:12 +1100

> > on the primary DNS server, a la bind9's $INCLUDE.

Also it is *not* BIND's $INCLUDE.  It is RFC 1035's $INCLUDE.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Tue, 9 Mar 2010 16:26:01 +0200

Dear Michael,

The problem is much more complex than the one presented with your example.
It originates by the need of the IDN domain names to be operating in the
user experience level like the Latin domains do (it is irrelevant if you
type something in caps or small letters).

Specifically in the Greek case where almost every word has the "tonos"
accent sign and some words end in a final sigma, bundling is a necessity and
not an option. Otherwise, depending on how you type something you end with a
different domain although as a user you have the firm belief that you typed
the same word.

For us solving this issue in the protocol level is very important.

Kind Regards,

Vaggelis Segredakis
Administrator of the .GR Top Level Domain
Institute of Computer Science
Foundation for Research and Technology - Hellas
Tel. +30-281-0391450
Fax +30-281-0391451
Email [email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday, March 08, 2010 9:22 PM
To: [email-masked]
Cc: Andrew Sullivan
Subject: [dnsext] Re: Request for input and participation 

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls
[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device
driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Mar 2010 10:20:28 -0500

>>>>> "Vaggelis" == Vaggelis Segredakis <[email-masked]> writes:
    Vaggelis> Specifically in the Greek case where almost every word has
    Vaggelis> the "tonos" accent sign and some words end in a final
    Vaggelis> sigma, bundling is a necessity and not an
    Vaggelis> option. Otherwise, depending on how you type something you
    Vaggelis> end with a different domain although as a user you have
    Vaggelis> the firm belief that you typed the same word.

What you are saying is that the combinatorics of each letter having both
tonos and not tonos is sufficiently high that for a 10 letter domain,
you might be having to have 1024 zones.  And that's just with one kind
of accent.

Greek's want to experience the same kind of service that anglos experience
where it doesn't matter what case we use.

Do you envision that the .gr nameserver might implement the
accent-insensitive results by doing accent-insensitive lookups on zones
loaded and synthesizing whatever protocol result we decide upon.
(I think "bname" was mentioned in one draft)

- --

---

From: Paul Vixie <[email-masked]>
Date: Tue, 09 Mar 2010 16:48:09 +0000

> From: Michael Richardson <[email-masked]>
> Date: Tue, 09 Mar 2010 10:20:28 -0500
> ...
> Do you envision that the .gr nameserver might implement the accent-
> insensitive results by doing accent-insensitive lookups on zones loaded
> and synthesizing whatever protocol result we decide upon.  (I think
> "bname" was mentioned in one draft)

i do not envision the equivilence work being done at lookup time as it is
for case-insensitive USASCII lookups.  rather, i envision BNAME synthesis
as some part of "zone preparation", similar to how the IDN conversions from
"wchar_t" IDN to "char" USASCII are done now.

---

From: Doug Barton <[email-masked]>
Date: Tue, 09 Mar 2010 14:48:20 -0800

On 3/9/2010 7:20 AM, Michael Richardson wrote:
>>>>>> "Vaggelis" == Vaggelis Segredakis<[email-masked]>  writes:

Michael,

With respect you'd probably be better served catching up on your mail 
before wading in here. It's a dense topic, and got a pretty good 
(although unsatisfying in the conclusions department) treatment in the 
recent past.

In regards to Greek variants, the tonos (sort of an acute accent mark) 
can only appear once per _word_, not per letter. Since most words have 
it, and many words end in the letter sigma (which has a terminal and 
non-terminal variant) it's not at all uncommon to have 4 different 
unicode variants for the same Greek word.

I believe the point that Vaggelis, and many others in the IDNA world are 
making is that to end users all of those 4 variants should work in 
exactly the same way, just like EXAMPLE.COM and example.com work the 
same way in the ASCII world.

> (I think "bname" was mentioned in one draft)

The various *NAME proposals are ultimately unsatisfying in the sense 
that they fall back to CNAME synthesis which prevents the use of the 
variant names as MX or NS records.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Mar 2010 10:54:36 +1100

> same way in the ASCII world.

Given that they are NOT the same word they can be exactly identical.  The
open question is however is "how exact" is good enough.

Is a BNAME pointing to the canonical form of the name good enough?
For Greek? For other languages?

> variant names as MX or NS records.

But is that a real show stopper or a imagined show stopper?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Mar 2010 11:11:36 +1100

> But is that a real show stopper or a imagined show stopper?

Also remember MX records are supposed to point to the name the MTA
knows itself by not a alias.  For this requirement A's and AAAA's
can be aliases, CNAMEs are just obvious aliases so they are easy
to detect.  This is for MX processesing in the MTA.  It also impacts
on STARTTLS as the correct CERT needs to be offered that matches
the name in the MX (implicit or explicit).

---

From: [email-masked]
Date: Wed, 10 Mar 2010 00:16:06 +0000

> Is a BNAME pointing to the canonical form of the name good enough?

	a what?  BNAME?
	where is that defined?  RFC?  I-D?  ISC internal tech report?

--bill

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Mar 2010 11:24:44 +1100

> 	where is that defined?  RFC?  I-D?  ISC internal tech report?

http://tools.ietf.org/html/draft-yao-dnsext-bname-01
 
Mark

---

From: Doug Barton <[email-masked]>
Date: Tue, 09 Mar 2010 16:47:04 -0800

> open question is however is "how exact" is good enough.

I don't parse this. <Greek word with tonos> and <Greek word without
tonos> are actually the same word, it's just a different way to
represent it. The same is true of terminal sigma.

> But is that a real show stopper or a imagined show stopper?

My understanding is that it's a real concern, but this is exactly the
kind of feedback that the "request for input" is supposed to elicit.
FWIW I've been encouraging people in the ICANN world to review the post
to the IETF list and hopefully to provide some useful feedback. My
perspective of the situation is informed by my work with various people
to whom these issues matter, but it's much better to get them to express
their needs and concerns directly.

> the name in the MX (implicit or explicit).

Actually this is a good example of why "the same" really needs to be the
same. Why should the user have to pre-plan which representation of the
domain name should be the "real" one, and therefore valid for use in
MX/NS records? The names should be functionally equivalent in every way.

Doug

--

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Mar 2010 12:19:26 +1100

> MX/NS records? The names should be functionally equivalent in every way.

For NS BNAME is actually a better solution as you only put the
offical zone in the nameserver configuration.  As the operator of
the zone you should know the name of your own servers.  Note its
very easy for a parent zone administrator to check whether a name
is a alias or not when a delegation is done and glue processing
doesn't work with aliases.

For MX and SRV it is up to the applications that use these records
to handle aliases be they CNAME/DNAME/BNAME or multiple QNAMES which
have the same A/AAAA records derived.

People have got caught up thinking CNAME/DNAME/BNAME is the only
way aliases happen.  They add multiple A records to silence the
warning but they don't get rid of the problem.  CNAME is not the
issue.  Aliases are the issue here in *all* possible forms.

EXAMPLE.COM and example.com are NOT aliases.  They are the same
name.

<greek-plain>.gr, <greek-tonos>.gr, <greek-final-sigma>.gr and
<greek-tonos-final-sigma>.gr are aliases of each other whether they
are implemented as CNAME/DNAME/BNAME or A/AAAA records.  There is
NOTHING dnsext can do to change that.  The only thing we can do is
to decide if there will be a formal canonical form (CNAME/DNAME/BNAME)
or not (A/AAAA).

Mark

---

From: Federico Lucifredi <[email-masked]>
Date: Tue, 09 Mar 2010 20:30:57 -0500

> But is that a real show stopper or a imagined show stopper?
+1

Best -F

-- 
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked] - GnuPG 0x4A73884C

---

From: John Levine <[email-masked]>
Date: 10 Mar 2010 03:47:10 -0000

>I believe the point that Vaggelis, and many others in the IDNA world
>are making is that to end users all of those 4 variants should work
>in exactly the same way, just like EXAMPLE.COM and example.com work
>the same way in the ASCII world.

The more I see of this argument, the clearer it is to me that this is
a problem that no amount of DNS twiddling can solve.

In English, the equivalence of upper and lower case is embedded not
just in the DNS, but in web clients and servers, mail clients and
servers, and all sorts of other software than handles domain names and
related English strings.  (Even there, the equivalence isn't handled
perfectly, viz. the ambiguity between standards that say that case
matters in the local part of mail addresses, and the universal
practice that says it doesn't.)

No matter what fabulous improvements we make to DNS servers and
clients to provide bundling or synonyms among names that are supposed
to be equivalent, users aren't going to be happy until all the other
software that handles domain names does that, too.

I realize there's a lot of pressure from the IDNA community, many of
whom say, roughly, "I just want these names to work the same", but as
with most requests that start "I just want", what they want is vastly
more complex than it may appear to be.

I haven't followed the process in enough detail to understand how much
of the name bundling to date could be packaged up for use in web
servers, MTAs, and other software that interpret domain names in
contexts other than DNS queries, but what we really have to do is to
communicate the bad news that until the application software
understands the synonyms, it doesn't really matter what the DNS
servers do.

R's,
John

---

From: [email-masked]
Date: Wed, 10 Mar 2010 06:00:11 +0000

On Wed, Mar 10, 2010 at 11:24:44AM +1100, Mark Andrews wrote:
> MarkA

	thanks.

--bill

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 10 Mar 2010 09:19:48 +0100

Or, just to rephrase this, people want "aliasses to a domain name"
which don't need any special processing and can be used as as a
full class citizen everywhere without any cost (for them).

	jaap

---

From: João Damas <[email-masked]>
Date: Wed, 10 Mar 2010 09:55:51 +0100

In the case of ASCII upper-lower case, the RFCs say you need to treat them as equivalent. However nothing actually changes on the wire. This is something that happens in the implementations.

In the case of ASCII it is very easy to convert between upper and lower case due to the design of the table: you simply logical-AND with !0x20.
In the general unicode case this is not as efficient (from a computing point of view), but I wonder if the solution shouldn't also reside in the implementations: the DNS libraries would need to extend the equivalence code from just applying the 0x20 bit-flip to a more complete mapping. Yes, every query name would need to go through the mapping, yes it is more compute-intensive, but it seems like it is also the right place for this to take place and avoid protocol modifications that will have the not-100% property.

Joao

---

From: [email-masked]
Date: Wed, 10 Mar 2010 10:12:23 +0000

> In the case of ASCII upper-lower case, the RFCs say you need to 
> treat them as equivalent. However nothing actually changes on the 
> wire. This is something that happens in the implementations.
> 
> In the case of ASCII it is very easy to convert between upper and 
> lower case due to the design of the table: you simply logical-AND with 
!0x20.
> In the general unicode case this is not as efficient (from a 
> computing point of view), but I wonder if the solution shouldn't 
> also reside in the implementations: the DNS libraries would need to 
> extend the equivalence code from just applying the 0x20 bit-flip to 
> a more complete mapping. Yes, every query name would need to go 
> through the mapping, yes it is more compute-intensive, but it seems 
> like it is also the right place for this to take place and avoid 
> protocol modifications that will have the not-100% property.

But surely what's required is much more than one-to-one character 
equivalence mappings?

For example, what about .jp and the Kanji equivalent (.日本 I think). 
That's just as valid a use-case as the Greek example, but requires an 
entire string to be mapped.

Ray

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 10 Mar 2010 11:04:15 +0100

In the general case there is no 1:1 mapping between lower and upper case. Instead there are functions defined that for example can create a lowercase(ch) version of ch, although the uppercase(lowercase(ch)) might not be ch.

Etc.

Recommendation is to "not go there". IDN discussions have been in this rat hole for years, and there are enough people on the bottom of that hole. Together with the rats.

   Patrik

---

From: João Damas <[email-masked]>
Date: Wed, 10 Mar 2010 12:19:16 +0100

I wasn't referring to 1:1 mapping, more like 1:n and surely it won't be as easy as some bit-flipping, more like a table lookup

On 10 Mar 2010, at 11:12, [email-masked] wrote:

> > lower case due to the design of the table: you simply logical-AND with !0x20.
> But surely what's required is much more than one-to-one character equivalence mappings? 
> 
> For example, what about .jp and the Kanji equivalent (.日本 I think).  That's just as valid a use-case as the Greek example, but requires an entire string to be mapped. 
> 
> Ray 
> 
> 
>

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 10 Mar 2010 12:51:07 +0100

This is much more messy than that as well, as the potential conversion is not character by character. And that we already from IDNA2003 know that people are confused over what they (for example) actually have registered. Have they registered FOO.com, or foo.com? I.e. when the lowercase mapping from FOO to foo happens in the application, and not in the DNS layer, some people think they have registered FOO.com and not foo.com.

And that create problems when you for PTR records and similar cases have "reverse functions" where people actually get exposes to the foo.com version -- and claim they have not registered it.

This is the main reason why IDNA2008 very very explicitly say that the only thing that can be called a domain name is what the IDNA spec call an A- or U-label (depending on whether it is the xn-- version or the version in Unicode). Anything else can of course be mapped to one such domain name that have a 1:1 mapping between A- and U-label, but it is not a domain name.

And, there are other cases that are more complicated than case mappings/foldings. For example how to handle equivalence of other combinations of characters. Things that can be expressed in multiple different ways. The problem with simplified/traditional in chinese. The issues with non-spacing marks in arabic and other context dependent character mappings. The difference in case mappings that are language dependent (in French for example). Etc.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Mar 2010 08:32:58 -0500

Dear colleagues,

> open question is however is "how exact" is good enough.

Before we open a completely new rat-hole to jump down here, I want to
note that the DNS has no words in it.

The DNS has labels.

The DNS is not in English, either.  It's not there to write prose.
(Think of the words you can't write in the DNS.  Like "can't".)

The IDNABIS WG has been all over this topic, several times, with some
participants using what we might call "folk linguistics" as well.  We
don't need to repeat that futile effort here.

The question at hand is not whether we can solve intractable
linguistic problems in the DNS.  The question is merely that, if we
suppose that there are two DNS trees of different labels that happen
to have the same natural-language semantics, can we then make the DNS
work transparently enough for users so that their natural impulse with
those natural-language semantics is not violated?  This is a much more
restricted goal.  It also has the happy property of being a technical
question, rather than a philosophico-linguistic one.

So, no "words", please.  Thanks.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 10 Mar 2010 09:10:53 -0500

> (Think of the words you can't write in the DNS.  Like "can't".)

can\039t or maybe \034can\039t\034

---

From: Tony Finch <[email-masked]>
Date: Wed, 10 Mar 2010 15:02:30 +0000

On Wed, 10 Mar 2010, Mark Andrews wrote:
> knows itself by not a alias.

In practice all implementations allow MXs to refer to CNAMEs.

> This is for MX processesing in the MTA.

MX processing is specified in terms of both names and addresses, so an MTA
does not in fact need to know all of its hostnames. Given a domain name it
can work out if any of the addresses refer to any of its network
interfaces. (However I should note that the MTA needs to know a bit more
if it is behind a NAT or if it is part of a cluster.)

> It also impacts on STARTTLS as the correct CERT needs to be offered that
> matches the name in the MX (implicit or explicit).

There is no specification for how to verify a certificate presented by an
MX. In practice, most MX certificates cannot be verified, and MTAs that
use TLS when speaking to MXs do not try to verify certificates.

http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Wed, 10 Mar 2010 17:11:52 +0200

We actually do not put a tonos on each letter, so 1024 zones for a
single-word domain are not necessary. Two would be sufficient today; four if
the domain has a final sigma and IDNA2008 is adopted. You could have
interesting variations though with more-than-one-word-with-final-sigmas
domain names :-)

I think the Bname proposal is very close to what we have asked from IETF.

Best,

Vaggelis Segredakis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 09, 2010 5:20 PM
To: Vaggelis Segredakis
Cc: [email-masked]
Subject: Re: [dnsext] Re: Request for input and participation 

- --

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 10 Mar 2010 10:13:15 -0500

+1

A one-para tour of horrors is the effort primarily among the
governmental representatives of the League of Arab States (so not
including all Arabic Script using users, e.g., those using Farsi,
Dari, and "Arabized" users in Sub-Saharan Africa and East Asia) was
the assumption that only proper (standard) Arabic words could be used
to form labels identifying mapped resources. This surfaced tensions
latent between Arabic language users and non-Arabic language users who
"shared" a common (Unicode Consortium created through "unification")
script.

It isn't something worth repeating. There are no words, only
identifiers, encoded as labels encoded as strings from some base
repertoire of characters.

I'd weaken the "same natural-language semantics" condition. There are
two (or more) trees in some namespace(s) (I don't care if one is
anchored at MdR and the other in Beijing), assert a single resolution
semantic. Solve for mechanism(s).

Eric

---

From: Edward Lewis <[email-masked]>
Date: Wed, 10 Mar 2010 10:22:07 -0500

>can\039t or maybe \034can\039t\034

Remember the 7-layer reference model?  Layer 6 = "Presentation layer"

That's the problem.  It's the presentation of the data that is the issue.

The DNS application layer (7) rests on a very flimsy presentation 
layer, so flimsy we've forgotten it's significance.  The presentation 
layer consists of:

1. The fixed-width fields we shove data into (well, significant but 
taken for granted)

2. The upper/lower case thing

3. The way in which we represent characters like "'" in text (\034).

What we are really looking for are new presentation layer rules.  I'm 
not saying that would be easy.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Mar 2010 11:36:18 -0500

No hat.

> can\039t or maybe \034can\039t\034

Well, that'll teach me to write a hurried message before rushing off
to a morning appointment.

This is right.  And of course, you can _also_ put any 8-bit label you
like in the DNS: that's quite clear in the RFCs.

But the plain fact is that we also have the "LDH" (letters, digits,
hyphen) restriction, which (since it's enforced all over the place in
applications, as I think it was John Levine pointed out elsewhere in
this thread) is effectively also a constraint on the particular
problem we're taking about in IDNA.

The IDNABIS WG restricted itself to either localizing or
internationalizing (depends on whom you believe) LDH, and I think
that's the right goal _for that application_.

But we're not trying to solve that problem, and if we were, it's too
late: IDNABIS has finished its work, as near as I can tell.

What is _on_ charter here is to address the DNS protocol implications,
if there are any, for two different labels or series of labels that
people want to treat as "the same".  In my opinion, we still need to
make sure that we understand what people think they mean by "the
same", we need to figure out what we actually can achieve without
undertaking DNSng, and we need to figure out whether those are even
possibly alignable.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 10 Mar 2010 17:41:05 +0000

> undertaking DNSng, and we need to figure out whether those are even

Pondering the policy space on variant issues lately, I'm tempted
towards a possible taxonomy of flavors of "the same".

For example, in some situations, having {label.A1, A} and {label.B1,
A} both resolve to {label.A1, IP address} is fine, no concern about MX
or NS or about visibility of a B1 namespace needed. This is probably
the simplest case for current technology.

In other situations, nothing less than complete transparency of
complete synchronization of namespaces will do-- such that it's not
visible to the user who asked for {label.A1, A} that {label.B1, A}
even exists, or vice versa, but they all resolve to the same RH value.
People smarter than I am about this class of usage assure me this is
impossible, either theoretically or without DNSng.

It may be useful to put more effort into solving the former of the
"variant problems" than the latter.

(I'm trying to get people to drop the definite article in this context
and replace "the variant problem" with "variant problems"-- it seems
to open up the mental landscape a bit more.)

Is it possible and useful to build such a taxonomy?

Suzanne

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Mar 2010 13:11:00 -0500

> Is it possible and useful to build such a taxonomy?

Yes, both possible and useful, in my no-hat opinion.  If some people
wanted to undertake that and post to the mailing list even a draft
outline of such a taxonomy before we meet in Anaheim, in my view it
would greatly help our discussion there.

Thanks!

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 10 Mar 2010 19:00:01 +0000

> Date: Wed, 10 Mar 2010 09:19:48 +0100
> From: Jaap Akkerhuis <[email-masked]>
>     

i agree that that's what people want.  and it's the chief benefit of
"shadow zones" as i've proposed them.  but note, without application
changes or configuration changes, a mail or web server will not be
able to transparently accept connections across names whose only
aliasness/sameness is known by DNS.  so, there's going to be a cost.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 10 Mar 2010 19:03:08 +0000

> Date: Wed, 10 Mar 2010 15:02:30 +0000
> From: Tony Finch <[email-masked]>
> 

anyone still running sendmail 5.61 or king james sendmail, wouldn't.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 10 Mar 2010 16:17:39 -0500

> towards a possible taxonomy of flavors of "the same".

One "variant" issue comes from the failure (of the IETF) to adopt the
intermediate tables meta-proposal from CNNIC engineers in 2001 to fix
problems in Han Unification.

Another "variant" issues comes from a distinct unification, the
creation of "Arabic Script".

So without stepping into the swamp of each, as these arise from
distinct problems, they are distinct "variants" (note the plural), and
may be distinct taxa in a "the same" problem statement.

> Is it possible and useful to build such a taxonomy?

Well, I think there's a risk in assuming that if we solve for SC/TC
equivalence, and for Arabic and non-Arabic equivalences, or just one,
or the other, and claim "done-ness" we'll find not much later that
we're not.

Eric

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Mar 2010 08:27:34 +1100

In message <[email-masked]>, Tony Fi
> In practice all implementations allow MXs to refer to CNAMEs.

Whether they check or not the issue.  RFC5321 still has them as
out of scope.

   When a domain name associated with an MX RR is looked up and the
   associated data field obtained, the data field of that response MUST
   contain a domain name.  That domain name, when queried, MUST return
   at least one address record (e.g., A or AAAA RR) that gives the IP
   address of the SMTP server to which the message should be directed.
   Any other response, specifically including a value that will return a
   CNAME record when queried, lies outside the scope of this Standard.
   The prohibition on labels in the data that resolve to CNAMEs is
   discussed in more detail in RFC 2181, Section 10.3 [38].

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Mar 2010 16:36:46 -0500

> or the other, and claim "done-ness" we'll find not much later that

Well, actually, we shouldn't solve for _either_ of those equivalences.
We can't.  The solutions for those things are above our slot in the
network stack.

But there's still a requirements-gathering task here: how are those
problems being solved or proposed to be solved now; and what, if
anything, would such solutions require from the DNS?  If the answer is
"nothing new", then we know we don't have any work to do.  We have
work to do only if those (and every other problem-solution pair of
this sort we can think of or hear about) need us to make a
modification either to make such solutions possible at all or else to
make them practical to use.

We need to stick, very hard, to our area of competence here.  We are
competent at altering the DNS protocols, adding things to them or
whatever, if that's useful and necessary.  Let's not go beyond what
we're in a position actually to do.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Mar 2010 09:16:56 -0500

No hat.

> Whether they check or not the issue.  RFC5321 still has them as

Well, RFCs aren't scripture.  If we don't like the founding
principles, and everyone in fact ignores them, surely we can change
the rules?  

I do have a doubt about the distance between "in practice all" and
"all".

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 11 Mar 2010 09:20:43 -0500

Andrew,

These are kinds of equivalence. If they are not distinguishable then
there is no value in attempting to create taxa of usecases around
things that can't be distinguished. It is IDNAbis' problem to solve
their problem(s), it is DNSEXT's problem to solve a potentially larger
class of equivalency types.

Eric

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Mar 2010 07:49:12 -0800

>principles, and everyone in fact ignores them, surely we can change

This was, again, a contentious debate. It is not clear that DNSEXT can or should overrule an applications WG that wanted to do something in the DNS in a certain way. It could certainly be appropriate for a DNSEXT-initiated communication to say "that's not helpful, please consider getting rid of it".

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Mar 2010 10:54:49 -0500

> This was, again, a contentious debate. It is not clear that DNSEXT
> can or should overrule an applications WG

Yes, sorry.  To be clear, in that context I meant by "we" "the IETF"
and not "this WG".  The point of what this WG is doing is to specify
the rules for _the protocol_.  Others can make the restrictions they
like on how to use what we specify.  We can offer guidance, but
ultimately we're defining a service for the Internet, which means that
Internet users can use subsets of it as they wish.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Mar 2010 12:49:26 -0500

On Thu, Mar 11, 2010 at 09:20:43AM -0500, Eric Brunner-Williams wrote:
> things that can't be distinguished. 

You are assuming that different kinds of "equivalence" can't be
distinguishable.  That's the premise I reject.

It seems to me that there are some things people want to do right now
for which our answer ought to be, "Yes, that's very hard in the DNS
today.  What you need is a better provisioning tool."  No changes to
the DNS would be needed, and we'd have a problem statement to kick out
to somewhere else -- maybe a new WG, maybe the provisioning Bar BOF
that Ed Lewis is organizing, maybe to purchasing departments for RFPs.
But it would be Not Our Problem, and we'd be able to say why and how
we think that.  Today, we can't, because we haven't covered all the
cases.

Moreover, there are those who claim that _all_ the behaviour we can
think of can be reduced to the above implementation.  I have no idea
whether that's right, yet, again because we don't really have much in
the way of clear, unambiguous statements of what problems are trying
to be solved and what compromises would be acceptable if one needed to
make them.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 11 Mar 2010 13:29:00 -0500

> distinguishable.  That's the premise I reject.

Um... banana peel. I don't know that they can, or can't be, as soon as
we slip out of the IDNAbis set of constraints -- that is, the mappings
between any two code points, and into any two subgraphs and mappings
between them.

It may be that two large ranges of code points, e.g., the SC and TC
ranges, and their pervasive mappings through out all of the string
space used to form labels, and a vastly smaller range of code points,
e.g., the few Arabic variants, found sparcely (and predominantly at
joiner and terminator), that is non-uniformly in the string space, are
dissimilar as universes of from-to mappings. From work in another
discipline (DNA string processing and evolutionary tree space
wandering) it seems possible to me, but I'm wicked busy and all I
wanted to say was
don't-assume-IDNAbis-variants-is-all-that-is-worth-looking-at.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Mar 2010 13:45:03 -0500

> don't-assume-IDNAbis-variants-is-all-that-is-worth-looking-at.

Oh, well, then, I completely agree.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Mar 2010 13:51:01 -0500

At 12:49 -0500 3/11/10, Andrew Sullivan wrote:
>  -- maybe a new WG, maybe the provisioning Bar BOF

That would be: http://www.ietf.org/mail-archive/web/dnsop/current/msg08230.html

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Mar 2010 08:44:47 +1100

> principles, and everyone in fact ignores them, surely we can change

I'm not saying don't change the rules.  It's just that aliases don't
work reliably as the rules are currently written.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 11 Mar 2010 14:21:04 -0800

On 3/10/10 11:00 AM, Paul Vixie wrote:
>  but note, without application changes or configuration changes, a
>  mail or web server will not be able to transparently accept
>  connections across names whose only aliasness/sameness is known by
>  DNS. so, there's going to be a cost.

To help resolve this issue, there is a third-party labeling scheme 
proposed for use with DKIM to confirm domain relationships by a single 
DNS transaction.  Perhaps this approach might better use a specialized 
RR to differentiate it from the TXT related foo.  With proliferation of 
related domains created by IDNA rule-set modifications, perhaps the RR 
should also include an assertion for the level of authorization implied 
by the asserted relationship.

http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03

-Doug

---

From: Brian Dickson <[email-masked]>
Date: Fri, 12 Mar 2010 14:43:49 -0400

[In-line and below quoted, are my responses. - briand]

> "variant problems" than the latter.

I've given it some thought -- see below for more on both the former
and latter...

> Is it possible and useful to build such a taxonomy?

Yes. :-)

At a minimum, it is certainly useful to map out the space, with signs saying
things like, "caution: rathole here", or "here there be dragons".

This can be done by listing what current technology supports (and
examples of problems it provides solutions for),
as well as what categorizations can be anticipated for new problems,
and suggested tools to assist solving those,
and whose responsibility it needs to be to handle the overall problem class.

This is a first kick at this, by no means meant to be comprehensive,
but rather to provide a framework for fleshing this taxonomy out.
The important things are, IMHO, the attributes in the process from
question to answer, below:

Category: Labels (individual labels in a series of labels)

[presentation-layer] input -> [presentation-layer] processing ->
[assert] uniqueness -> {registration, provisioning, operation, or
query} -> {population, dissemination, or lookup/answer} ->
[presentation-layer] use of data, or output

In no particular order:

case "trivial":
input is "any"
processing is "variable"
label variant uniqueness is "N/A - no variants exist"
registration is "variable"
provisioning is "variable"
dissemination is "variable"
(label) lookup is "binary bit-wise comparison"
answer is "as-is"
presentation is "variable"

case "classic":
input is ASCII letters/digits/hyphens (LDH)
processing is "none"
label variant uniqueness is "not permitted - only one variant on
combinations of letter case (UC/LC) may exist"
registration is "validate uniqueness by ASCII case-insensitive match
against registry"
provisioning is "as-is"
dissemination is "as-is"
(label) look-up is "case-insensitive"
answer is "as-is from question" (rather than as-is from dissemination)
presentation is "as-is"
caveat -- the "case-insensitive" lookup, and lack of processing on
input, is both necessary and reasonable, because the ASCII character
set was designed for this, and because instantiating the
case-sensitive equivalents requires 2^N (roughly) labels for labels of
length N.

<Commentary on "new" cases>
Overlapping boundaries for languages, character sets, and countries,
as well as authorities for these and variants and subsets of each,
make it a big problem to try to establish universal rules or even
conditional/contingent rules.
This can be illustrated by a few examples:
Character sets shared by multiple languages: Cyrillic, Nordic, Romantic
Languages (with significant differences in dialect) shared by multiple
countries, or even provinces/states/regions within countries: English,
French, Spanish, many others
Countries with multiple languages: Canada, USA (unofficial),
Switzerland, many many others
This is further compounded by TLDs which may encompass all these
boundaries (the generic TLDs, sponsored TLDs, etc.), each of which may
have different rules regarding "equivalent" labels (allowed or not,
bound together to same registration or not, partial or full label
applicability of these rules, etc.)

These can be classified based on the attributes regarding label
variant uniqueness, the corresponding provisioning and dissemination,
and whether variants get bound together (to the same single
registration).
If we can provide mechanisms for the association of bound-together
labels, so that their equivalence results in complete functional
identity, then we can avoid encumbering the "look-up" with any
additional rules.
This will presumably necessarily involve an additional burden on the
"input"/"processing" side, in cases where some classes of label
variant uniqueness is required.
<end Commentary on "new' cases>

case "Limited character variants":
Example: Greek "tenor" and "sigma"
input is "any"
processing is "remove tenor and signma" to normalize input (to both
query and provisioning/dissemination systems)
label variant uniqueness is "not permitted"
provisioning is "normalized"
dissemination is "normalized"
(label) look-up is "case-insensitive"
answer is "as-is from question"
presentation is "as-is" (or de-normalized to match input?)
NB -- avoids new/additional special handling of limited character
variants, places that burden on IDN side of things

case "Limited in-language, in-country, in-TLD variants":
Example: UK-english obsolete/obfuscated/deprecated words vs current
words - "gaol" vs "jail"
input is "any"
processing is "variable"
label variant uniqueness is "variable"
provisioning is dependent on label variants, and "variable" - could be
transparent, or non-transparent, with or without label variants, with
or without binding between variants.
NB -- let TLD/registry handle this, stick to support for label "bound
together" support if needed by TLD
NB -- possibly handled by published "dictionary" of such labels/words,
including which way each is handled (CNAME or bound variants)

case "Limited in-country, cross-language variants":
Example: Canada (esp. government)
Label variant uniqueness is "variable"
provisioning dependent on label variants - could be bound label
variants, or even combined variants with CNAMEs from individual
variants, like "A" CNAME "A-B", "B" CNAME "A-B", "A-B"
published/provisioned.
NB -- let TLD/registry handle this, stick to support for label "bound
together" support if needed by TLD
NB -- possibly handled by published "dictionary" of such labels/words,
including which way each is handled (CNAME, bound variants, or
combined variants with CNAME)

Category: Series of Labels (one or more labels)

Currently, we have CNAME (including possible CNAME chains), and DNAME.
There are proposals for BNAME, and for "shadow zones".

Problem statement: binding together (atomically and transparently)
multiple labels in the same zone, is not currently possible, and is a
huge rat-hole, as it would necessitate much ugly difficult change to
DNS, i.e. it would require DNSng.

Problem statement: binding together multiple labels from different
zones is currently not transparent, and in some cases not possible.

Observation: Limiting binding together of label series', to situations
where all such label series are delegated to the same zone (zone
cut/zone apex), may change the problem from intractable to feasible

Observation: Unifying multiple delegated zones (atomically) requires
only a means of identification of the "sameness" of a zone as having
multiple such identities, at the zone apex.

Possible proposed solution: additional RR at apex of zone, identifying
zone "aliases", and possibly disambiguating other zone-specific
RR/RDATA, e.g. whatever is needed for DNSSEC to work, i.e. with
multiple trust anchors above the zone.

Comments/thoughts?

Sorry for the length, and please feel free to add to the taxonomy or
point out problems, errors, omissions, or caveats.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Fri, 12 Mar 2010 21:03:43 -0400

> multiple trust anchors above the zone.

Sorry to follow up on my own email, but I think there's a simple question,
to which the answer isn't obvious, but for which the answer is crucial:

Is there any new problem introduced on a given authority server, if a zone
cut is created (and where the same server serves the new subordinate zone)?

I.e. Is it reasonable to require a given label, in a zone, to be a
zone cut boundary,
in order to solve some other problem (e.g. BNAME/CNAME/DNAME/ZCLONE)?

Brian