exact match vs mapping

[Erik van der Poel]

Hi all,

Thanks for the meetings. After the 2nd meeting, Pete Resnick and I
discussed a "layer" model that is probably already familiar to most of
us, but it raises an interesting question that I thought I'd pose to
the mailing list.

We have often talked about protocol "stacks" where e.g. HTTP sits on
top of TCP, which sits on top of IP, and so on. In our IDNA
discussions, we have often talked about the HTML stack and the email
stack. If we take these stacks to their logical extreme, they would
include the human user at the top:

human user
email app
message body
822 header
SMTP envelope
TCP
IP

This is a very rough description of the stack, and I realize that SMTP
goes back and forth between client and server, but, I hope you get the
general idea. So far, my assumption has been that SMTP extensions
would probably want to use U-labels. I have no idea what people are
thinking for the 822 header. (John?)

The Web stack might look like this:

human user
Web app
HTML/IRI/IDNA2003
HTTP/URI/DNS
TCP/UDP
IP

Now, one of the issues with IDNA2008 is whether or not to include
mapping as a MUST. Of course, one way to do this is to have a separate
RFC for mapping, and have the main IDNA protocol refer to the mapping
spec, saying that the mapping must occur "somewhere" in the stack
above. It sounds like some of the WG members would like to "push" the
mapping all the way up the stack to the app (in the UI, immediately
after keyboard or other entry).

But we have also talked about "getting the user used to lower-case in
the DNS" (by displaying in lower-case, etc). So my question is: What
is the goal of IDNA? Is it a goal to have software map non-ASCII
characters to lower-case to simulate traditional DNS behavior with
ASCII strings? Or is it a goal to teach the user to enter lower-case
in the first place (effectively pushing the lower-case mapping all the
way up to the human brain)?

I'm just wondering whether we're disagreeing on the goals of IDNA, and
that that might be one of the reasons for the delay.

Erik