... but I think that my basic idea was a good one, and that when we go
to full standard the spec should add "Subject" to the list of headers
taken from the inner part. Any other opinions? -- Nathaniel
It's a good idea, but the subject of the inner message ought to be
available so that the human recipient can decide whether to read
it now or later or discard it or whatever. And yet it seems that we
should not require that the subjects of the container messages
be identical to the subject of the contained message. So I suggest
defining a "subject" parameter for content-type message/partial, which
must reflect the subject of the contained message.
I don't like this approach very much. I think the subject of the container
messages should be closely related to the subject of the contained messages.
(Perhaps saying that material can be added but not removed would do the trick.)
If you want to include additional unrelated commentary use a different header.
The Subject: header is pretty close to being part of the message contents
rather than just another header.
I think the semantic mismatch between an entire header and a parameter will be
a problem. It is one of those things that will work fine on paper but will
cause problems with actual implementations.
I also think Nathaniel's approach is the correct one -- my view is that the
specification as it stands effectively limits the ability to annotate the
subject with fragmentation information. This should be allowed.
For the record, my implementation follows the RFC explicitly. It doesn't amend
the subject header on the fragments, so it works properly when reassembling
messages it disassembled. But, as Nathaniel notes, I get a (1 of n) on the end
of the subject line when processing messages created by metamail.
Ned