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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
