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

[Kari Hurtta <hurtta+gmane at siilo.fmi.fi>]

John C Klensin <klensin at jck.com> writes in gmane.ietf.ima:

> --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.

Yes. I agree. 

If we suppose that legacy formats vanish, we should not
require conversion support for them.   


> 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.

Replace "format that is in the mailstore" with "format on what local
system received messages".

/ Kari Hurtta


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