Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
IMO, the ultimate aim (even if this is not practical) is to deliver
to each recipient the same version of the Fax as they would have
received IF they were the only addressee
I think this is a reasonable and practical goal. I don't think that
recipient A should experience a difference in message quality
(or worse, fail to receive the message at all) based on whether or
not you cc'ed recipient B.
Negotiation can mean that A and B receive different messages, both stating
(in to/cc) that the other received the one they didn't. Sounds very fishy
to my ears.
This is nothing new; situations arise routinely where the header recipient
lists don't tell the full story about who did or did not get a message or a
particular version of a message.
The thing sounds as if it's 100% incompatible with S/MIME and other
signature mechansisms. Shouldn't that be mentioned in the draft's security
considerations section?
On the contrary, far from being incompatible, this facility may actually
facilitate the ability to use signatures in situations where it presently isn't
possible to use them. Specifically, if a client is aware of a recipient's needs
it can tailor a message for that recipient and then sign it after the
tailoring is complete. Without this knowledge what tends to happen is that the
tailoring is done after the signature is applied, which of course renders the
signature invalid.
Now you may argue that such transformations are a bad idea. And on a
theoretical level I'd agree with you. But on a practical level the need for
them is there, and I'd much rather see then done by the client than by some
intermediary.
The fact that multipart/signed is designed so that signatures can be attached
to content on the fly is also useful in this context.
As for mentioning any of this in the security considerations section, I
have no problem with that.
Ned