MBOX-Line: From mrc+imap at panda.com  Sun Oct 30 20:58:06 2011
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] BODY.PEEK[section]<origin.size> FETCH response
In-Reply-To: <1D4C80A2-BD6A-4888-9A21-29D746896D97@ghoti.org>
References: <8F0DA5FA-FB07-4AFA-9C58-8F0927998343@ghoti.org>
	<alpine.OSX.2.00.1110301823210.9034@hsinghsing.panda.com>
	<1D4C80A2-BD6A-4888-9A21-29D746896D97@ghoti.org>
Message-ID: <alpine.OSX.2.00.1110302053130.9034@hsinghsing.panda.com>

On Sun, 30 Oct 2011, Ashley Clark wrote:
> The server responding with the matching 0 origin was running Dovecot. I
> don't know the implementation of the other server and don't have ready
> access to UW or Cyrus.

Well, I think that you have gotten your answer. I can tell you that Panda
(nee UW) does the same, and I am certain that Cyrus does.

> It seems that the origin must be relative to the start of the part that
> is being requested in both the request and response but I didn't see it
> clearly stated in the RFC. Is this a safe assumption?

Yes. And if you think about it, no other interpretation makes any sense at
all. The IMAP specification was not developed capriciously; everything in
IMAP has a reason why it is that way. In a few matters of syntax, it was
because of compatibility with the past. But in the case of a partial
specifier, the only thing that could possibly be useful is the offset from
the start of the part - particularly when you consider asynchronous
multiple partial fetches and subseqeunt reassembly.

In general, you will notice in IMAP that the types in fetch responses
mirror what was requested. That is by design.

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

