Subject: [EAI] draft-ietf-eai-utf8headers-01.txt question

From: Kari Hurtta <[email-masked]>
Date: Sat, 14 Oct 2006 12:36:30 +0300 (EEST)

draft-ietf-eai-utf8headers-01.txt:

   angle-addr     =  [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS]

   alt-address    =  "{" [CFWS] addr-spec [CFWS] "}"

RFC 2822:

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

atext           =       ALPHA / DIGIT / ; Any character except controls,
                        "!" / "#" /     ;  SP, and specials.
                        "$" / "%" /     ;  Used for atoms
                        "&" / "'" /
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "{" /
                        "|" / "}" /
                        "~"

atom            =       [CFWS] 1*atext [CFWS]

dot-atom        =       [CFWS] dot-atom-text [CFWS]

dot-atom-text   =       1*atext *("." 1*atext)

draft-ietf-eai-utf8headers-01.txt:

  utf8-addr-spec =  utf8-local-part "@" utf8-domain

  utf8-local-part=  utf8-dot-atom / quoted-string / obs-local-part

  utf8-domain    =  utf8-dot-atom / domain-literal / obs-domain

  utf8-atext   =  ALPHA / DIGIT /
                   "!" / "#" /     ; Any character except
                   "$" / "%" /     ; controls, SP, and specials.
                   "&" / "'" /     ; Used for atoms
                   "*" / "+" /
                   "-" / "/" /
                   "=" / "?" /
                   "^" / "_" /
                   "`" / "{" /
                   "|" / "}" /
                   "~" /
                   UTF8-xtra-char

   utf8-atom     = [CFWS] 1*utf8-atext [CFWS]

   utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS]

   utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext)

"{" adn "}" are on utf8-addr-spec and addr-spec because they
are on atext and utf8-atext.

How is is possible to parse this if CFWS  is optional  around 
"{" and "}" characters (alt-address)  ?

Seems that this requires parser which tries all possible parsing trees
(with backtracking) and still it can got be several different 
interpretations.

To parse that "{" and "}" are needed to remove from dot-atom and
utf8-dot-atom.

Alternatively   "{" need to be changed to " { " and "}" to " } ".

Then there is not pissble for several parsing trees (because 
between utf8-atext elemens and between atext elements "."
character is required -- backtracking may be still needed on 
parser however.)

/ Kari Hurtta

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Jeff <[email-masked]>
Date: Wed, 18 Oct 2006 18:24:18 +0800

> Alternatively   "{" need to be changed to " { " and "}" to " } ".
Thanks for your comment.
How about use "[" and "]" as the bracket?
This was discussed before. (Thanks Charles and Tony.)
That is :
alt-address = "[" [CFWS] addr-spec [CFWS] "]"

Jeff
-TWNIC

---

From: John C Klensin <[email-masked]>
Date: Wed, 18 Oct 2006 14:09:00 -0400

> alt-address = "[" [CFWS] addr-spec [CFWS] "]"

Hi.

Maybe it is no longer relevant today, but "[" and "]" were
excluded from the original characters permitted in email
addresses (and lots of other places) because it is in a
national-use position in ISO 646 BV.  Should it displayed by an
ISO 646 rendering engine in a country that uses those positions,
the output could be very strange indeed (the UTF-8 showing up as
boxes or question-marks and the brackets and nationally-selected
characters).

It may still be a good choice, but we should understand the
implications of what we are doing.

   john

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 21 Oct 2006 21:53:24 +0300 (EEST)

>>> John C Klensin

> implications of what we are doing.

I'm not sure that I understand.  [ ] are definately used on
e-mail address.

RFC 2822:

domain-literal  =       [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

These are rare, but seen.

/ Kari Hurtta

PS.   If I remember correctly, in Finnish/Swedish ISO 646 variation these was
              [ => Ä
	      ] => Å
	      \ => Ö

      or something like that.

---

From: John C Klensin <[email-masked]>
Date: Sat, 21 Oct 2006 15:32:09 -0400

--On Saturday, 21 October, 2006 21:53 +0300 Kari Hurtta
<[email-masked]> wrote:

>> national-use position in ISO 646 BV.  Should it displayed by
>> an ISO 646 rendering engine in a country that uses those
>> positions, the output could be very strange indeed (the UTF-8
>> showing up as boxes or question-marks and the brackets and
>> nationally-selected characters).
>> 

Yes.  But we strongly discourage domain literals, and that
doesn't make it a good idea.  I want to stress that I don't
consider it a showstopper either, but we should not walk into
this without consideration of the implications.

> These are rare, but seen.

Less rare than one might like.

> PS.   If I remember correctly, in Finnish/Swedish ISO 646
> variation these was               [ => Ä
> 	      ] => Å
> 	      \ => Ö

>       or something like that.

That sounds about right.

    john

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 22 Oct 2006 06:23:51 +0200

Kari Hurtta wrote:

  [John wrote]
>> the output could be very strange indeed

Why would a box in a museum try to display raw UTF-8 header fields
with an optional <alt-address> enclosed in curly braces or square
brackets ?

The historical issue is the same, in C it got us ??(, ??<, ??), ??>
among others.  Here's the German version (ISO 646-DE or DIN 66003):

http://www.mi.uni-koeln.de/c/mirror/www.kostis.net/charsets/iso646.de.html

I've never seen it anywhere in practice.  I don't see how it could
affect UTF-8 headers, but if it does then [\] aren't worse than {|}.

Frank