MBOX-Line: From mrc+imap at panda.com  Sun Nov 27 08:34:40 2011
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] [noob] fetch command with repeating
 attributes?
In-Reply-To: <BAA75CE5-7AE6-4C96-821E-A56A41337B9F@mac.com>
References: <BAA75CE5-7AE6-4C96-821E-A56A41337B9F@mac.com>
Message-ID: <alpine.OSX.2.00.1111270821030.931@hsinghsing.panda.com>

On Sun, 27 Nov 2011, Petite Abeille wrote:
> Can the fetch command contain the same attribute multiple times?

Yes.

> For example, the following request , curtesy of dbmail test suite [1],
> sports the BODY.PEEK attribute twice, for two different header fields:
> C0000A UID FETCH 1:* (BODY.PEEK[HEADER.FIELDS (Subject)] BODY.PEEK[HEADER.FIELDS (Message-Id)] ENVELOPE RFC822.SIZE UID FLAGS INTERNALDATE)
> Is such fetch request compliant?

Yes.

> Can the fetch attributes be repeated multiple times?

Yes, but that is not a repeated fetch attribute.

BODY[HEADER.FIELDS (Subject)] and BODY.PEEK[HEADER.FIELDS (Message-Id)]
are two entirely different FETCH attributes. The stuff in the [] is part
of the fetch attribute, and thus makes the two different. By special
dispensation, ".PEEK" is not part of the attribute and does not appear in
the response.

An example of a repeated fetch attribute is this pointless example:
 	tag FETCH 1 (UID RFC822.SIZE UID)

In this case, UID is repeated. This is valid/compliant but pointless. The
server may respond by sending the UID twice, or it may send it just once;
either way satisfies the request. On the other hand, nothing prevents a
server from (pointlessly) sending UID twice. So, in the end, the effect is
identical to:
 	tag FETCH 1 (UID RFC822.SIZE)
even if some servers may be babble more

Also, consider this pointless example:
 	tag fetch 1 (BODY.PEEK[HEADER.FIELDS (Subject)] BODY[HEADER.FIELDS (Message-Id)]

The response and effect is identical to
 	tag fetch 1 (BODY[HEADER.FIELDS (Subject)] BODY[HEADER.FIELDS (Message-Id)]

This is because the same attributes are fetched, and the second BODY
(without the .PEEK) causes the \Seen flag to be updated as if the first
.PEEK was not there.

IMAP does not prevent pointless client commands; however the server is
supposed to behave sensibly.

> If yes, what's the expected response? Two BODYs, one for each header?

Yes.

BODY[HEADER.FIELDS (Subject)] and BODY.PEEK[HEADER.FIELDS (Message-Id)]

> One BODY with the two requested fields? Either?

No. That would be a response with a different FETCH attribute. The server
must respond with the requested attributes.

If the client requested Subject and Message-Id separately like that, it
wants them returned separately. If it wanted them together, it would have
requested them together:
 	tag fetch 1 (BODY[HEADER.FIELDS (Subject Message-Id)]

In this case, the server MUST return attribute
 	BODY[HEADER.FIELDS (Subject Message-Id)]
with a single string containing both.

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

