Thanks for the reply, David!

On 11/13/2010 06:40 AM, David Bremner wrote:
> Are both the forward and backward pointers needed?

Technically, only the "signs" pointer is needed, i guess.  I had
included the "signedby" pointer so that frontends which process the list
linearly know that a signed part will be referred to later by one or
more signatures.

If you think that's not actually useful, i'd be happy to drop the
"signedby" pointer.  What do other people think?

>> Would it make more sense to do deeper structural modifications of the
>> json output (e.g. return the full MIME tree instead of a list of parts)
>> than to go with the current proposal?
> 
> Yeah, this occured to me too, especially since I think David Edmondson
> has some changes in mind to support better handling of
> multipart/alternative parts.

Another related concern that occurred to me is that parts E and F in my
example mail are technically part of the aggregate that is signed by I,
but they apparently the end-user won't even know they exist (unless the
frontend uses "notmuch show --format=mbox").

This seems problematic if the message headers of the included message
have relevance to the content.  e.g. an e-mail that says "here's the
phishing attempt i received" (Received: would be relevant) or "Look at
the nasty things this guy said!" (From:, Subject:, and Date: would be
relevant at least).

David Edmonson, i'd be interested in hearing your proposal for
restructuring the output to see how it might interact with my pieces here.

I also found it interesting to consider the range of possible non-leaf
MIME types:

 https://secure.wikimedia.org/wikipedia/en/wiki/MIME#Multipart_messages
 http://www.iana.org/assignments/media-types/multipart/

	--dkg