Subject: [ietf-dkim] Internationalized domain names

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Jul 2006 17:25:15 -0700

Eric added the following to base-04:
        Internationalized domain names MUST be punycode-encoded
        [RFC3492].
This is very wrong. The Punycode encoded value does not include the 
"xn--" string.

The text should instead read:
        Internationalized domain names MUST be converted using
        the  steps in section 4 of [RFC3490] using the ToASCII
        function.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jul 2006 09:30:48 -0700

>        the  steps in section 4 of [RFC3490] using the ToASCII

Agreed.

Calling this an ACE label which is identified by the "xn--" prefix  
may avoid some of the confusion.

This could also be written as:

  Internationalized domain names MUST be converted using the
  steps in section 4 of [RFC3490] into "ACE" labels using the
  ToASCII function.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Jul 2006 10:29:31 -0700

>  steps in section 4 of [RFC3490] into "ACE" labels using the

No, that's wrong: only the labels that have non-LDH characters are 
converted. Section 4 in IDNA covers this correctly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jul 2006 16:08:48 -0700

> converted. Section 4 in IDNA covers this correctly.

Good point, but not exactly right either.  A term for international  
domain names encoded into ACE labels would provide a useful  
reference, rather than calling this puny-code.  The '_' underscore  
character is also not one of the 37 case-insensitive LDH (letter,  
digit, or hyphen) characters either, but the intent is not to include  
this label within this requirement.  While domain name encoding is  
specifically mentioned with the i= parameter where there are  
essentially no character restrictions for subdomains, this statement  
also applies to the d= tag as well.

Perhaps:

  Internationalized domain names MUST be converted using the
  steps in section 4 of [RFC3490] into "ACE" labels when
  appropriate by applying the ToASCII function for "stored stings."
  This requirement does not apply to the "_domainkey" label.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Jul 2006 16:20:28 -0700

At 4:08 PM -0700 7/19/06, Douglas Otis wrote:
>Good point, but not exactly right either.

Please show *exactly* where the following is "not exactly right":
        Internationalized domain names MUST be converted using
        the  steps in section 4 of [RFC3490] using the ToASCII
        function.

>A term for international domain names encoded into ACE labels would 
>provide a useful reference, rather than calling this puny-code.

The proposed text does not use the term "puny-code".

>The '_' underscore character is also not one of the 37 
>case-insensitive LDH (letter, digit, or hyphen) characters either, 
>but the intent is not to include this label within this requirement.

Correct, and irrelevant.

>   While domain name encoding is specifically mentioned with the i= 
>parameter where there are essentially no character restrictions for 
>subdomains, this statement also applies to the d= tag as well.

Correct, and irrelevant. You cannot use "_" in labels in domain names 
in either i= or d=.

>  This requirement does not apply to the "_domainkey" label.

No. Changing a simple, correct statement into a confusing one with 
new terminology is a bad practice. Please stop.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jul 2006 22:01:08 -0700

On Jul 19, 2006, at 4:20 PM, Paul Hoffman wrote:

>>> No, that's wrong: only the labels that have non-LDH characters  
>>> are converted. Section 4 in IDNA covers this correctly.
>>

The term "internationalized domain name" covers more than just unicode.

Per RFC3490:
,--
| An "internationalized domain name" (IDN) is a domain name in which
| every label is an internationalized label.  This implies that every
| ASCII domain name is an IDN (which implies that it is possible for a
| name to be an IDN without it containing any non-ASCII characters).
'__

Without reviewing the mapping of the ASCII code points, limitations  
expressed by this statement are not apparent and further depend upon  
several other documents.  In addition, few are as familiar with IDNA  
as you, being one of the authors.  This IDNA spec defines the  
operation of a translation shim between an application and underlying  
infrastructure dependent upon how the string is used.  Technically,  
this IDNA RFC has little to do with DKIM and offers an awkward way to  
define a character set and a domain label limitation without further  
clarifications.  A concise way of expressing this definition is to  
provide the ABNF character set permitted for use within the i=  
parameter.  When the d= parameter is an IDN, it does not matter with  
respect to the function of DKIM and is completely irrelevant.

Unfortunately label definitions within STD13 (RFC1034) have changed  
somewhat.  The current sub-domain ABNF referenced from RFC2821  
appears to be insufficient, however an IDN represents just a sub-set  
of this definition.  It would also appear on closer review, the  
RFC3490 reference offers little additional clarity.  DKIM should  
better define the sub-domain ABNF instead.

ABNF:

letter = %x41-5A | %x61-7A ; A-Z | a-z
digit  = %x30-39 ; 0-9
hyphen = %x2D ; "-"
ldh = letter | digit | hyphen
let-dig = letter | digit
sub-domain =  let-dig [*61 ldh let-dig]

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Jul 2006 10:50:13 -0700

At 9:57 AM -0700 7/20/06, Douglas Otis wrote:
>A follow-on:

-1. We should not be thinking about changing IDNA or RFC 2822 in the DKIM WG.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Jul 2006 14:36:21 -0400

> We should not be thinking about changing IDNA or RFC 2822 in the 
> DKIM WG.

The chairs agree, and the chairs also note that, related to this, we 
have said that we will also mostly not be thinking about how to work 
with EAI here.  I say "mostly" because there's a likely outcome for much 
of what EAI's doing, and we shouldn't make changes to DKIM that will 
interoperate badly with that outcome.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Jul 2006 13:11:25 -0700

On Jul 20, 2006, at 11:36 AM, Barry Leiba wrote:

> The chairs agree, and the chairs also note that, related to this,  
> we have said that we will also mostly not be thinking about how to  
> work with EAI here.  I say "mostly" because there's a likely  
> outcome for much of what EAI's doing, and we shouldn't make changes  
> to DKIM that will interoperate badly with that outcome.

The suggested change does not affect RFC2822 or IDNA.

The DKIM base draft has a rather fundamental problem.  The definition  
for sub-domain is both insufficient and erroneous.  Also there is no  
requirement for DKIM to even mention IDNA, nor does this reference  
add any requisite definitions pertaining to DKIM.  IDNA defines a  
process for converting between Unicode strings for visual display and  
host or domain name suitable strings.  DKIM will _never_ perform any  
of these conversions.  Unless there is some process that detects  
invalid ACE labels, which does not appear to be defined in RFC3490,  
there is no reason to even mention this document.  IDNA is required  
when defining MUA interaction with DKIM information, which is  
excluded from the DKIM base.  The need to specify label length could  
be seen as having increased importance in regard to the i=  
parameter.  When i= sub-domains are used, there are no other check  
made on the validity of these labels.

----------
Remove:

2.5  Imported ABNF Tokens
  RFC2821 sub-domain token reference

References to RFC3492 following i= and d= signature tag definitions:

-----------
Add (prior to or in Section 3):

  ABNF:

  hyphen = %x2D ; "-"
  ldh = ALPHA | DIGIT | hyphen
  let-dig = ALPHA | DIGIT
  sub-domain =  let-dig [*61(ldh) let-dig]

----------
----------

As reference:
(The referenced ABNF used in the DKIM base.)

RFC2821:

Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
sub-domain = Let-dig [Ldh-str]

-----

RFC1034 (STD13):

The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>

-----

ICANN/IANA: (the wild)

Consistent example of current domain name policy:
http://www.iana.org/cctld/specifications-policies-cctlds-01apr02.htm

alpha = %x41-5A / %x61-7A ; A-Z / a-z
digit = %x30-39 ; 0-9
ldh = alpha / digit / dash
id-prefix = alpha / digit
label = id-prefix [*61ldh id-prefix]

-Doug