Subject: [EAI] Minutes of EAI WG Montreal Meeting(Welcome comments)

From: Xiaodong Lee <[email-masked]>
Date: Thu, 03 Aug 2006 11:01:55 +0800

Dear All,

This is the minutes of EAI Wg Montreal meeting, please check it, and note
the rough consensus in the end of this minutes.

Thanks a lot for Alexy Melnikov taking this minutes.

Regards!

*****************************
*****************************
The meeting has started with short review of WG status:
1)interim meeting in Beijing in June 2006
2)8 WG drafts, one new -00 (Mailing list draft)since the interim

1.1 Presentation:
John quickly talked about -framework-01.txt document. Changes since the
previous revision:
Added comments about PGP/SMIME/DKIM. PGP and S/MIME don't sign headers,
so they should not be affected by EAI, but DKIM is.
John also updated terminology used in the document.

1.2 Questions or Comments:
Ted: how EAI affects mailto IRI and IRI in general. Is this in scope for
the WG?
Tony Finch (in jabber): also vcards, ldap schemas....
John: Martin has asked to add some text to -framework.
Ted suggests to use new URI schema, as this is a major syntax change.
Philip Guenther: mail3
Philip: S/MIME messages containing RFC 2047 encoded word will have to
continue to use RFC 2047 in the future.
John: Sure. Text is welcomed.

2.1 Presentation:
John quickly presented Harald's document. There were only editorial
changes since the previous revision. No questions were asked about the
document.

2.2 Questions or Comments:
No.

3.1 Presentation:
Yao Jiankang presented -smtpext-00.txt draft.
Main changes since the previous revision
1). Refined the Mailbox Address Syntax definition
2). Changed the ESMTP name for the extension to be UTF8SMTP
Open issues:
1). Do we recommend to use SASLPrep (RFC 4013) for local part of an EAI
address?
2). EHLO keyword for the extension
3). Syntax of SMTP commands: where to put alternative address and what
is the exact syntax for MAIL FROM/RCPT TO after that)

4.1 Presentation:
After that Yao did live demo of sending EAI email (different cases from
Harald's draft) using extended qmail.
The demo implementation doesn't do mailing list related examples, but
authors are working on it.
The demo contained a bug: "Content-transfer-encoding: 8bit utf8", but
otherwise worked well.

4.2Questions or Comments:
Note that demo didn't exactly match the latest draft, but it will be
updated. In particular the demo was using a single parameter to carry
either alt-address or [old] atomic=yes semantics (as per rough consensus
at Beijing interim).
John commented that a single parameter versa 2 parameters is another
open issue.

Discussion about how to parse a single parameter followed in jabber
Chris (in jabber): I like the fact eaipara eliminates the silly state of
both ALT-ADDR and ATOMIC parameters. But it's badly named.

Ted: it seems that in Beijing there was an agreement to change from 2
parameters (for alt address and atomic) to 1 parameter. Why?
Yao: to avoid the silly state when both are present.
John: we need to get consensus on the change today.
John: disadvantage of a single parameter: the only way to distinguish
keyword from alt-address is by looking at @ sign. What happens if some
implementation misspells the keyword?
John: there is also a possible performance implication of the change.
Chris: I find the silly state to be a more serious design error than
John's concern about forward parsing.
Many (actually John agrees with them): Having a single parameter is a
good thing.

Pete: I'm still not clear on the difference between ATOMIC and the
absence of the parameter?
Ted: In the absence, it seems like it would mean you don't know that it
is downgradable, so bounce the message.

Suggestion to change "eaiparam=" to something like "downgrade=".

Randy: Why have an ATOMIC parameter at all? If its purpose is to permit
the RCPT TO address to be converted when ALT-ADDRESS is not supplied,
why can't the sender just do the conversion and use the converted
address as ALT-ADDRESS?
Many: We like that.
Ted: Would there be some clients that don't have code to downconvert
utf8 addresses? This is the only good justification for having "atomic".
John: We can have atomic flag in the submission server, so that the
client doesn't need the code to downconvert the address.
Tony Finch warns about importance of the user interface, specially
address books, mailto: urls ...
Tony Finch raises some concern of having a submission only extension: it
doesn't actually create less work for people, as most MSAs are also
MTAs, so the code is shared.

Pete: What about the change to put alternative address inside the <> of
the mail from/rcpt to? This requires changes to RFC 2821. Pete is
proposing that this move outside the angle brackets
Chris: Agree with Pete, I would rather reuse existing ESMTP parameter
parsing code.
[Poll]: the alt-address parameter outside of the <> (i.e. == separate
ESMTP parameter)
Consensus to move alt-address outside of the <>.

[Coming back to discussion about encoding atomic =yes or alt-address in
a single parameter]
Eric A.: we can put @ sign before a keyword to make it distinguishable
from an address
Pete: if we can agree to remove atomic, we don't need to decide on how
to encode keywords.
Many: agree.
[Poll]: eliminate atomic?
John: I want to give an argument I don't like. Only the receiving server
really knows its addresses.
Chris: We can not impose semantics on ASCII local parts without breaking
the current model. But we _could_ impose semantics on UTF-8 local parts
when we introduce them. I'd say we should impose as few such semantics
as possible, but having explicit downgrading rules makes sense to me.
Consensus to remove the atomic from MTAs.
Ted (with AD hat on): who is doing the draft for submission only atomic
parameter?
John/Randy: will do a draft on atomic in submission.
John/Randy: but we would prefer to not have the atomic anywhere.

5.1 Presentation
Nai-Wen Hsu presented "UTF8 Header" draft.
Major changes:
1). i-Email header was added
2). ABNF has changed
Pending changes:
Update ABNF to disallow UTF-8 in Message-ID and Received header
Open Issues:
1). alt-separator - currently using { }
2). name of the i-Email parameter

5.2 Qeustions or Comments:
Discussion (in jabber) about alt-separator has followed. '{' and '}' are
not "special" in RFC 2822, if a parser finds them in the domain part
(e.g. <local-part@domain{downgraded-local@downgraded-domain}>), it will
happily treat them as a part of the domain, but domain lookup later will
fail.
Tony Finch suggests ':', saying that Microsoft consuses ';' and ','.
Philip G.: how about nesting <>s for the downgrade?
Marcos.Sanz: utf8@utf8 [ascii@punycode] ?

6.1 Presentation
testing report (also by Nai-Wen Hsu).
Test based on Sendmail.
Different test cases:
1) downgrade envelope
2) downgrade headers (punicode in Received header, add i-Email header, etc.)
3). also tested mailing lists
Linux "mail" was used as EAI-aware client. Outlook Express as non
EAI-aware client
A simple EAI POP3 server was written in Perl.
Tested with CAPA UTF8 and without it
Issues:
1) May add-spec change? Should we use ESMTP argument for alt-address?
(no longer relavant due to todays discussions)
2) Recommend: alt-separator for mailing lists is the same as for
'utf8header'
3) EAI-parameter replaces Envelope from: can alt-address be from another
domain; interaction with DSN ESMTP extension, etc.
4). SPF: is EAI parameter restricted to the MTA domain? If not, how to
setup SPF?
5) Interaction with DKIM: downgrade/upgrade can break signatures
6.2 Questions or Comments:
No

7.1 Presentation:
Pete Resnick presented IMAP draft. Couple of offline comments were received.
Major Issues:
1) non extended LIST returning UTF-8 stuff? Will try to address in the
next revision
2) Does the server have to upgrade all messages in the mailstore?

7.2 Qeustions or Comments:
Philip: there is some complexity with server not willing to do upgrade
for *some* mailboxes. Can we eliminate this (all mailboxes are UTF8)?
There is performance issue for servers, e.g. calculating proper RFC822.SIZE

Chris: It was less effort to write the draft in a way that is UW
c-client compatible than to write the simpler always-upgrade design and
deal with the political fallout.
Cyrus: I still think a mode switch with a '* NOUTF8' response on select
for those mailboxes the server won't 'upgrade' is a simpler
implementation approach.
Chris: please suggest some text
John: "* NOUTF8" is also consistent with the principle that one should
design for the long term then work in transitions, rather than designing
kludges that one has to carry around forever.
Cyrus promised to write some text

8.1 Presentation:
Edmon Chung presented draft on EAI Mailing lists.
Draft philosophy: "mailing lists should not introduce any additional
protocol requirements for EAI"
Open issues:
1) Is it a requirement to obtain alt-addresses on mailing list expansion?
If yes, how to obtain them?
Different mailing list scenarios:
a) Pure case (only UTF-8 subscribers involved)
b) Mixed case (some members might not have alt-addresses)
2). "Downgrade Considerations for mailto URLs"
List-* headers are mostly using URIs, so they should be using IRIs. So
there is an issue of extending mailto: schema to allow for EAI.
3). Operational policy of requiring alt-address/ atomic info

8.2 Questions or Comments:
Ted: we can't require all addresses to be downgradable (e.g. if there is
a community of tai users exchanging email in tai - why do they need to
have alt-addresses?) Legislating human behaviour is impossible task.

Example problem: sender has non-downgradable address, some subscribers
have ascii-only addresses - is the message to be bounced?
William L.: if mail from was non downgradable, but the mailing list
rewrites MAIL FROM, bounce might not be needed.
Philip G.: EAI mailing list can help two groups of people to communicate
(one is ascii only, ther other is utf8 only)
Pete: is it realistic to expect that people are not going to have
algorithmically derivable ascii addresses?
John: it is difficult to prevent people from doing stupid things
(referring to previous Ted's comment about legislating human behavior)
John: needs to describe possible implementation options for "bounce non
downgradable sender addresses"

Ted: So the clear thing is that making a mailing list address with a
non-downgradable address is a bad idea.

Chris: Thought experiment: what if the mailing list simply replaced all
UTF-8 addresses with the list submission address?
Tony Finch: the problem posters might not be subscribers

It seems that there are many open issues with the draft. This document
is really hard.

9.1 Presentation:
No presentation for POP3 draft, only to recieve comments
9.2 Questions or Comments:
No comments in the room on Chris's POP3 draft.

Side conversation in jabber on non-atom email addresses. One example is
subaddressing <[email-masked]>. Consensus that implementations
that support plus addressing must be able to decode punycode before
extracting subaddress.
This followed by a diffsicuin that punicode loses information, as it
uses normalization. Whatever EAI will end up using for encoding UTF-8
will have to be lossless.

10.1 Presentation:
Next presentation: Fujiwara report downgrade-01
Major changes:
1) Follow new header format, added i-Email header, etc.
2) Received header field is not allowed to contain UTF-8
Overview of the draft, 3 downgrade options
1) Don't downgrade headers (new?)
2) Downgrade headers
3). MIME encapsulation

10.2 Questions or Comments
Pete: why "Downgraded: To:" instead of "Downgraded-To:"?
Cyrus: many tools do grep on headers (include IMAP servers), so having
Downgrade-to: would work better for them.
Philip (rephrasing previous question): can we just check for 8-bit,
instead of requiring all implementations to check for UTF-8? The former
is certainly easier to do.
Chris: checking for UTF-8 is not hard (pasted some code into jabber).
Marcos.Sanz: First, it is a stateful check. Second the code does
necessary checks, but they are not sufficient for valid UTF-8.
Chris: There are three case: Message is standards compliant and has
UTF-8 headers. Message is standards compliant and has 7-bit headers
only. Message is not standards compliant. Treating the third case as
"Garbage In Garbage Out" (GIGO) is not a problem in my book. So the
UTF-8 test is necessary and sufficient, IMHO.
Marcos.Sanz: If the GIGO case can be ignored, then checking for the
highest bit set is sufficient and necessary, too.
Chris: true, except for any potential security issues with overlong
UTF-8 sequences.

John: Assume I have UTF-8 headers and a body part that is, itself,
CTE=foobar (a type you don't recognize). If I now encapsulate the whole
thing as base64, the multiple encoding rule is broken. You can't upgrade
CTE foobar to 8bit and then re-encode the whole business (as you could
in principle do with Base64) because you have never heard of foobar.
[Problem]: MIME-encapsulating is going to break nested encoding rules.

tlr: Downgrade can replace utf8-only address with MAIL FROM address,
which are not necessarily the same thing

William L.: Some ESMTP parameters (e.g. ORCPT) pass addresses,how do
utf8 addresses get encoded in them?
Chris: ORCPT has a tagged address: ORCPT=rfc822;encoded-addr. So we
could use ORCPT=eai;encoded-addr. Of course, the xtext encoding used by
ORCPT explicitly forbids 8-bit, we'd have to change that to permit UTF-8.

Comparison of different downgrade methods: MIME encapsulation preserves
all header information, but make information unreadable in old UAs.
There is also different cost associated with different methods.

At the end of the meeting Xiaodong has summarized the rough consensus on
outstanding issues for all docs:
1) ATOMIC parameter
Answer:agreement to remove it
2) Syntax for alt-address in the envelope
Answer: move it outside of bracket
3) Do we need new extended SMTP error codes for cover bouncing and
downgrade cases?
Answer:we don't need
4) Encapsulation Model issue: is it satisfactory?
Answer:Multiple issues with existing text, need to be discussed deeply
5) Consistent terminology
Answer: Every Author should update their draft within two weeks, if
necessary, and should keep consistent terminology with framework draft.

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

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