mailing list archives

Hi there,

while reading the rfc3501 and think about FETCH Response one question
come in my mind. The rfc says:

BODY[<section>]<<partial>>
...
...
         The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
         specifiers refer to the [RFC-2822] header of the message or of
         an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
         HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
         field-name (as defined in [RFC-2822]) names, and return a

         subset of the header.  The subset returned by HEADER.FIELDS
         contains only those header fields with a field-name that
         matches one of the names in the list; similarly, the subset
         returned by HEADER.FIELDS.NOT contains only the header fields
         with a non-matching field-name.  The field-matching is
         case-insensitive but otherwise exact.  Subsetting does not
         exclude the [RFC-2822] delimiting blank line between the header
         and the body; the blank line is included in all header fetches,
         except in the case of a message which has no body and no blank
         line.

So if I have a multipart message which has a body but no "BODY TEXT"
should the single newline get written when ask for headers nor not ?

C: A16 FETCH 1 (BODY[3])
S: \* 1 FETCH \(BODY\[3\] \{1124\}
S: PGh0bWw\+PGhlYWQ\+PHRpdGxlPjwvdGl0bGU\+PC9oZWFkPgo8Ym9keT4KPGJsb2NrcXVvdGUgY2l0
S: ZT0naHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9XaWxsaWFtX1NoYWtlc3BlYXJlJz48cHJl
S: PgpUaG9zZSBwYXJ0cyBvZiB0aGVlIHRoYXQgdGhlIHdvcmxkJ3MgZXllIGRvdGggdmlldwpXYW50
S: IG5vdGhpbmcgdGhhdCB0aGUgdGhvdWdodCBvZiBoZWFydHMgY2FuIG1lbmQ7CkFsbCB0b25ndWVz
S: LS10aGUgdm9pY2Ugb2Ygc291bHMtLWdpdmUgdGhlZSB0aGF0IGR1ZSwKVXR0ZXJpbmcgYmFyZSB0
S: cnV0aCwgZXZlbiBzbyBhcyBmb2VzIGNvbW1lbmQuClRoeSBvdXR3YXJkIHRodXMgd2l0aCBvdXR3
S: YXJkIHByYWlzZSBpcyBjcm93bidkOwpCdXQgdGhvc2Ugc2FtZSB0b25ndWVzLCB0aGF0IGdpdmUg
S: dGhlZSBzbyB0aGluZSBvd24sCkluIG90aGVyIGFjY2VudHMgZG8gdGhpcyBwcmFpc2UgY29uZm91
S: bmQKQnkgc2VlaW5nIGZhcnRoZXIgdGhhbiB0aGUgZXllIGhhdGggc2hvd24uClRoZXkgbG9vayBp
S: bnRvIHRoZSBiZWF1dHkgb2YgdGh5IG1pbmQsCkFuZCB0aGF0IGluIGd1ZXNzIHRoZXkgbWVhc3Vy
S: ZSBieSB0aHkgZGVlZHM7ClRoZW4tLWNodXJscy0tdGhlaXIgdGhvdWdodHMsIGFsdGhvdWdoIHRo
S: ZWlyIGV5ZXMgd2VyZSBraW5kLApUbyB0aHkgZmFpciBmbG93ZXIgYWRkIHRoZSByYW5rIHNtZWxs
S: IG9mIHdlZWRzOiAKICBCdXQgd2h5IHRoeSBvZG91ciBtYXRjaGV0aCBub3QgdGh5IHNob3csCiAg
S: VGhlIHNvaWwgaXMgdGhpcywgdGhhdCB0aG91IGRvc3QgY29tbW9uIGdyb3cuCjwvcHJlPjwvYmxv
S: Y2txdW90ZT4KPC9ib2R5PjwvaHRtbD4K\)
S: A16 OK FETCH completed\.
C: A18 FETCH 1 (BODY[3.TEXT])
S: \* 1 FETCH \(BODY\[3\.TEXT\] \{0\}
S: \)
S: A17 OK FETCH completed\.
C: A17 FETCH 1 (BODY[3.HEADER])
S: \* 1 FETCH \(BODY\[3\.HEADER\] \{0\}
S: \)
S: A17 OK FETCH completed\.

Or should it be:

C: A17 FETCH 1 (BODY[3.HEADER])
S: \* 1 FETCH \(BODY\[3\.HEADER\] \{2\}
S:
S: \)

Thanks,
Norman

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.

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