Hmm. This one is much, much trickier. Although one can argue that the rules
for
message/partial are too email-centric right now, that doesn't necessarily mean
changing them in another domain is a good idea. Defining another type for this
purpose might be feasible as an alternative, but that's not necessarily good
either since it would fail to leverage existing support for message/partial.
(Assuming there's a significant amount of it.)
IMHO, message/partial shouldn't be used for fragmented messages that use 8bit
encodings, a new content-type should be defined for this purpose. but we
shouldn't feel compelled to adhere to the "no nested encodings" rule for this
new type, because the normal implementation of this type would be to decode
the c-t-e for the fragment, store the decoded fragment in a file, and when
all of the fragments are present, concatenate them into a message.
that, and the state of programing has changed a bit since the early 1990s -
threads make it easy to handle nested encodings even without the intermediate
step of copying to a file, and thread support is widely available these days.
so while I don't think we should retroactively allow nested encodings with
existing content-types, I don't think there should be a problem with allowing
them in a new content-type for fragmented messages.
Keith