[EAI] EAI meeting notes from the Dallas IETF

Please let me know if the notes are accurate.

===============
The EAI meeting has started with Harald Alvestrand (the WG chair)
setting out the rules for the meeting: no arguments about whether the
proposed approach (use UTF-8 email addresses) is Ok or not. Harald also
added that the goal of the meeting is to try to resolve as many issues
as possible.
Ted Hardie, the responsible AD for the EAI mentioned that IESG will
consider very seriously transition from the experimental phase of the
EAI WG to the standard track phase (see the charter).

1) "EAI constraints" document.

John Klensin has talked about his "EAI constraints" document, which
talks about potential fragmentation issues among other things. The draft
is describing John's personal opinion and thus doesn't have to become a
WG document.
John mentioned that the document is a set of tradeoffs and that it is
not possible to satisfy all of them. John didn't talk in details his
draft, assuming that everybody has read it and jumped to the Q&A right away.

Q: Paul Hoffman has asked why this draft can't be an individual submission.
A: John: processing for individual submissions takes long time, can be
much slower than a WG document.

2). "EAI scenarios" document.

Harald has presented his "EAI scenarios" draft next. He explained that
he has tried to describe use cases in generic terms in order not to
constraint the solution. All requirements which weren't 100% needed were
removed.
Paul Hoffman has suggested to fold this document into the framework
document. John has replied that having too many informational documents
is bad. Consensus of the room to make the draft a WG document, but keep
it a separate draft. Consolidation can be done later on.

3). "EAI framework" document.

John talked about the framework draft next.
Q: Ted Hardie: the "problem statement" section says that major rework is
needed on the document, what is planned?
A: John: take out the text about major rework :-).

Q: Lisa has asked if the WG is considering multiple solution or just one.
A: John has replied that there is a single solution, multiple documents
are needed mostly in order to spread the workload between multiple people.

Q: Paul Hoffman: the document doesn't say which documents are mandatory
to implement and which are optional.
A: John: everything is mandatory, but we are not sure when to downgrade
and under what conditions.

Q: Ted: the document only allows downgrade or bounce?
A: John: yes

Q: Dave Crocker: DSN has very strict rules when to bounce a message, why
this draft is not as strict?
A: John: the intent was to make EAI it as strict as DSN rules.

4). "Internationalized Email Headers" document

Jeff Yeh has presented "Internationalized Email Headers" draft
(draft-yeh-ima-utf8headers-01.txt).
He described changes since -00 first:
- added new header field to signal that header fields are in UTF-8
- clarified that new format requires the IEmail SMTP extension
...

Rules in RFC 2822 were not changed, in particular header names are still
in ASCII. Message-ID were not changed, date-time were not changed except
for the "comment" part. RFC 2822 "phrase" and "comment" non-terminals
can contain UTF-8 now.
Jeff has also talked about updated ABNF for RFC 2822 "mailbox".

Q: Ted: what issues are anticipate for mailing lists?
A: Jeff: mixture of i18n and ASCII addresses in a single message

Q: Dave Crocker: References include text, why not I18N them?
A: Pete Resnick has jumped to the microphone: References only allows for
comments, which are addressed by general rule about comments.

Dave Crocker noted that RFC 733? provided a syntax form multiple
addresses for an entity and it might be nice to reuse it.

Chris Newman noted that it was important to give an example of
internationalized timezone in the date-time, i.e. Internationalized 
comment after the timezone offset.

John Klensin replied to this that I18N time zone might be an issue with
deployed mail clients.
Pete Resnick suggested to restrict where UTF-8 can be used, not just say
"everywhere where 'comment' is used".

Paul Hoffman suggested that the document should give detailed
instructions "do this, don't do that", so that other WG like DKIM and
PKIX can see any interactions with EAI.
Pete Resnick noted that there were some shared syntax between 2821 and
2822, so it would be better to abstract it out. But need to be explicit
about which rules affect email message format and which affect SMTP.

Q: Philip Guenther (remotely through jabber): do the changes to these
rules also effectively change the rules for MIME part headers inside the
body, e.g. Content-*: headers at the starts of a MIME part?
A: John Klensin: Philip's issues is not addressed, will be added to todo
list

Chris Newman suggested to use SASLPrep for email address canonicalization.
Philip Guenther noted that S/MIME at least had no canonicalization levels.

5). "EAI SMTP extension" document

Jiankang Yao talked about EAI SMTP extension
(draft-yao-ima-smtpext-02.txt). Changes since the last revision:
- added mailbox address syntax
- added the ATOMIC and ALT-ADDRESS optional parameters to MAIL FROM and
RCPT TO commands.
ALT-ADDRESS takes precedence. If not specified and ATOMIC=yes, the I18N
address can automatically be converted to ASCII (using yet to be decided
ASCII Compatible Encoding)

Q: Is there any reason to permit both ATOMIC and ALT-ADDRESS on a single
address? As written, ATOMIC is ignored if ALT-ADDRESS is present

Q: Pete Resnick: why change the "atom" ABNF? Why not use ABNF for the
quoted string?
A: John: Quoted strings are nothing but troubles operationally (based on
20 years of experience), so the draft is trying to address this issue on
purpose.

Q: Philip: are spaces allowed in local part (they need to be quoted)?
This is frequently used with user+mailbox addressing.

Q: Paul Hoffman: we can't have UTF-8 examples in the document, as RFC
format doesn't allow for UTF-8 :-(.

Q: Ted: email address can be in either UTF-8 or punycode?
A: Yes.

Q: Pete Resnick: Why ATOMIC is needed, my guess is for subaddressing.
Harald request to defer the question till downgrade draft

6). "Downgrade" document

Yoshiro Yoneya talked about the downgrade draft
(draft-yoneya-ima-downgrade-01.txt). Changes from -00:
- added downgrade requirements section
- separate description of SMTP and message format downgrading

Downgrade requirements:
- downgrade once, don't upgrade until delivered
- downgrading must be easy
- MUST preserve header information
- should work with DKIM/SPF
- an attempt to downgrade MUST be recorded
...

Chris Newman noted that MUST is too strong for preserving all header
information.
Chris Newman commented that some requirements can't be met (e.g. charset
info is lost on conversion). He suggested to use "best effort"

Yoshiro talked about downgrade procedure in details (see the draft). The
draft describes two ways to downgrade: MIME encapsulation and
header-by-header conversion.

Harald (as a participant) suggested to remove the text about upgrading  
and MIME encapsulation case, as there is no use case for them. The 
removal will make the whole model simpler (and thus will simplify the 
document).

Chris Newman wanted to have upgrade in a different spec (or not at all).
But he doesn't think upgrade can be avoided, as lack of upgrade makes
writing IMAP client very difficult (2 different cases to handle in IMAP
code).

Lisa commented that encapsulation can be useful, as MUAs can be upgraded
to support UTF-8 easier.
Pete Resnick recommended to split upgrade (or downgrade) of SMTP and
message format.
John has commented that encapsulation preserved all information.
Chris Newman commented that protocol level upgrade can only happen
inside an Autonomous System (e.g. enterprise), no need to talk about
this in the draft.
Ted Hardie commented that header-by-header approach has advantage that
only MUA needed to be updated, no changes to POP/IMAP servers.
John raised an issue about downgrading headers that the MTA doesn't know
about. He also commented that encapsulation and header-by-header are not
necessarily mutually exclusive.
Harald pointed out that encapsulation can produce a message that the
recipient can't use (i.e. MUA doesn't recognize the format).

No consensus in the room about encapsulation versa header-by-header, the 
discussion should continue on the mailing list.

7). "POP3 I18N extension" document

Chris has talked about POP UTF8 extension draft. The basic approach was
to add parallel command for each affected command, as there are not that
many of them. I.e. the draft added RET8,LST8 in addition to RETR, LIST.
It also added an optional parameter to the USER command and requires use
of SASLPrep for USER/PASS/APOP use SASLPrep. The NO-RETR capability was
added to say that the server can't support "old" 7bit mode.
Chris has considered an alternative approach (a new command to do a
"switch to UTF-8 mode", but decided against it). In particular Chris
thought that the TOP command was evil and thus there is no TOP8 command.
Up-conversion is required to make clients easier to implement.

Q: Randy Gellens: TOP8 is useful in mail clients (to check if a message
is to be downloaded).

John Klensin wished that TOP has never existed. He commented that for
libraries that support both IMAP and POP, TOP adds extra effort and
requires specific mode of parsing message.
No consensus for "not having TOP8" and Chris gave up on not adding TOP8.

Q: Tony Hansen: how RETR works on UTF-8 mailstores?
A: Chris Newman: downgrade. The behavior of RETR is not changed in any way.

Pete Resnick commented that clients who wanted to download just headers
would use RETR and drop the connection. So it is better to have TOP8.

Q: why clients are using TOP? Because they have limited
memory/bandwidth? They should be using LIST.

Randy Gellens commented that clients use TOP both to look at headers and
to peek at body.

Chris asked the WG if a global switch is better than a parallel set of
commands? Harald (as the WG chair) replied that this should be taken to
the mailing list.

8). John talked about fragmentation of group of users due to EAI (see 
John Klensin's message on the mailing list).

Barry Leiba commented that if there were partitioning, EAI would help to
limit it by preventing deployment of multiple incompatible methods.
Paul Hoffman added that there might be partitioning of people based on
left-to-right versa right-to-left scripts.
Cyrus Daboo added that there are other issues to be addressed like
vCard, mailto URLs, etc.

9). The meeting has concluded. Authors of the documents need to 
republish their documents with WG names.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima