Subject: [EAI] Internationalized email addresses in vCard 4.0

From: Simon Perreault <[email-masked]>
Date: Fri, 05 Nov 2010 09:55:32 -0400

Hello,

We need some advice from the EAI working group.

vCard 4.0 is a file format for contact information. It's a textual
format and its character set is always UTF-8. One of the information
items it may contain is email addresses. See here:
http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13#section-6.4.2

Basically to list an email address in a vCard you will have a line
looking like this:

EMAIL:[email-masked]

The ABNF for what comes after the colon is "addr-spec", which is defined
in RFC 5322, section 3.4.1.

Now, addr-spec does not allow full Unicode. An internationalized address
would need to be EAI/IDN-encoded, which implies that a vCard app would
need to decode it to display it to a user.

Questions:
- Is this the right way to do it?
- Should we allow full Unicode, which removes the need for decoding from
the vCard app and adds the need for encoding in the MUA?
- Should both forms be possible, should one form be preferred over the
other, or should only one form be allowed?
- What should the ABNF look like for allowing Unicode characters in
email addresses?
- Would it help us in any way if we were to specify a mailto: URL instead?

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Nov 2010 18:41:44 -0400

--On Friday, 05 November, 2010 09:55 -0400 Simon Perreault
<[email-masked]> wrote:

> vCard 4.0 is a file format for contact information. It's a
> textual format and its character set is always UTF-8. One of
> the information items it may contain is email addresses. See
> here:
> Basically to list an email address in a vCard you will have a
> line looking like this:
> 
> EMAIL:[email-masked]
> 
> The ABNF for what comes after the colon is "addr-spec", which
> is defined in RFC 5322, section 3.4.1.
> 
> Now, addr-spec does not allow full Unicode. An
> internationalized address would need to be EAI/IDN-encoded,
> which implies that a vCard app would need to decode it to
> display it to a user.

Except that you misunderstand what "EAI/IDN encoding". I would
strongly suggest that you have a look at the EAI drafts and that
you deal with this by replacing the 5322 addr-spec with the EAI
equivalent.  Otherwise, you are just going to create trouble for
yourselves and your users.

> - Is this the right way to do it?

Nope.  See above.

> - Should we allow full Unicode, which removes the need for
> decoding from the vCard app and adds the need for encoding in
> the MUA?

No, and you are asking the wrong question.  See above.

> - Should both forms be possible, should one form be
> preferred over the other, or should only one form be allowed?

What "both forms"?

> - What should the ABNF look like for allowing Unicode
> characters in email addresses?

See above.  Your one problem is that you will end up with a
normative reference with a spec that isn't finished yet.  The
good news is that I hope and expect to have it wrapped up well
before the end of the calendar year.

> - Would it help us in any way if we were to specify a mailto:

Arggh.  Translation: certainly not unless you want to wait for
the EAI WG to finish its review of mailto, which has not really
begun yet.

     john

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 06 Nov 2010 01:03:10 +0100

>yourselves and your users.

I haven't been paying attention for some time, but trying now, I could
not find that equivalent (I went to the Working Group homepage and
clicked through a couple of drafts, grepped the RFC index for "email"
and "e-mail", particularily scanned for some ABNF in RFC 4952, none of
which turned up anything useful within five minutes. Then I went to
Wikipedia, which only references RFC 5335 on "Internationalized Email
Headers" which didn't seem that relevant, but if you scroll way down
there, there is "utf8-addr-spec"; if that is the definition you mean,
then the definition does not really make sense to me; I would expect
e-mail addresses to be composed of characters, not sequences of bytes.)

I think it would be a good idea to have a Internationalized Email Ad-
dresses RFC that defines the syntax and semantics of addresses, and
does so in terms of characters, not bytes (and naturally does not de-
fine headers, mail protocol extensions, and so on). That specification
might then also address how other protocols are to use said addresses.
For what it is worth.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Yangwoo Ko <[email-masked]>
Date: Sat, 6 Nov 2010 09:57:45 +0900

Pleae refer to https://datatracker.ietf.org/doc/draft-ietf-eai-rfc5335bis/

On Sat, Nov 6, 2010 at 9:03 AM, Bjoern Hoehrmann <[email-masked]> wrote:

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

-- 
a human / twitter as yangwooko / msn as [email-masked] / nate as
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Sat, 06 Nov 2010 12:11:30 -0400

John C Klensin wrote, on 11/05/2010 06:41 PM:
> I would

To be clear, does "the EAI equivalent" stand for uAddr-spec, as defined in
<http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-03#section-4.4>?

> Your one problem is that you will end up with a

Got it, thanks. We'll certainly be discussing this in our WG meeting...

Simon

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Nov 2010 14:05:37 -0400

--On Saturday, 06 November, 2010 12:11 -0400 Simon Perreault
<[email-masked]> wrote:

>> strongly suggest that you have a look at the EAI drafts and
>> that you deal with this by replacing the 5322 addr-spec with
>> the EAI equivalent.  Otherwise, you are just going to create
>> trouble for yourselves and your users.
> 

Yes, with the qualification that, like all WG I-Ds, this is a
moving target and might change before it is approved.  I
wouldn't personally expect that, but you shouldn't take my
belief as a guarantee.

    john