Subject: [EAI] EAI WG status and rechartering

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Nov 2009 18:08:17 +0000

Greetings,

Here is what I think remains to be done under the current WG charter:

1).
draft-ietf-eai-downgraded-display
draft-ietf-eai-imap-utf8

I am awaiting for updated versions of these documents before getting 
them approved.

2). The following document is the last deliverable needed before 
rechartering (I think):

draft-ietf-eai-mailinglist

Currently it is expired. Reissuing the document and sending it to WGLC 
(if ready), would be nice.

While I am waiting for the 3 documents, I think the WG can start 
discussion about whether the group should shut down or recharter. In 
case there is consensus to recharter, I would like to see if updated 
charter text can be agreed on.

If the WG has enough energy to recharter, I would also like to ask the 
WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an 
additional deliverable.

Note that I also would be looking for at least 1 new WG chair. If you 
want to volunteer yourself or somebody else, please send me an email 
message with details directly.

Best Regards,
Alexey, Apps AD.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 23 Nov 2009 18:34:07 +0900

Hello Alexey,

> WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an

I'm not sure this makes sense, for two reasons:

- While draft-duerst-mailto-bis is very much about internationalization
   (it allows non-ASCII characters in things such as Subject and body,
    which the current RFC doesn't), it isn't actually about EAI

- The draft has already been out for quite a long time, it doesn't seem
   to make sense to wait for other EAI drafts to complete and then the
   WG to recharter to move on.

That said, it would be possible (I'd even say appropriate) for a 
rechartered WG to take up the job of either further updating what might 
by that time be the RFC resulting from draft-duerst-mailto-bis 
(essentially continuing what was 
http://tools.ietf.org/html/draft-ietf-eai-mailto-01), or of creating a 
new URI/IRI scheme for EAI mail addresses. [I'd be glad to volunteer as 
an editor in either case.]

Also, it's never too late for anybody in this WG to have a look at 
draft-duerst-mailto-bis (currently at 
http://tools.ietf.org/html/draft-duerst-mailto-bis-07). Any kinds of 
reviews are appropriate, but with respect to WG matters, I'd want in 
particular to point out the following two items (not EAI per se, but 
definitely related) in Section 2, "Syntax of a 'mailto' URI":

    4.  Percent-encoding can be used in the <domain> part of an <addr-
        spec>, in order to denote an internationalized domain name.  The
        considerations for <reg-name> in [STD66] apply.  In particular,
        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.  URI
        producing applications MUST NOT use percent-encoding in domain
        names unless it is used to represent a UTF-8 character sequence.
        When the internationalized domain name is used to compose a
        message, the name MUST be transformed to the IDNA encoding where
        appropriate [RFC3490].  URI producers SHOULD provide these domain
        names in the IDNA encoding, rather than percent-encoded, if they
        wish to maximize interoperability with legacy 'mailto' URI
        interpreters.

    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.

Regards,   Martin.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 23 Nov 2009 13:02:13 -0000

> charter text can be agreed on.

If we are going to recharter, then an additional piece of work could be to  
do EAI for Netnews. This would be mostly straightforward, since the  
distrubution channels for Netnews (NNTP and UUCP) are already 8-bit clean,  
and have been so for years, and so downgrading would only be needed when  
netnews was gatewayed to an email list.

So the only additional work would be to define an EAI extension for the  
Newsgroups header, enabling newsgroups with non-ASCII names to be formed.  
The USEFOR WG did much work on that a few years back, and tests indicated  
that such newsgroups would indeed progagate fine (a non-ascii group under  
dk.* was created for the purpose). But the work was shelved pending  
completion of other work. This job is nominally still on the agenda for  
the USEFOR WG, but that group has struggled to get its main two drafts out  
of the door (to be published imminently as RFC5536/7), and it is unlikely  
to survive further. So moving that item to this group would make sense. I  
could probably persuade a few News experts to come here to finish it off,  
and would be happy to produce a draft based on what USEFOR did earlier.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Joseph Yee <[email-masked]>
Date: Thu, 26 Nov 2009 11:48:06 -0500

Hi Martin,

I read the latest mailto-bis (07).  Section 2.4 and 2.5 are great.

In the paragraph right after section 2.5, it mentions the pct-encoding  
for <hfname> and <hfvalue>.  My own interpretation had it sounds like  
allowing <hfname> to be pct-encoded.  Since current and proposed  
message header definition do not allow non ASCII characters, wouldn't  
that be easier to limit <hfname> to ASCII only?  That would make  
<hfname> be case insensitive easier to manage too.  I noticed that  
section 4 would stop non ASCII in <hfname>, but wonder if it's good to  
restrict it in mailto IRI.

Regards,
Joseph

On 23-Nov-09, at 4:34 AM, Martin J. Dürst wrote:

> rechartered WG to take up the job of either further updating what  
> might by that time be the RFC resulting from draft-duerst-mailto-bis  
> (essentially continuing what was http://tools.ietf.org/html/draft-ietf-eai-mailto-01) 
> , or of creating a new URI/IRI scheme for EAI mail addresses. [I'd  
> be glad to volunteer as an editor in either case.]
>
> draft-duerst-mailto-bis (currently at http://tools.ietf.org/html/draft-duerst-mailto-bis-07) 
> . Any kinds of reviews are appropriate, but with respect to WG  
> matters, I'd want in particular to point out the following two items  
> (not EAI per se, but definitely related) in Section 2, "Syntax of a  
> 'mailto' URI":
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Nov 2009 14:11:19 +0000

>   WG to recharter to move on.

I agree with both statements.

> new URI/IRI scheme for EAI mail addresses. [I'd be glad to volunteer 
> as an editor in either case.]

Yes, I mostly meant this work item.

I think that draft-duerst-mailto-bis is essentially ready for IETF LC. 
If no major objections are raised during IETF LC, then it can be 
published as an RFC. However if there are some objections, the document 
might require a new or existing WG to help build/judge consensus.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 30 Nov 2009 16:45:01 +0900

Hello Joseph,

> I read the latest mailto-bis (07). Section 2.4 and 2.5 are great.

These are just point 4 and 5 in a numbered list within Section 2, but 
thanks for your review and comments, anyway.

> allowing <hfname> to be pct-encoded. Since current and proposed message
> header definition do not allow non ASCII characters, wouldn't that be
> easier to limit <hfname> to ASCII only? That would make <hfname> be case
> insensitive easier to manage too.

Okay, so you are proposing to change the grammar from:

       hfname      = *qchar

(with qchar being unreserved / pct-encoded / some-delims) to:

       hfname      = unreserved

On the face of it, that may seem okay. But looking at things in detail, 
it isn't. Optional header field names, as defined in RFC 5322 (see 
http://tools.ietf.org/html/rfc5322#section-3.6.8) can include any 
printable ASCII character except ":". So for whatever reason, and 
however unlikely, there may be a header field named "#browns" (an 
abbreviation for "hashbrowns"), where the "#" would need escaping in a 
mailto: URI. This would lead to an example such as:

mailto:[email-masked]?%23browns=diced-with-bacon

Which would translate to a mail containing:

To: [email-masked]
#browns: diced-with-bacon

So even if this example is quite silly, we can essentially not remove 
pct-encoded from the production. This means that software interpreting 
the mailto: URI has to reverse the %-escaping on hfnames, anyway.

Do you think we need such an example? I hope not, but if you think it 
would help, I'd also appreciate ideas for a somewhat better example.

> I noticed that section 4 would stop
> non ASCII in <hfname>, but wonder if it's good to restrict it in mailto
> IRI.

Yes, you are correct, section 4 would essentially stop non-ASCII as well 
as most ASCII, too.

Regards,    Martin.

---

From: Joseph Yee <[email-masked]>
Date: Mon, 30 Nov 2009 13:31:44 -0500

On 30-Nov-09, at 2:45 AM, Martin J. Dürst wrote:

> These are just point 4 and 5 in a numbered list within Section 2,  
> but thanks for your review and comments, anyway.

yes, my mistake there.

>> message
> On the face of it, that may seem okay. But looking at things in  
> detail, it isn't. Optional header field names, as defined in RFC  
> 5322 (see http://tools.ietf.org/html/rfc5322#section-3.6.8) can  
> include any printable ASCII character except ":". So for whatever  
> reason, and however unlikely, there may be a header field named  
> "#browns" (an abbreviation for "hashbrowns"), where the "#" would  
> need escaping in a mailto: URI. This would lead to an example such as:
>
> So even if this example is quite silly, we can essentially not  
> remove pct-encoded from the production. This means that software  
> interpreting the mailto: URI has to reverse the %-escaping on  
> hfnames, anyway.
>
> Do you think we need such an example? I hope not, but if you think  
> it would help, I'd also appreciate ideas for a somewhat better  
> example.

I agreed with you, there are still non alphabets in hfname.  The  
suggested restriction would not help.

For example, maybe header X-something?  It's not common either,but  
would show escaping in header name and I don't think we need such  
example.

Thanks for your explanation, Martin.

Regards,
Joseph

> Yes, you are correct, section 4 would essentially stop non-ASCII as  
> well as most ASCII, too.
>
> Regards,    Martin.
>
>
> --