Minutes for EAI at interim-2012-eai-1
minutes-interim-2012-eai-1-1

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.