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.
Good point, and one that finesses the problem of how to downgrade a fragment
quite nicely. I like it.
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.
Interesting. I use threads in almost all the programming I do, and it never
occurred to me to use them for this. (It is obvious how it would be done,
of course.) I guess this would be OK for simple utilities or even for most
clients, but for any sort of server, forget it. Thread overhead is just too
great to waste them on this sort of thing.
OTOH, I coded support for nested encodings sitting in sessions at the Atlanta
IETF just to see how hard it would be. And it wasn't especially difficult.
Nevertheless, I think your first argument regarding the effective separatness
of message reassembly is much more compelling. I wish it had been made
at the time message/partial was specified.
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.
Yup. And given that it is the obvious way to move forward.
Ned