Subject: [EAI] IETF 79 - EAI Agenda

From: Joseph Yee <[email-masked]>
Date: Thu, 28 Oct 2010 13:34:13 -0400

All,

The following link has the draft agenda for the upcoming session at IETF79.

http://www.ietf.org/proceedings/79/agenda/eai.txt

Please let us know by Nov 1 for any change.

Thanks.
Joseph
EAI co-chair

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 30 Oct 2010 12:10:22 +0900

Hello Joseph,

> http://www.ietf.org/proceedings/79/agenda/eai.txt

Thanks for preparing this. My comments are all related to mailto.

First, I note that your agenda mentions 'mailto' twice, first under
    5. Other documents
and then separately again as
    6.  Discussion of i18n MAILTO plan
I suggest it might be easier to merge these two items.

Second, RFC 6068 (http://tools.ietf.org/html/rfc6068) was just published 
this month. But I'm happy to work on an update if necessary. I have 
cc'ed my co-authors to check whether they would also be happy to 
continue as co-authors.

In terms of I18N, RFC 6068 is a big progress over RFC 2368. It allows 
non-ASCII content in any headers (where the header itself allows that) 
and in the body (via the generic UTF-8-based percent-encoding). This is 
already widely supported by many (though not all) MUAs.

It also allows percent-encoding in the domain-name part of an 
<addr-spec>, which an MUA can transform into punycode. It also contains 
a 'forward-compatible' provision for the LHS of mail addresses:

    5.  Percent-encoding of non-ASCII octets in the <local-part> of an
        <addr-spec> is reserved for the internationalization of the
        <local-part>.  Non-ASCII characters MUST first be encoded
        according to UTF-8 [STD63], and then each octet of the
        corresponding UTF-8 sequence MUST be percent-encoded to be
        represented as URI characters.  Any other percent-encoding of
        non-ASCII characters is prohibited.  When a <local-part>
        containing non-ASCII characters will be used to compose a
        message, the <local-part> MUST be transformed to conform to
        whatever encoding may be defined in a future specification for
        the internationalization of email addresses.

The minimum change to make RFC 6068 work with EAI would be to change the 
language around 'reserved' and point to the relevant EAI RFC(s). I can 
submit an Internet-Draft for this as soon as Monday of the IETF, either 
as an individual draft or as a WG draft. Please tell me which name to use.
[The WG and the community could even decide that implementers can figure 
this out by themselves, and that no update is needed.]

Further changes would be appropriate in the Syntax and Examples 
sections, to make clear that when using EAI, data can be sent as raw 
UTF-8, without using encoded words.

Other alternatives have been discussed previously. They mainly include
a) Special syntax for fallback addresses
b) A new scheme for EAI mailto

As for b), I think this was very appropriate at a time when the 
<...<...>> syntax was still en vogue. At least in my personal opinion, 
it is no longer really needed; non-ASCII addresses will fail in the same 
way with the 'mailto' scheme as with a new scheme, and sending mail with 
a non-ASCII address isn't something essentially different from sending 
it with an ASCII address.

As for a), the easiest way to make this work is to have specific 
well-defined header fields already available. For example, it might be 
helpful in some scenarios to have a header field:
    From-all-ASCII:
Independent of the downgrading discussion, this could be helpful to 
populate address books with alternative addresses that a sender could 
e.g. use when sending to a non-EAI mailing list.

Regards,    Martin.

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

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 30 Oct 2010 20:25:34 +0900

On 2010/10/30 16:57, Larry Masinter wrote:
> I think any updates to RFC 6068 need to come from a clear
> statement of requirements from the EAI working group, and
> I would hold off submitting any updates until there is
> some clearer consensus that updates are actually needed.

That's fine with me. I just wanted to give input to the group on what 
could be done, and make clear that I'm ready to serve as an editor.

Regards,   Martin.

> Larry
> --
> http://larry.masinter.net
>
>
> -----Original Message-----
> From: "Martin J. Dürst" [mailto:[email-masked]]
> Sent: Friday, October 29, 2010 8:10 PM
> To: Joseph Yee
> Cc: EAI WG; Larry Masinter; Jamie Zawinsky
> Subject: Re: [EAI] IETF 79 - EAI Agenda, mailto:
>
> Hello Joseph,
>
>      5.  Percent-encoding of non-ASCII octets in the<local-part>  of an
>          non-ASCII characters is prohibited.  When a<local-part>
>          message, the<local-part>  MUST be transformed to conform to

---

From: Larry Masinter <[email-masked]>
Date: Sat, 30 Oct 2010 00:57:03 -0700

Larry

-----Original Message-----
From: "Martin J. Dürst" [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 8:10 PM
To: Joseph Yee
Cc: EAI WG; Larry Masinter; Jamie Zawinsky
Subject: Re: [EAI] IETF 79 - EAI Agenda, mailto:

Hello Joseph,

Regards,    Martin.

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Oct 2010 08:47:31 -0400

> some clearer consensus that updates are actually needed.

Speaking as an individual (no comment as co-chair until I read
the entire thread and 6068), this sounds like a wise strategy.

   john