Subject: [EAI] Agenda presentation uploaded to meeting materials page

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 Nov 2006 14:43:51 -0800

The agenda and discussion slides we will use on Thursday has now been 
uploaded to the meeting materials page:

You will find the slides on this page:

<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67>

under the Applications Area, EAI.

               Harald

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

---

From: Martin Duerst <[email-masked]>
Date: Thu, 09 Nov 2006 14:43:06 +0900

Hello Harald, others,

I have not found any item regarding implementations on the agenda.

I know that implementations are not usually much discussed during
a WG meeting, but in the minutes from Beijing, there was some helpful
information about ongoing/planned implementations, and it would
be great if there were such information this time, too.

For everybody's information, I'm currently working with a student
of mine on implementation in an MUA (Sylpheed, see
http://sylpheed.sraoss.jp/en/). We should have some results in a
month or two. We are very interested in getting an SMTP server
implementation for testing (with an MUA only, things are
kind of boring, to say the least). Also, if somebody is working
on a POP or IMAP server, we would appreciate to know.

With kind regards,     Martin.

At 07:43 06/11/09, Harald Alvestrand wrote:
>The agenda and discussion slides we will use on Thursday has now been uploaded to the meeting materials page:
>

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

---

From: Martin Duerst <[email-masked]>
Date: Thu, 09 Nov 2006 14:32:08 +0900

Hello Harald, others,

>under the Applications Area, EAI.

Here is some additional material for your discussion discussion about
the mailto: URI draft
(currently http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt)

It is a breakdown of the various things that (most probably) need
to happen sooner or later, in order of priority, first as a short
list (which you might want to put into a slide) and then again
with some comments added. If I have misrepresented anybody's
position, I'm appologizing in advance.

Summary
-------

1) General fixes to the mailto: URI as it is, independent of
   internationalization.

2) Allowing non-ASCII characters where they are currently allowed
   in email (e.g. Subject: header field).

3) Internationalizing email addresses in mailto:.
   3)a] Internationalizing the RHS (domain name part)
   3)b] Internationalizing the LHS

4) Including the syntax for fallback addresses

With Comments
-------------

1) General fixes to the mailto: URI as it is, independent of
   internationalization.

   Mostly proposed by Frank, Frank said that this should be done
   separate, before anything else. I'm ready to do that work, in
   combination with at least 2).

2) Allowing non-ASCII characters where they are currently allowed
   in email (e.g. Subject: header field).

   In my view, this is overdue, because it is an unnecessary
   limitation, and some implemenations already exist and others
   are looking for guidance. This is the main contribution of
   the draft. It uses UTF-8 and %-encoding to work well with IRIs.
   The fact that EAI also uses UTF-8 is a coincidence on the
   technical level (on a higher, architectural/best practices
   level, it is not a coincidence).

   John expressed two concerns: a) that there may be normalization,...
   issues that should be handled in an uniform manner before
   moving forward, and b) that 'internationalizing' mailto:
   in this way at the same time EAI is moving ahead with
   internationalizing the actual addresses may be confusing.

   With respect to a), including non-ASCII characters (as UTF-8
   or in any of many other encodings) e.g. in the Subject
   field is already possible, and not restricted, and allowing
   this is mailto: doesn't seem to make the problem any worse
   (if it is bad indeed, which I don't think it is).
   With respect to b), I think the mailto: draft can be
   very clear on what it does and what it doesn't, and people
   who want to get themselves confused will always find a way
   to do so.

   I currently think that completing the draft with 1) and 2)
   and publishing it, as an individual submission, and later
   do another update, possibly as a work item of this WG or
   a followup WG (after completing the current items, as
   Ted was insisting), is what makes most sense.

3) Internationalizing email addresses in mailto:.

   This falls into two parts, RHS and LHS. This at first looks
   intimately related to the work of this WG, but actually, it
   can be defined in a way that is independent of the WG work.
   The trick is simply to say "Here is how you put a non-ASCII
   email address into a mailto URI; at any given time, there
   may be no (as currently), one (e.g. EAI), or more than one
   way to actually send something to such an address, but this
   specification doesn't address this."

   3)a] Internationalizing the RHS (domain name part)

   Sending mails can already be implemented now, by converting
   the non-ASCII characters in the mailto: URI to xn--punycode
   in SMTP and the actual mail headers. With EAI, a better method
   should become available.

   3)b] Internationalizing the LHS

   This currently doesn't work. This means that the spec will
   be around, but because there are no implementations, there
   will be no actual URIs that use this feature. It will be
   possible once EAI becomes available.

   The draft currently includes 3), but given that e.g. 3)b]
   at this point in time could not be implemented, and therefore
   the draft could not move to Draft Standard that way, it may
   not be appropriate to include this. Also, it would probably
   create more confusion than staying at 2).

4) Including the syntax for fallback addresses

   Concretely, something like mailto:[email-masked][[email-masked]]
   or mailto:[email-masked][email-masked]} (or
   mailto:utf8@utf8<ascii@ascii>, but '<' and '>' are not allowed
   in URIs!) would be added to the mailto: syntaxt.

   I have mentioned that this may need to be done in the current (-03)
   draft, but it is way to early, because the syntax isn't clear
   yet and implementations are not available yet, and it's not
   even clear whether this is really needed
   (something roughly like
    Contact: <a href='mailto:[email-masked]'>Internationalized</a>
             <a href='mailto:[email-masked]'>old style</a>
    may be more appropriate in many cases).

Conclusion
----------

My own personal conclusion at the moment is to do 1) and 2) in a first
step, as an individual submission (together with Larry and Jamie) and
with help of whoever sees a need to contribute, and then do 3) (and
possibly 4) at a later stage. I hope this will reasonably address
all the concerns of everybody who has expressed (or otherwise has)
a concern. But I'm looking forward to further WG input.

I hope everybody is enjoying San Diego. It was great the last time
around the IETF was there.

Regards,     Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 09 Nov 2006 17:01:36 +0100

Martin Duerst wrote:

> something like mailto:[email-masked][[email-masked]]
> mailto:utf8@utf8<ascii@ascii>, but '<' and '>' are
> not allowed in URIs!)

That's interesting - I thought that [...] is also NOT
allowed, excluding IPv6 (or IPvFuture) literals in the
<host> part of an <authority>

And after two years and that message...
<http://permalink.gmane.org/gmane.org.w3c.uri/858>
...I hoped that I finally understand RFC 3986.  Based
on that article anything claiming to be an URI must
match the general syntax in RFC 3986.

Trying that for mailto:[email-masked][[email-masked]]
as URI (not IRI) the "mailto:" part should be a scheme.

There's no query- or fragment-part, so the rest should
be a hier-part.  It doesn't start with "//", and so it
must be a <path-absolute> or similar, no <authority>.

All path-constructs consist of zero or more segments
separated by slashes, each segment consists of zero or
more <pchar>s.   With a special case for relative URLs
without scheme, where the first segment cannot contain
a colon, that's in other words 1*<pchar> excluding ":".

Putting it all together - the colon-case is irrelevant
after the trailing colon in "mailto:" - you can have
<pchar>s and slashes, and <pchar> doesn't allow "[" and
"]" like it doesn't allow "<" and ">".

If that's wrong wrt URIs it could be very important for
the EAI-work, because Kari and I discussed alternatives
for the proposed "[" and "]" <alt-address> syntax, and
I was confident that using angle brackets to delimit it
wouldn't make it worse for your mailto:-work.

> My own personal conclusion at the moment is to do 1)
> and 2) in a first step, as an individual submission

That sounds good, please propose a list to discuss some
details.

> then do 3) (and possibly 4) at a later stage. I hope
> this will reasonably address all the concerns of
> everybody who has expressed (or otherwise has)

The question above about square- vs. angle-brackets is
about the potential output of EAI, it could affect the
future 2368ter if angle-brackets are worse than square-
brackets.

Frank

---

From: Xiaodong Lee <[email-masked]>
Date: Fri, 10 Nov 2006 01:39:31 +0800

Dear Martin,

There is no time slot for implementation discussion for saving time to 
discuss the open issues.
We just mentioned some implementations are ongoing by CDNC. ( www.cdnc.org)

About that, you may contact Mr.Yao Jiankang, [email-masked] to know more.

Regards!

-- 
-- Xiaodong LEE [The best answer is doing]
   +86-10-58813020 
   mailto:[email-masked]
   http://www.lixiaodong.cn

---

From: "Jeff" <[email-masked]>
Date: Fri, 10 Nov 2006 04:21:26 +0800

TWNIC had setup a EAI SMTP server for testbed. If anyone is interesting in
join in testing, please sent a brief message with you IP address range to
[email-masked]. I could open relay for them. 
And also, we have a simple updated version of POP3 server (modified from
Perl Net::Server::POP3). But it currently archived in somewhere, some
server, I have to dig it out when I get back to my office.

Regards,

Jeff Yeh
-TWNIC

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 1:43 PM
> To: Harald Alvestrand; [email-masked]
> Subject: Implementations (was: [EAI] Agenda presentation uploaded...)
> 
> Hello Harald, others,
> 
> I know that implementations are not usually much discussed 
> during a WG meeting, but in the minutes from Beijing, there 
> was some helpful information about ongoing/planned 
> implementations, and it would be great if there were such 
> information this time, too.
> 
> For everybody's information, I'm currently working with a 
> student of mine on implementation in an MUA (Sylpheed, see 
> http://sylpheed.sraoss.jp/en/). We should have some results 
> in a month or two. We are very interested in getting an SMTP 
> server implementation for testing (with an MUA only, things 
> are kind of boring, to say the least). Also, if somebody is 
> working on a POP or IMAP server, we would appreciate to know.
> 
> >The agenda and discussion slides we will use on Thursday has 
> now been uploaded to the meeting materials page:
> >
> ><https://datatracker.ietf.org/public/meeting_materials.cgi?me
> eting_num=
> >67>
> >