Re: [EAI] How to prevent up-conversion (Re: Respawn "Messages on original form" (Re: I-D ACTION:draft-ietf-eai-imap-utf8-01.txt))

[John C Klensin <klensin at jck.com>]

--On Wednesday, March 21, 2007 07:49 +0000 Chris Newman 
<Chris.Newman at Sun.COM> wrote:

> There are three formatting options:
> 1. A format compatible with requirements of RFC 3501.
> 2. A format with minimal RFC 2047/2231 turds.
> 3. The format that is in the mailstore (initially this will be
> identical to 1,
>    but as EAI-aware mailstores are deployed it should become
> indistinguishable
>    from 2).
>
> The protocol must offer 1 to preserve interoperability.  The
> current proposal offers options 1 and 2.
>
> And argument could be made the protocol should offer option 3
> instead of option 2.  I would be interested in that debate.

To start the debate, I will pose my usual question: if we were 
developing this with no constraints from the legacy (ASCII, in 
this case) environment, what would we do?  I think, in this 
case, that points to option 3.  And that, in turn, argues for 
precisely the 1/3 case rather than the 1/2 case, with 1 
supported primarily for legacy compatibility purposes.

My only concern about that reasoning is that there are some 
advantages of maintaining an abstraction between "what is in the 
mailstore" and "the image/view of the mailstore content that is 
seen by a client".  I don't think the above prevents that, but 
we need to be careful about reading.  Access to the mailstore 
version on a "by reference" basis is pretty close to a 
showstopper for me: we should not be specifying those formats at 
all, only what must be able to be produced from them.

> If you are are suggesting the protocol offer both options 2
> and 3 in addition to 1, then I would question if the benefit
> merits the additional complexity.

Concur.

    john


_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima