[EAI] Side note (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+ietf at siilo.fmi.fi>]

Kari Hurtta <hurtta+ietf at siilo.fmi.fi> writes in gmane.ietf.ima:

> >>> Chris Newman
> > 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.
> > 
> > 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.
> > 
> >                 - Chris
> 
> 
> My point is that there must be possibility to get
> 
>      The format that is in the mailstore
> 
> ( I accept upgrade only for messages, which are downgraded
>   UTF8SMTP messages. Do not mess with other messages. )
> 
> 
> To me it does not matter, is there optionally also possible get
> 
>       A format with minimal RFC 2047/2231 turds.
> 
> whatever that means.
> 

Note that I'm talking other FETCH items than BODYSTRUCTURE 
or ENVELOPE. 

Specially that means RFC822 and BODY[] items.
(specially items like BODY[], BODY[HEADER], BODY[TEXT], RFC822,
 RFC822.HEADER, RFC822.TEXT )


( not BODY which is like BODYSTRUCTURE )

 
  
/ Kari Hurtta



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