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

From: Graham Klyne <[email-masked]>
Date: Wed, 23 Sep 1998 10:18:05 +0100

At 09:32 22/09/98 -0700, Ned Freed wrote:
>> > I personally favor a message/rfc822 parameter, but I can also see a
case for
>> > putting it elsewhere. What do other people think? [...]
>
[...]
>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.

I agree -- especially your reason 3 which I realized after my earlier posting.

But, I think there is still a question whether this "structural handling"
information is specific to *just* RFC822.  The premise of my suggestion was
that the structural handling was more widely applicable.  I am toying with
a view that the handling may be appropriate to 'message/...' types in general.

A recent discusion I had concerned the actual handling differences between
'application/...' and 'message/...' (with reference in part to proposing
'application/MIME' vs 'message/MIME').  One view was that 'message/...'
indicates handling that is expected to be performed by a message handling
agent, where 'application/...' suggests some external program;  this seems
to be consistent with the idea that MIME content-types are used for
dispatching to a handling module or application.

I feel I may be going over some old ground here, and don't wish to restart
an old debate, but I would be interested in your view.

#g

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

---

From: Ned Freed <[email-masked]>
Date: Thu, 24 Sep 1998 00:18:57 -0700 (PDT)

> a view that the handling may be appropriate to 'message/...' types in general.

It certainly doesn't apply to the subtypes delivery-status or
disposition-notification. This alone makes calling it a general message type
parameter inappropriate. It would at most be a parameter specific message
subtypes could call on if needed.

It can apply to message/external-body, although it only applies indirectly
when message/external-body references a message/rfc822 object.

Message/partial already has well defined structural considerations (indeed,
these rules should serve as a starting point for defining how to recombine
message/rfc822 objects) and needs no such parameter. I actually would have
suggested using a single part message/partial for this were it not for my
belief that the reassembly rules are likely to be different in some ways.

The type message/news should never have been defined -- message/rfc822 was
designed to accomodate news messages despite its name -- and in practice is not
used. 

I don't know about message/http, but I suspect it would need its own rules. And
it isn't clear this issue exists for HTTP anyhow, or that if it does it should
be solved this way.

And that's the entire list of message types.

As a practical matter this sort of structural concern only exists when there's
a set of "outer" headers which are exposed to transport manipulation and hence
cannot be secured by putting them inside of a security enclosure. Now, this
doesn't mean such things cannot appear at an inner level -- this will happen
when someone wants to include an entire message built this way with its
security wrapper intact within another message.

But this does restrict the reasons for using this scheme.  We only have two
outer message types which transports manipulate at present: message/rfc822
(which also covers News) and message/http. I don't want to get into
message/http at the present time. And that leaves message/rfc822.

> dispatching to a handling module or application.

This is a reasonable view. But it doesn't mean that a message/mime object,
should one be defined, would benefit from this sort of structural handling. If
you want to secure such an object all you have to do is put the whole kit and
kaboodle inside of the security enclosure. I see no justifcation for exposing
part of it outside and having to recombine later. (Yes, I realize that people
have on occasion argued that there's value in confidentiality services that
expose, say, the content-type of of the secured material. However, I remain to
be convinced that this is a good idea, let alone that it should be accomplished
by something similar to this.)

> an old debate, but I would be interested in your view.

See above. Also note that if I'm wrong and there's value in using this
mechanism elsewhere, its definition can easily be borrowed in the definition
of another type or subtype at a later date.

				Ned

---

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 25 Sep 1998 15:10:52 -0500

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/24/98 
   at 02:18 AM, Ned Freed <[email-masked]> said:

>I don't know about message/http, but I suspect it would need its own
>rules. And it isn't clear this issue exists for HTTP anyhow, or that if
>it does it should be solved this way.

I am not aware of a message/http. It is my understanding that if you have
an e-mail message attachment (with headers) that you should use the
message/rfc822 and then text/http as a MIME part of the attached message
(with multipart/mixed or multipart/alternative in the message header).

In general message/rfc822 is to be used to signify that a MIME part is a
message with headers and that the user should reference the header of that
message for it's context.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: My best view from a Window was through OS/2.

---

From: Ned Freed <[email-masked]>
Date: Fri, 25 Sep 1998 14:22:57 -0700 (PDT)

> (with multipart/mixed or multipart/alternative in the message header).

The concept of "message" is a lot more general than e-mail these days. As
are the uses MIME is put to.

Message/http is the media type for an HTTP message. See RFC2068 for details.

> message for it's context.

An email message, yes. A message in a more general sense, no.

				Ned