[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:

> (combined answer)
> 
> --On Monday, 26 March, 2007 16:50 +0100 Charles Lindsey
> <chl at clerew.man.ac.uk> wrote:
> 
> >> Charles Lindsey wrote:
> >>> 
> >>> Generally speaking I just regard it as a fundamental
> >>> requirement of any   internet protocol to be able to examine
> >>> what was actually on the wire,   before other agents started
> >>> to "improve" it.
> >> If taken to mean what the words mean in their dictionary
> >> definitions,   what you are asking for is packet trace.
> >> The most reasonable tools for that are called "tcpdump" and
> >> "ethereal"   (provided that your "wire" is an Ethernet, of
> >> course).
> > 
> > Yes, I am not concerned about the inner structure of TCP
> > packets. But what I DO want to see is that anyone who receives
> > an email in his MUA (whether via an IMAP storage server of
> > otherwise) can have access to the original RFC 2822 object as
> > it arrived on the wire at the final MTA. The ability to
> > provide that service constrains somewhat what IMAP
> > implementations can do internally.
> 
> I do not believe this is a requirement for IMAP implementations
> today (for all-ASCII messages).   Retrieving the various pieces
> as pieces and reassembling them doesn't count, since that may or
> may not exactly restore the original, received-by-MTA, version.
> If it is not, I suggest that it is out of scope for this WG
> until and unless IMAPext gets around to making the change for
> the base specification.

IMAP is cabable to return full rfc822 message.
There is several queries which assumes existance of rfc822 message.


RFC 3501:

      BODY[<section>]<<partial>>
         The text of a particular body section.  The section
         specification is a set of zero or more part specifiers
         delimited by periods.  A part specifier is either a part number
         or one of the following: HEADER, HEADER.FIELDS,
         HEADER.FIELDS.NOT, MIME, and TEXT.  An empty section
         specification refers to the entire message, including the
         header.
<...>

     RFC822
         Functionally equivalent to BODY[], differing in the syntax of
         the resulting untagged FETCH data (RFC822 is returned).

      RFC822.HEADER
         Functionally equivalent to BODY.PEEK[HEADER], differing in the
         syntax of the resulting untagged FETCH data (RFC822.HEADER is
         returned).

      RFC822.SIZE
         The [RFC-2822] size of the message.


      RFC822.TEXT
         Functionally equivalent to BODY[TEXT], differing in the syntax
         of the resulting untagged FETCH data (RFC822.TEXT is returned).


My MUA uses commands RFC822.HEADER and RFC822.TEXT for retrieval.
Also getting rfc822 message in one querie is possible. 

There is nothing what require asking message in parts.

/ Kari Hurtta


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