Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?)

From: Shawn Steele <[email-masked]>
Date: Sat, 22 Jan 2011 22:54:44 +0000

> >          So, the core suggestion is to have the revision focus
> >          only on the existing, basic 5322 ABNF constructs and
> >          simply augment them to support UTF-8.
> >...

> I can live with this approach.  If it is adopted, I'll help sort out the domain name part.

As mentioned, IMO, the domain part should "just" say UTF-8 as well, though it's fair to point out the dependencies on existing RFCs that define DNS.  DNS is a bit trickier than the other headers because we explicitly want to disallow the punycode I think, and require UTF-8 U-Labels instead.

-Shawn

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 23 Jan 2011 08:16:09 -0800

On 1/22/2011 2:54 PM, Shawn Steele wrote:
> As mentioned, IMO, the domain part should "just" say UTF-8 as well, though
> it's fair to point out the dependencies on existing RFCs that define DNS.
> DNS is a bit trickier than the other headers because we explicitly want to
> disallow the punycode I think, and require UTF-8 U-Labels instead.

(disclaimer: I remain tentative aboout discussing anything in the IDN realm, so 
when -- not if -- I get an issue wrong, please be gentle...)

I think the modification for domain name pertains to the <dot-atom> rule.

It's temping to do an incremental enhancement to it that is similar to the other 
proposed UTF-8 additions, but of course IDN is rather more complicated.

So it's tempting to just do something like:

    dot-atom = <u-label>

if there were such an ABNF rule already defined.  Worse, the definition of 
<u-label> is not simple.  It is another case of defining things as "not ASCII" 
rather than as "UTF-8".  It's requirement that the string have at least one 
character above x07f makes it a less usable construct for our purposes than one 
might have expected.

I have not found any ABNF that covers the legal domain name characters for 
"native" UTF-8.  I believe that rule needs to be defined and then we should use 
it directly.

Since we are specifying a relatively clean UTF-8 environment, we should probably 
try to avoid UTF8-over-ASCII encoding mechanisms, if that's reasonable.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net