Subject: [EAI] Meeting minutes from the San Diego IETF meeting

From: Harald Alvestrand <[email-masked]>
Date: Fri, 22 Dec 2006 10:35:33 +0100

Here are the minutes as posted to the IETF website:

http://www3.ietf.org/proceedings/06nov/minutes/eai.txt

We will attempt to get corrections uploaded if needed, even though the
official minutes deadline is already well passed.

Again, the chairs' apology for our lack of timeliness.

                 Harald, for the chairs

Minutes for IETF EAI WG Meeting in San Diego @ IETF67

TIME: 13:00 to 1500, Nov.9, 2006
VENUE: Room Spinnaker, Sheraton San Diego Hotel & Marina
Items of Minutes :
A.Agenda Bashing
B.Status of Work
C.Framework
D.SMTP extensions
E.Header draft
F.Downgrade document
G.End-system docs
H.Other docs
I.Key Points Summary

A.Agenda Bashing
--No tutorial materials in this meeting, only to discuss the open issues;
--No modification on agenda.
--Harald makes the presentation on the status of EAI WG and issues list 
of every WG draft.

B.Status of Work
--Framework has finished the WG Last Call;
--SMTP Ext., UTF8 Header, and Downgrade draft are in discussion;
--Supporting documents drafted. IMAP, POP, Mailing List draft. And DSN 
draft is coming soon, encapsulation and mailto drafts exist;
--Implementation tests have started. (CDNC test the EAI solution)

C.Framework
--Show the issues list, and assumption the silent ones agree or find it 
acceptable, based on the mailing list discussion;
--Setup the issue tracker: https://rt.psg.com; user/passwork: ietf/ietf;
--Issues list:
    #1387 1.3 - i18mail user clarification: Editorial, accepted
    #1388 -3 - Missing MIME considerations: Note that -headers needs to 
address MIME issues
    #1389 4.1 - term "bounce" vs "reject": Remove term "bounce". Exact 
term to use debated.
    #1390 4.1 - "POP": Editorial, accepted
    #1391 5 - delivery to final delivery MTA: Being wordsmithed
    #1392 6 - delete i18n section: Accepted
    #1393 7 - missing local part abuses as label: Resolution not clear; 
non-EAI issues involved
    #1394 10 - too long security section: Wordsmithing, but no changes
    #1395 13 - nits: Editorial, accepted
    #1396 7.1 - title change IRI -> URI: Accepted
    #1397 10 - UTF-8: Resolution not clear, still open
--Editor will make changes based on the existing mailing list 
discussion,and do version 03 rev;
--Chair will issue WG Last Call on those fixed;
--There are no new issues;
--If necessary, version 04 will be issued and passed to IESG for approval.

D.SMTP extensions
--Resolved issue is that identifier is UTF8SMTP;
--The open issue is that DSN extension should be a new document?
--Chris Newman: we have extensions that add parameters to SMTP MAIL FROM 
and RCPT TO, should the UTF8SMTP draft look at published extensions and 
loosen syntax to permit UTF-8 in _some_ parameters? in particular: AUTH 
parameter on MAIL FROM�� any other issues on UTF8SMTP?
Alexey: I will be revising SMTP AUTH soon, so I can try to address UTF-8 
in the AUTH parameter
--chris: ORCPT is the other big one, but that's being addressed in DSN rev
Alexey: it might be better to do it in the EAI document, so as not to 
introduce a dependency on EAI into SMTP AUTH.
--Chris: why EAI needs DSN? Since EAI will be experimental, not stds.
--draft standard DSN RFCs are 7bit only, original UTF-8 rcpt address 
important to preserve on bounce for end-user correlation, as we have 
more address translation in system, preserving them in bounces important
--technical issues:use new 'utf-8' address type and URI-style %encoding 
on downgrade; message/delivery-status --> messages (note that ORCPT 
value is xtext, so kind of double-encoding would occur). 
message/delivery-status --> message/utf-8-delivery-status, other option 
to use message/delivery-status; charset=utf-8 but that hard to use in 
many architectures for content return: message/rfc822 vs message/utf-8
--leaning towards message/utf-8 due to interaction with IMAP 
BODYSTRUCTURE interaction, if any unextended IMAP server hit a 
message/rfc822 with UTF-8 addresses, the returned BODYSTRUCTURE would 
probably give IMAP clients trouble
--need localized & i-default error text
--- end-user sees DSNs, needs comprehensible reason string
--pguenther: how to know which language to return?
--chris: Alexey's draft has LANG command for session and a LANG 
parameterfor MAIL command for the transaction
--Ted: this could have come up before EAI. Why didn't it?
Chris: there has been SMTP LANG extensions floating around for years, as 
a server vendor, have had requests for this, primarily from Japanese 
customers

E.Header draft
--resolved issues: a)marker on messages: "UTF8SMTP: UTF8" header field, 
  "UTF8SMTP: downgrade" for downgraded messages, b)I18mail address 
*always*has angle brackets
--open issues:a)alt-address representation, b) UTF-8 in MIME headers.
--JohnK: when 1123 added <user@domain> sans leading phrase, some MUAs 
used a trick to parse these, that trick will blow up on the proposed 
alt-addr representation
--chris: propose we take a hum on using the proposed rep
--resnick>: Can someone give me a quick explanation of why we want a 
UTF8SMTP header?
--ted: wonky headers inserted by virus checkers. Are there people in the 
room or on the list who know or are involved
--pete: explicit marker. Redundant, but useful.
--resnick: tells you whether it is utf8 or has been downgraded, if so, 
could they check whether they already use the proposed syntax or do 
something with them, can tell you if it started ascii-as Harald said, 
complete to have such, though no use case springs to mind, It's 
redundant, but thatmeans it might disagree with reality.
--randy: worried by syntax
--harald: takes hum for support of the syntax
--room in favor, to be taken to list
--johnk: another proposal for the marker header: use MIME-Version: 2.0
--pete: worried about why we have this header
--johnk: we've been here this before, so why not be here before with the 
old one
--chris: will anyone actually implement this as other than MUST 
generate,MUST ignore?
--harald: does anyone have a *use* for this marker? does anyone recall 
why that header was added?
--randy: useful strictly for debugging
--tony: optimization for UTF8 case?
--don't have to scan everything
--pguenther: new received: via type? Received: via UTF8SMTP ?
--randy: likes it
--johnk: like it too
--harald: so, change SMTP doc to register UTF8SMTP via type?
--ted: but this was inserted by MUA?
--randy: not a problem, because MUA uses UTF8SMTP to submit
--alexey: recall that chris registered ESMTPA/ESMTPS/ESMTPSA/... via types
--harald offers choices:
     a) leave UTF8SMTP header field in:one vote
     b) take it out: 10 votes
     c) mime-version 2.0: none
     d) can't decide: 5 votes
--harald: will take proposal to list to take it out
--next open issue: UTF-8 in MIME headers
--chris: we have real mess with filenames in mime headers 
(content-disposition), would be real good if we deprecated the existing 
coding methods and replaced them with unencoded UTF-8
--pete: non-controversial to say we want that, but what's the downgrade? 
deprecate 2231 and use 2047?
--chris: yep
--pete: worried about _us_ (EAI WG) deprecating 2231
--William Leibzon: what about other MIME using groups?
--Kazunori Fujiwara: makes downgrade much harder; have to walk MIME 
structure, go to 2231
--allow in mime-version: 2.0 ?
--straw poll: most people don't know whether we should do this
--straw poll #2: 2231 vs 2047 vs don't know? Answer: don't know
--alexeymelnikov: Excuse my ignorance: Is UTF8SMTP header field is the 
same as Header-Type in draft-ietf-eai-utf8headers-02.txt?
--johnk: or we could jsut drop the filename parameter when it contains 
non-ASCII

F.Downgrade document
--Resolved issues: conversion is used , not encapsulation: target is 
ASCII mail users.
--open issues:
   - downgrade: header fields for storage of prev-converted data
   - representation of utf8 address after conversiom?
   - bounce vs leave out when addresses in header donm't have alt-address
   - headling of 2047/2231 in header when already present
   - MIME body part headers
--chris: should be selective about data for which we preserve the 
pre-conversion form, thinks we should preserve original addresses and 
leave out everything else, don't need to preserve which header had the 
utf8 form. we need to preserve the mapping of ut8-address to 
ascii-address, i.e., don't need to record that a given utf8 address 
appeared in the 'to' header but just that a given ascii address was the 
alt of particular utf8 address
--pete: worried when stuff it isn't perfectly reversible
--alexey: +1 on Pete's concern
--pete: only stuff we can't downconvert are addresses, so, use 2047/2231 
for others and downgrade header for addresses only
--william: prefer encapsulation
--harald: rejected by list. DKIM is problem; so don't go there? 
consensuson keeping address original forms but not other headers.
--Pete Resnick: DKIM is just like any signing/encrypting situation: The 
only choice is to encapsulate and you won't be able to verify anything 
outside of the encapsulation. That means DKIM can't verify at the server 
level. Bummer, but that's what you get. downgrade everything at gateway 
before signing...?
--harald: what to do with header address w/o alt-address? drop address 
orbounce?
--johnk: uncomfortable with anything but bounce less so with leaving a 
comment
--barry: how is this different from messages to N people where M bounce?
--johnk: change to header
--daveC: this is effort to enhance mail system, not replace it, right? 
Dropping addresses/headers seems like crossing of fine-line into having 
twoemail systems that are being gatewayed
--pete: really think deleting headers is Wrong Thing. Violation of 
envelope/header separation?
--randy: agrees with john+pete. bouncing important during upgrade, so 
that people know how to fix things
--barry: sender doesn't care or screwed up, or address _has_ no equiv; 
noway to reply, loss is a given; sender didn't provide alternate, would 
still prefer to deliver
--<marcos> Is there any precedence case of header deletion in the specs?
--Yao: prefer bounce; alternative sends useless message
--barry: bouncing may put sender in odd situation where they may need to 
pull address and resend, no?
--ned freed: deja vu all over again, downgrading in the 8bit mime case 
similar bouncing is problematic: blowback spam (aka joe jobs) confidence 
inanti-spam required?
--randy: do we really have another choice? proposals for better bounces 
exist, deleting header or address is worst case, cause neither end sees 
the change
--ned: so annotate the removal in the message
--Yao: bouncing lets sender improve the situation; retry with ascii 
address, etc
--Ted: "learning experience for the user" is _not_ a good thing very 
expensive, very rare that people will have control of stuff in the 
middle, oreven be aware of it. suggest that WG make it task to find a 
third solution.
--randy: DSN extensions provide tools for recognizing bounces, tie DSN 
support into UTF8SMTP support?
--chris: the model for email is that envelope is transport, header is 
"commentary", not related to transport is bouncing based on content a 
violation of the model? given address books, bouncing based on headers 
may makeit impossible to send a message to mixed EAI and non-EAI users
--william: bounce is best of bad choices so far; drafts for each 
alternative?
--harald: strong opinion in room that dropping header is bad
--pete: dropping includes downgrade header?
--harald: doesn't matter, strong against either way
--<resnick> So long as you get the Downgraded header, I think deleting 
the original and not bouncing is fine with me.
--harald: bouncing has problems
--harald: <need magic here>

G.End-system docs
--POP3: no open issues
--IMAP: waiting on IMAP ENABLE draft
--IMAP waiting on downgrade and DSN
--mailing lists: randy taking on this draft
--Cyrus: Contributing a draft on a "UTF8 IMAP".
--has open issues, randy given free rein for now

H.Other docs
--forward as attachment in scope?
--encapsulation: needed for DSN content return; adopt as WG doc?
--pete: +1
--mailto: URI
--wait until core set published?
--scenarios doc: polish and publish?
--ted: volunteers for action item, but needs help: lots of other IETF 
stuff thinks it knows what an email address looks like
--johnk: clarification on the instructions to him: what should he do for 
items that are "resolution uncertain"
--harald: make sure you're happy with the resolutions that exist; john 
tomove as expediently as reasonable
--doug Otis: problems with munging of downgraded but not
--johnk: read drafts

I.Key Points Summary
-- Verison 04 of Framework draft will be passed to IESG
-- Chris will take the DSN draft.
-- randy taking on mailing list draft

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 22 Dec 2006 12:57:11 +0100

Harald Alvestrand wrote:

> --alexey: recall that chris registered ESMTPA/ESMTPS/ESMTPSA/... via types

A complete set is UTF8SMTP, UTF8SMTPA, UTF8SMTPS, UTF8SMTPSA.

What about the LMTP set, does anybody care, or can we lump
that together ?  Maybe using USMTP[S][A], where "US" stands
for either "ES" plus UTF-8, or "L" plus UTF-8.

> --pete: worried about _us_ (EAI WG) deprecating 2231

IFF it's done (2231 isn't completely bad) please do it fast,
some 2231 considerations in USEFOR could be still trimmed.

> --barry: sender doesn't care or screwed up, or address _has_
> no equiv; noway to reply, loss is a given; sender didn't
> provide alternate, would still prefer to deliver

Strong NAK, "prefer to deliver" is a wrong decision, "prefer
to reject" MUST be the first choice.  80% of mail is spam, we
don't need wannabe-improved UTF-8 one-way spam to achieve 95%.

> --ned freed: deja vu all over again, downgrading in the 8bit
> mime case similar bouncing is problematic: blowback spam (aka
> joe jobs) confidence inanti-spam required?

SMTP without SPF (or something better covering the RMX idea) is
FUBAR since the day when RFC 1123 5.3.6(a) was published.  With
"reject at the MX" legit senders get at least a fighting chance.

> --harald: <need magic here>

4408 is the only game in town, not counting the pre-1123 SMTP.

Frank