Re: [PATCH 2/4] Introduce a generic tree-like abstraction for MIME traversal.

[Austin Clements <amdragon@MIT.EDU>]

Quoth Jameson Graef Rollins on Dec 10 at  1:17 pm:
> On Sat, 10 Dec 2011 03:25:48 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
> > +           out->is_encrypted = TRUE;
> > +           out->is_signed = TRUE;
> > 
> > These are set only if we do decryption/verification.  But their
> > names and comments imply that they should reflect properties of
> > the part and be set independently from whether we are actually
> > doing decryption or verification.
> 
> I don't think this directly affects anything at the moment, but this is
> a good point.  I can imagine that it might be good to maintain that
> distinction down the line so it's probably worth being consistent here.

See my response to Dmitry's original email.  The structural properties
can be derived directly from the type of the part field, so I got rid
of these fields.

> > Both decryption and verification use cryptoctx.  But decryption
> > is done iff decrypt is true (without checking if cryptoctx is
> > set) and verification is done iff cryptoctx is set (without any
> > special flag).  Why is it asymmetric?  Do we need to check if
> > cryptoctx is set for decryption?
> 
> We probably should.  We can probably fix this in followup patches, since
>  Austin is just working off of what dkg and I put in there originally.

Actually, this one was my fault from when I tweaked the control flow
to use the MIME node context.