[EAI] EAI critical path issues

[John C Klensin <[e-mail]>]

Hi.

Sorry to be posting this just before the meeting, but I wanted
to see if anything would be posted over the weekend that would
help clarify issues.  This note attempts to summarize what
appear to me to be the critical-path outstanding issues in the
hope it can help focus our agenda.

No particular order; writing as co-chair except where noted.

(1) IMAP: Is "{SELECT, LIST,...} UTF-8" necessary and/or
desirable.  If so, do we intend to permit a client to specific
that it accepts EAI syntax but not EAI messages?.  This question
doesn't seem to have a POP analogy -- is that true and does that
answer help inform the decision.

(2) IMAP: Murray's note of 23 April raises an issue about LANG
that does not appear to have been answered on-list.

(3) Do weintend to allow a critique of popimap-downgrade (or
other approaches) in simple=downgrade or vice versa?

(4) popimap-downgrade: Does this update 5322?

(5) popimap-downgrade: Given that we are going to publish this
spec, is the rewrite model acceptable or do we intend to change
it?  Personal note: the model that is there has been refined,
presumably, by many months of exposure in the WG.  Do we really
have sufficient consensus for restarting that discussion.

(6) The two downgrade specs are currently on track for Proposed
Standard?  Do you we have consensus for starting a discussion
about Information or Experimental instead?

(7) fter going through all four documents again and, to my
personal relief, having gotten no traction for reopening RFC
6530 ("Framework"), I think we should consider:

7.1 Adding a paragraph to the IMAP spec (5738bis) that makes
three points explicitly:

	(i) Unless it knows that all mail-reading clients that
	might be used have been upgraded to be EAI-compliant or
	the associated delivery MTA doesn't advertise UTF8SMTP,
	an IMAP (or POP) server or mail store that supports EAI
	messages must anticipate that it will receive
	connections and message requests from mail-reading
	clients that are not EAI-capable.   

	(ii) Whatever decision a server makes about how to
	handle that case will lose information -- either hiding
	the message, replacing it with an error response, or
	creating a variation on the message that is
	EAI-compatible (the latter is known as "downgrading"
	but, because there will be significant information
	losses in many cases, the result is really a variant
	message, not a downgrade.  There are no completely
	satisfactory solutions to this problem: the best answer
	is obviously for users who might receive messages that
	require EAI capabilities to upgrade all mail-reading
	mechanisms that might use.  The choice among the best
	ways to encourage users to upgrade and supply
	appropriate information while doing so will depend on a
	series of tradeoffs that should recognize the
	particulars of the mail environment, implementation cost
	issues, expectations of how quickly conversions will
	occur, assumptions about the ratio of messages that
	require EAI capability and those that do not, and
	perhaps other issues.  The WG cannot predict the future
	well enough to make a single, definitive, recommendation
	in this area.
	
	(iii) In many environments, a given user may use
	multiple mail reading approaches, perhaps an IMAP client
	on one occasion, a POP client on another, webmail access
	at other times, and a different POP or IMAP client at
	still other times.  Because of this, a server cannot
	convert a message to "downgraded" form and use that form
	to replace the original message in the store without
	completely disabling EAI capability.  In principle, a
	server can be designed to keep a "downgraded" version in
	combination with the original one, selecting the
	appropriate one when the client request arrives, but
	that is an implementation optimization, not a
	specification requirement.

7.2 The two "downgrade" specs should be reference from that
section as examples -- nothing more or less.

7.3 All other text about downgrading should be removed from the
IMAP spec.

7.4 All text about downgrading should be removed from the POP
spec and a reference to the above substituted.


Does that help move us forward?

Chat with you all soon.
    john