MBOX-Line: From norman at apache.org  Fri Apr 15 11:17:20 2011
To: imap-protocol@u.washington.edu
From: Norman Maurer <norman@apache.org>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] FETCH Response
In-Reply-To: <alpine.OSX.2.00.1104151032550.797@hsinghsing.panda.com>
References: <BANLkTi=fFBXLWaJ9bnnjm2dO0uYJPGGnkQ@mail.gmail.com>
	<alpine.OSX.2.00.1104151032550.797@hsinghsing.panda.com>
Message-ID: <BANLkTi=p5s7Vnri5p44Yuzq2M-Y9x-HWAw@mail.gmail.com>

Hi Mark,

this was exactly what I was refer to, and the answer I needed. Sorry
the \ where there by mistake..

Thanks again for your help :)

Bye,
Norman


2011/4/15 Mark Crispin <mrc+imap@panda.com>:
> It took me a while to figure out what you were asking in your example, as
> you omitted some important information: specifically, the BODYSTRUCTURE
> that identified the type/subtype/encoding of message part 3. ?Also,
> where did those spurious \ in the server responses come from?
>
> Anyway, I think that your answer is as follows:
>
> The BODY section specifiers HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and
> TEXT only apply to message parts of type MESSAGE/RFC822. ?Implicitly, the
> entire message (the top level) is typed MESSAGE/RFC822.
>
> Your example presumably shows a TEXT/HTML message part with encoding
> BASE64. ?At least, the BODY[3] contents appeared to be BASE64, and when
> put through a BASE64 decoder came up with a short HTML document.
>
> In other words, HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT are all
> meaningless for BODY[3] in this example. ?The appropriate server behavior
> is:
>
> C: A18 FETCH 1 BODY[3.HEADER]
> S: * 1 FETCH (BODY[3.HEADER] "")
> S: A18 OK that was a silly thing for you to do!
> C: A19 FETCH 1 BODY[3.TEXT]
> S: * 1 FETCH (BODY[3.TEXT] "")
> S: A19 OK that was a silly thing for you to do!
>
> As a matter of good design, you should always use an zero-length quoted
> string, rather than a zero-length literal, to represent the empty string.
> Of course, implementations MUST accept either form.
>
> The reason why you don't have a blank line in the 3.HEADER fetch is that
> there is no "message" (it is a TEXT/HTML, not a MESSAGE/RFC822) and thus
> if you are substituting an empty string the "message which has no body and
> no blank line" rule applies.
>
> If I were to do things over today, I would have required:
>
> C: A18 FETCH 1 BODY[3.HEADER]
> S: A18 BAD meaningless to fetch header for type TEXT/HTML
> C: A19 FETCH 1 BODY[3.TEXT]
> S: A19 BAD meaningless to fetch header for type TEXT/HTML
>
> It's historical as to why meaningless text fetches return the empty string
> rather than a BAD; there were good reasons once upon a time but those
> reasons have long since been rendered moot. ?A related history is why
> BODY[1] and BODY[TEXT] are equivalent for a non-MIME message.
>
> -- Mark --
>
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
>

