IETF 85 - EAI  Agenda
9:00AM EST, Room 209

The primary (and probably only) purpose of this meeting is to review
the status of "UTF8=ONLY" in IMAP server capability announcements and
client ENABLE commands.  In both contexts, the question is whether
"ONLY" should be retained.  If it is not retained, should the
parameter be eliminated, resulting in a "UTF8" announcement and/or an
"ENABLE UTF8" command?

Participants are expected to be thoroughly familiar with "IMAP
Support for UTF-8" (draft-ietf-eai-5738bis-10) and with the capability
announcement and ENABLE facilities of the base IMAP specification
(RFCs 3501 and 5161) in order to participate competently in the
discussion.

Agenda:
1. Introduction and review of purpose of meeting

2. Agenda-bashing **

3. Discussion of "UTF8=ONLY", "UTF8=ACCEPT", their relationship, what
	the WG intends, and how to make it clear. ***

4. AOB **

5. Adjorn

This is expected to be the last meeting of the EAI WG before, at
least, an extended period of suspension.

** Additional topics for the agenda will be considered only if either:

(i) They are proposed on the mailing list not later than the start of
	the Wednesday plenary with a strong argument that the issues
	involved would be "showstoppers" unless resolved before the
	POP/IMAP cluster of EAI documents are approved and published.

(ii) Those who advocate taking them up are able to make a presentation
	of under two minutes at the WG meeting that persuades those in the
	room that the issues invovled would cause significant damage to
	conforming implementations or the Internet more broadly if not
	addressed.
 
*** Those with proposals for either better explanations of what is now
in the document (e.g., retain "ONLY" in both the server and client) or
an alternate plan are _strongly_ encouraged to make those proposals to
the mailing list, preferably with text, prior to the start of IETF.
It is unlikely that the WG would approve a proposal that is largely
hand-waving (nor that co-Chairs or ADs would let us get away with it).
An explanation of what is now in the document will need to include a
clear explanation of the conditions under which "ENABLE UTF8=ONLY" and
"ENABLE UTF8=ACCEPT" may be used if the server specifies "UTF8=ONLY",
i.e., how those two commands are distinct under that condition.

This meeting should not take over an hour.  If the problem cannot be
resolved in that time, it probably cannot be resolved at all, which
would be a _very_ bad outcome.  However, unless specific text is
prepared before the meeting (see above), participants should expect
that a drafting committee will be appointed at the end of the first
hour.  At that point the meeting will be temporarily suspended and
then reconvened at 10:30 AM to review and approve the proposal.

Warning: because this document has already completed IETF Last Call,
the conclusions for this meeting will be posted to the mailing list
for review and with a _very_ brief period for objections.  Those who
might have objections should be prepared to voice them no later than
2359 UT on 12 November.