Meeting Minutes and Summary of EAI Jabber Interim Meeting May 14, 2012 The summary below was organized by topic and document; it only loosely reflects the order of the meeting discussion. A summary of critical-path issues for the WG was posted to the mailing list just before the meeting started: http://www.ietf.org/mail-archive/web/ima/current/msg04787.html. The Jabber log for the meeting is at http://www.ietf.org/jabber/logs/eai/2012-05-14.html There was a general discussion about whether the EAI POP and IMAP documents should be shown as updating the associated base specifications (RFCs ???? and 3501 respectively). The conclusion, after much circling around, was that they are extensions that actually don't update or change the base documents. However, the question of whether extension specifications update base document is really a matter for the IESG to decide and shepherd's reports will reflect that observation. Regarding IMAP-UTF8 draft - IMAP LANG will return language list in no specific order. - IMAP LANG will not return 'default' in the language list. - IMAP use ENABLE to manage mode switch -- no additional commands or options to support partial UTF-8 header field or address capability. - As a result, the UTF8 parameters were dropped from SELECT, EXAMINE, LIST, LSUB, hence all of the related responses as well - New text suggested dealing with text about transitions and downgrading by concentrating the discussion into this draft (to be referenced from the POP-UTF8 one) after as much text as possible has been moved into the downgrade documents. The idea of removing as much transitional text as possible to the downgrade documents was to avoid clutter once EAI capability is widely deployed. Group at interim meeting supported this approach and the general outline for proposed text. Regarding both downgrade drafts - Neither downgrade drafts will update RFC5322, RFC3501 - Downgrade docs will not critique each other: the WG's conclusion is that they may be appropriate under different circumstances and that yet other circumstances may call for yet other approaches (such as simply refusing to deliver an extended message to a legacy client). The WG does not believe it would be productive to try to create a case analysis of which techniques would be most appropriate under which circumstances at least until some experience accumulates (and possibly ever because the decisions may be determined by local operational circumstances). - There is no WG consensus to try to use ".invalid" email addresses in the downgrade process. A separate email will be sent to the WG mailing list about this issue. - Both downgrade drafts will publish as Proposed Standard, with PROTO write up addressing the rationale. Regarding approach to downgrade and empty group at "From:" - A suggestion made about writing a 'mini-doc' that updates RFC 5322 and specifies the use of an empty group in "FROM:". The suggestion will be brought to the mailing list for further discussion even though this WG is probably not the right place to process that specification. If agreed, Barry Leiba and John Klensin will try for first rough draft.