EAI Minutes IETF 68 - Prague, Czech Republic 20 March 2007 Eric Burger, Scribe Framework Document ------------------ Issue: Some uncomfortable with wording of MTA / Message Store split. Resolution: Current wording is acceptable to the work group. The document is finished. SMTP Extensions draft-ietf-eai-smtpext-04 ------------------------- Issue: Should a UTF8 server send UTF8 to non-UTF8 hosts? Resolution: Let editors work out and propose to group Issue: Do we need an explicit tag per message indicating the message is UTF8 (HDR=UTF8SMTP)? Discussion: Either transaction states UTF8 is present or the MTA figures it out. On the philosophy (Dave Crocker), "Is it cheap and is it safe?" John Klensin pointed out that every header is expensive, and a few people mentioned that one had to trust all of the next hops. Resolution: VERY ROUGH consensus that we do not need the parameter. Some holdouts to keep the parameter. Will take to list. UTF8 Headers draft-ietf-eai-utf8headers-03 ----------------------------- A few nits in the document, but no substantial issues. New -04 draft to come out which should be ready for WGLC. DSN draft-ietf-eai-dsn-00 --------------------- Issue: Cannot use xtext, because DSN requires the removal of 8-bit characters when going to 7-bit SMTP servers. Already have to encode 5 reserved ASCII characters; today hex-encode Unicode; it should be UTF8 Options: 1. Use xtext for ASCII and something else for UTF-8 2. use %xx encoding of UTF8 or \uxx encoding of Unicode Point: desire to not do double-encoding (although Pete pointed out that there already is double encoding for IRI's) Resolution: NONE (3-3 vote). Take to list Note: Alexey will be the new editor Issue: Should message encoding be application/utf8smtp or message/utf8smtp Discussion: MIME allows 8-bit types, but explicitly prohibits 8-bit message types for message/* Argument in favor of message/utf8smtp: the object is a message. Argument against message/utf8smtp: may break 7-bit implementations Argument for application/utf8smtp: will work with everything, since application/ is supposed to be treated as application/octet-stream Argument against application/utf8smtp: automated DSN processors might barf on 8-bit content Argument against (soft) message/utf8smtp: the use will leak out, e.g., multipart/digest Resolution: do message/utf8smtp; fix broken implementations (if any) Issue: what about utf8headers? Should it be text/utf8header or message/utf8header? Resolution: NONE. Slight preference for message/utf8header, but nowhere near consensus. Take to list. Downgrade draft-ietf-eai-downgrade-03 --------------------------- Issue: Is upgrading important Discussion: Useful, as we can get rid of RFC 2047 encodings as close to the client as possible. Consideration, however, that this is more of an access protocol (POP, IMAP) issue than SMTP issue. Upgrades break DKIM. Upgrades in the network are likely to be buggy. Upgrades likely to break signatures. Why would servers, which get graded on speed, spend time doing conversions? Hum called on whether to have no upgrades; upgrade at MTA in network, upgrade at "recipient system" for display, reply address, and checking signature; or upgrade for display and reply address and NOT for checking signature. Resolution: Strong consensus on upgrading at the "recipient system" for display and reply address and NOT for checking signature. At this point, Dave Crocker agrees with John Klensin. John shudders. IMAP draft-ietf-eai-imap-utf8-01 --------------------------- Issue: How to enable UTF8 in IMAP data elements? Modally or with new, UTF8-enabled, commands? Discussion: RFC 3501 states 7-bit only unless explicit charset specified. Proposal: allow all fields to be UTF8 unless otherwise specified Problem: IMAP capabilities model is server advertises capabilities, but server only deduces client capabilities from what the client requests. Proposal: use explicit ENABLE command Discussion: IMAP-EXT and LEMONADE like approach. Resolution: Consensus to use ENABLE command to enter "UTF8 mode" To do: Fix LOGIN command to allow UTF8 (editors) To do: verify ENABLE command OK with IMAP community (Pete Resnick) POP draft-ietf-eai-pop-01 --------------------- Since very few commands, and easy to get modality wrong, consensus is to create new, UTF-enabled, commands. Mailing Lists draft-ietf-eai-mailinglist-01 ----------------------------- Issue: Can we infer that a mailing list that happens to have only ASCII addresses is not a UTF8 mail list? Discussion: No - The recipient's address does not define their capabilities. Moreover, no hints from a subscription e-mail, as it might be in ASCII or, more likely, the subscription happened over the web. Resolution: Just describe the issues in the text. Issue: What to do with list-* headers: only use ASCII; use UTF8; use IRI's; use multi-valued (ASCII, UTF8) addresses, which is already allowed; use new, UTF8-specific, headers/ Discussion: The mailto: scheme needs to deal with UTF8 and IRI's Resolution: list-* takes URI's; mailto: is a URI scheme; when mailto: takes IRI's or UTF-8 in the future, this just will work To do: warn developers today list-*'s may be 8-bit today Issue: Should Return-path be ASCII or UTF8SMTP (envelope return path, not list reply address)? Should it always be ASCII, as that will work with everything? Alt-address does not have syntax today. Discussion: For automatically generated messages, e.g., NDN's. Proposal: Provide ASCII and Alt-Address so that it is possible to downgrade the response Resolution: Too early to decide; try some experiments. Scenarios Document draft-ietf-eai-scenarios ------------------------ Issue: Publish, hold, or let draft lapse? Resolution: Hold the document Downgrade draft-ietf-eai-downgrade-03 --------------------------- Issue: What to do about uFor in Received: header? Discussion: Current text says to delete it. Problem is total loss of traceability. Proposal: Encourage gateways to insert additional Received: headers and put the original information in comments, e.g., Received: by ME for ME ; describe what happened To do: John Klensin to write text