MBOX-Line: From guenther+imap at sendmail.com  Sun Mar 11 15:46:57 2007
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] question on BODY[n.MIME]? 
In-Reply-To: <07Mar11.133752pst."57996"@synergy1.parc.xerox.com>
References: <07Mar8.112542pst."57996"@synergy1.parc.xerox.com>
	<alpine.OSX.0.83.0703081129120.11046@pangtzu.panda.com>
	<07Mar8.141232pst."57996"@synergy1.parc.xerox.com>
	<alpine.WNT.0.83.0703081500000.4212@Tomobiki-Cho.CAC.Washington.EDU>
	<07Mar11.123637pst."57996"@synergy1.parc.xerox.com>
	<1173646260.17598.293.camel@hurina>
	<07Mar11.133752pst."57996"@synergy1.parc.xerox.com>
Message-ID: <Pine.BSO.4.64.0703111632520.17904@vanye.mho.net>

On Sun, 11 Mar 2007, Bill Janssen wrote:
> Thanks.  So calling x.HEADER on a non-"message/rfc822" part should
> raise an error.

It's an error for the client to request it; AFAICT, the server's behavior 
is not constrained.  The obvious and relatively client-friendly behaviors 
are to either return a tagged BAD response or return NIL for the requested 
part.  E.g.:

tag fetch 1 body[1.header]
tag BAD Invalid section specifier for message(s)

tag fetch 1 body[1.header]
* 1 FETCH (BODY[1.HEADER] NIL)
tag OK Completed


A server that treated such a request as an undocumented extension that set 
the \deleted flag on the message would still conform, though the QoI of 
that server would generally be considered very low...


Philip Guenther


