83 lines
3.0 KiB
Plaintext
83 lines
3.0 KiB
Plaintext
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.
|
|
|