RE: [idn] IDNs in email message bodies

["Brian W. Spolarich" <briansp@walid.com>]

  [I deleted paf's message so I'm replying to it here]

| Patrik Fältström <paf@cisco.com> wrote:
|
| > the application which put things in the clipboard buffer should do it
| > in the ace encoding
|
| I disagree for two reasons.  First, if I highlight Japanese text and it
| gets transformed into ACE when I pasted it, I'm going to be surprised
| and annoyed.  Second, what you propose is simply impossible in many
| cases.  For example, my MUA is Mutt running inside an xterm.  Mutt
| has no control over how copying and pasting happens, because it's all
| handled by xterm.

  I disagree with Patrik as well.  Doesn't IDNA basically say that
applications should do this sort of thing:

  if ( isRFC1035(domain_name)) {
	doDNSOperation(domain_name);
  } else {
	ace_domain_name = IDNify(domain_name);
	doDNSOperation(ace_domain_name);
  }

  sub IDNify (domain_name) {
	if (! isUnicode(domain_name) {
		domain_name = convertToUnicode(domain_name);
	}
	domain_name = doNameprep(domain_name);
	domain_name = convertToACE(domain_name);
  }

  Meaning that only when you may have to call the 'doDNSOperation'
mythical function do you need to worry about the IDN issues.

  In addition, user applications need to worry about IDN display
issues, but again only in the context where you may do an
operation on the name as a protocol element.

  Perhaps that's a good working definition:  IDNs as protocol
elements MUST be in nameprepped ACE, otherwise they're just
data.  In addition, user agents SHOULD display IDNs in protocol
element contexts in native characters.