Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages

From: Graham Klyne <[email-masked]>
Date: Tue, 22 Sep 1998 11:13:53 +0100

At 15:47 17/09/98 -0700, Ned Freed wrote:
>> I'd like to see a convention established for interpreting the
>> message/rfc822 type in this way, possibly when accompanied by some
>> other syntax.
>
>I agree that this would be useful functionality -- I've suggested adding
>it several times in the past, but was never able to get much support
>for it.
>
>Its clear that this indicator has to be on the "inside", since you want the
>signature to be able to cover it. This then begs the question of whether
>it should be an attribute of the signature/encryption facility or of the 
>MIME message/rfc822 content.
>
>I personally favor a message/rfc822 parameter, but I can also see a case for
>putting it elsewhere. What do other people think? If there seems to be
>consensus that this needs to be on message/rfc822, I'd be happy to write
>a short draft defining such a parameter.

It sounds as if this might be a role for content-disposition.  In a
non-RFC822 environment, one might wish to apply the "promotion" principle
for content types other than message/rfc822, and to encapsulations other
than signature/encryption.

#g

------------
Graham Klyne
([email-masked])

---

From: Ned Freed <[email-masked]>
Date: Tue, 22 Sep 1998 09:32:09 -0700 (PDT)

> than signature/encryption.

I considered a content-disposition value, but quickly rejected it. My reasons
include:

(1) This usage is specific to message/rfc822; it doesn't make sense on other
    content types. Dispositions are supposed to apply regardless of type, and
    definitely shouldn't be highly type-specific.
(2) Applications may want to specify a disposition for a message independent
    of security handling. This results in the one field being used for two
    things.
(3) This isn't a disposition per se; it is structural handling information.

				Ned