AW: sharp s (Eszett)

Patrik Fältström patrik at frobbit.se
Mon Mar 10 19:10:08 CET 2008


On 10 mar 2008, at 13.53, Jelte Jansen wrote:

> it would still be represented back
> to the user as a sharp s, if that is what they've entered

I would like to dive in a bit into this, with "represented back to the  
user"...

We have a few things that we have to look at, and maybe we who write  
the documents have not explain this enough in detail:

When looking things up in DNS, this is really a lookup. You send in a  
key, and get data back. Nothing more nothing less.

One send in for example {a.b.c,IN,A} and get back 1.2.3.4

To get something back, what the user "send" must "match" what is  
stored in the DNS. This implies we must define what "send" implies and  
what "match" implies.

"match" is defined by the base DNS RFCs. The comparison is byte by  
byte, with the exception of 0x41 - 0x5A that is to match 0x61 - 0x0x7A  
respectively (case insensitivity if one treat the bytes as ASCII  
characters).

"send" implies according to what I feel we talk about today, a mapping  
from what the user "type" to some unicode string, then encoding in  
punycode if all rules pass with green light.

If a matches b, and a is registered in the DNS, then b must be mapped  
to a before the actual DNS lookup is done.

What is actually used when looking up things in DNS is _never_  
displayed to the user.

What CAN happen though is of course the following:

User types a.b.c.

a.b.c is mapped to d.e.f.

d.e.f is looked up in DNS, and 1.2.3.4 is returned.

(note that d.e.f is not known to the user, the user "looked for a.b.c").

4.3.2.1.in-addr.arpa is looked up, and d.e.f is returned.

d.e.f is displayed to the user, and d.e.f is NOT the same as a.b.c  
according to what the user think.

This is very similar to the "normal" FQDN issues when one have virtual  
domains on a host where the PTR record for the IP address of the host  
give information about the hostname itself. So this I feel is sort of  
not a new problem.

But it is not really a "inverse" transaction in the database, it is  
from a DNS point of view also a lookup.

Now, if we have a mapping from ß -> ss, then people can still look up  
ß.de. But what is stored in the DNS is ss.de. Sure, the PTR for  
1.2.3.4 will be ss.de, not ß.de, but, it might even be  
"srv031.hosting.com".

So, what do you really mean when you say "represented back to the user"?

     Patrik



More information about the Idna-update mailing list