Subject: [dnsext] Name equivalence - thoughts on the Greek issue

From: Brian Dickson <[email-masked]>
Date: Mon, 13 Sep 2010 13:35:01 -0300

In the case of the Greek characters and the need for "equivalence", this
might be one area to push back to the IDN folks.

Here's what occurs to me:

The encoding used for some subset of IDNs might better be done to make use
of the case-insensitive nature of ASCII, whose case insensitivity is already
fundamentally embedded in DNS.

For instance, if the encodings of a specific character, with and without
some special property unique to the language/script of its origin (such as
Greek "tonos"), were to differ only in the ASCII case of the encoding
itself, the problem goes away by virtue of DNS case insensitivity.

This would require (some) encodings that on a per-character basis are
byte-aligned, meaning each original character becomes an integer number of
characters.
Potentially, If there are more than 36 characters in the original script, or
more than 26 that differ by property, then the result could be doubling of
the length of the label (plus 4 characters for new ACE prefix).
The savings would be that there would no longer be a requirement to have
"the same" work done to augment DNS.
And, it would only require one DNS label to handle all the constituent
variants within the label.

This would either have to be done with a unique ACE prefix for each such
language/script, or with a new ACE prefix with enough encodings for all the
covered language/scripts.

Done right, this could also accommodate case plus another property, so four
variations per "symbol" could be encoded using case.

E.g. if there were 36 characters in a particular language, no more than 26
which had a "property bit" and a "case bit", then "foo" maps to "aa", and
the first "a" is the "property bit" significator, and the second "a" is the
character+case.
Then "Aa" is "foo with property, lower case", "aA" is "foo without property,
upper case", "AA" is "foo with property, upper case".
The shortest label would be $IANA--aa (e.g. "gr-aa"), for a single-character
label.

NB: What the property bit is may differ by character in the original
language, and/or context of usage.
E.g. It is my understanding that the greek sigma could be upper/lower, or
terminal/non-terminal, but not both, so while it may be context dependent,
it is consistently deterministic from a mapping perspective, based on that
context.

The rest of RFC 3490 and RFC 3492 would need to be -bis'd to handle the
additional logic and ACE prefix(es).
E.g. "If all (one-script) then (use specific ACE prefix and mapping) else
(use standard "xn--" prefix and mapping).". The reverse mapping would
obviously be completely deterministic, based on the ACE prefix.

It might not make us popular with the IDN folks, but I bet it would be well
received by those using such scripts...

Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Sep 2010 12:54:55 -0400

> byte-aligned, meaning each original character becomes an integer number of

Uh, I think (1) that this is now well into the weeds for this
discussion and (2) you seem not to be attending to the unhappy fact
that IDNA2008 is all based on UTF-8, and that that bears with it a
large number of issues having to do with Unicode and the way it
happened to develop, historically speaking.

Moreover,

> additional logic and ACE prefix(es).

your targets are wrong.  The present discussion has been inspired
primarily by the effects of obsoleting 3490 and updating 3491.  One of
those effects was to remove all the mapping from the protocol.

A

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

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Sep 2010 18:10:21 +0100

--On 13 September 2010 13:35:01 -0300 Brian Dickson 
<[email-masked]> wrote:

> byte-aligned, meaning each original character becomes an integer number
> of characters.

(unicode use on my mailer is untested, so bear with me).

I am not sure this is always true. Consider the sequences "oe" and œ
(that's meant to be LATIN SMALL LIGATURE OE' (U+0153), an "o" and an "e"
joined together). Or "fl" and "ﬂ" (that's meant to be "LATIN SMALL
LIGATURE FL" (U+FB02), an "f" and an "l" joined together). Two characters
could have a single equivalent unicode character.

With apologies to Butler Lampson, I propose, on the basis that all
problems in computer science can be solved by an additional
layer of indirection, MOSTLY IN JEST, the generalised SED
script record, to be applied on a per label basis when translating
UNICODE names:

$ORIGIN foo.
	.	IN	SED	"s/ﬂ/fl/g;œ/oe/g;"
	oefloe	IN	NS ns.example.com.

$ORIGIN oefloe.foo.
	.	IN	SED	"s/ﬂ/fl/g;œ/oe/g;"
	www-oe	IN	A	192.200.0.1

(obviously please fix with appropriate escape chars)

nameprep works on a label by label basis from RHS to LHS. At some
early point in processing each label, the SED record for the domain formed
by the already processed rightward labels is looked up, and the sed
string applied. Apart from its type, the SED record is just like
a TXT record.

So in the above, when looking up www-œ.œﬂœ.foo. example nameprep is 
first
done on foo, leading to "foo", then on "œﬂœ.foo." leading to a SED
query for foo., then to "oefloe.foo.", then a nameprep on on "
"www-œ", leading to a SED query for oefloe.foo. and "www-oe.oefloe.foo".

This generalises to support all other forms of equivalence e.g.
$ORIGIN foo.
	.		IN	SED	"s/^onename$/anothername/g;"
	anothername	IN	NS ns.example.com.

Because, if we can get DNS to do SRV records, geolocation, security
and spam filtering, surely we should be able to get it to do arbitrary
string replacement too? draft-01 will contain a full implementation
of emacs in DNS :-)

-- 
Alex Bligh

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Sep 2010 10:41:38 -0700

At 1:35 PM -0300 9/13/10, Brian Dickson wrote:
>It might not make us popular with the IDN folks, but I bet it would be well received by those using such scripts...

This seems to make the assumption that the IDN folks did not consider this topic for the original IDNA spec or the new one. If so, that assumption is very, very wrong.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Sep 2010 19:12:36 +0100

On Mon, 13 Sep 2010, Alex Bligh wrote:
> layer of indirection,

That was David Wheeler, not Butler Lampson.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.