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 parameter for 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 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 that means 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? consensus on 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 or bounce? --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 two email 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; no way to reply, loss is a given; sender didn't provide alternate, would still prefer to deliver -- 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 in anti-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, or even 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 make it 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 -- 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: 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 to move 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