ietf-822
[Top] [All Lists]

Re: Content-Transfer-Encoding and yEnc

2002-04-03 03:44:34


On Tue, 2 Apr 2002, ned+ietf-822(_at_)mrochek(_dot_)com wrote:

    So the question I am asking of this list is whether a proposal for a
    CTE for encoding binaries within an 8bit domain would stand a
    reasonable chance of being accepted by the IESG (assuming for the
    moment that it was technically sound and properly specified)?

The key, of course, is restricting this to an 8bit domain like netnews. Do
that and the problem is vastly simplified. And the answer is that a
reasonable proposal would have a good chance of being accepted.

The definition of a new CTE for netnews is only the first part of the
problem. For yEnc to be generally usable, there will need to be a
mechanism for splitting messages and probably checksumming the split
parts.

I see the connection as well as the rationale for a move to using MIME
mechanisms for postings split into multiple messages, but to some extent this
issue is orthogonal.

The latter could be fairly simply accomplished by extending Content-MD5
in some way so as to apply to an entire message/partial part rather than
just leaf parts.

A message/partial part in isolation is technically a leaf, so this is really
not a problem. However, you could also put the checksums on the parts inside
the message/partial. Or both.

However, the use of message/partial for splitting yEnc messages in the
first place hits RFC2046 Section 5.2.2.

    "If [non-7bit] messages were encountered at a gateway into a 7bit
    transport environment, there would be no way to properly encode them
    for the 7bit world, aside from waiting for all of the fragments,
    reassembling the inner message, and then encoding the reassembled
    data in base64 or quoted-printable.  Since it is possible that
    different fragments might go through different gateways, even this
    is not an acceptable solution.  For this reason, it is specified
    that entities of type "message/partial" must always have a
    content-transfer-encoding of 7bit (the default).  In particular,
    even in environments that support binary or 8bit transport, the use
    of a content- transfer-encoding of "8bit" or "binary" is explicitly
    prohibited for MIME entities of type "message/partial". This in turn
    implies that the inner message must not use "8bit" or "binary"
    encoding."

The answer to Charles'  question "[would] a proposal for a CTE for
encoding binaries within an 8bit domain stand a reasonable chance of
being accepted by the IESG" has been quite positive. What chance is
there of a relaxation of the above message/partial restriction being
acceptable for use only within netnews, again assuming a technically
sound and properly specified proposal?

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.)

And it isn't possible to argue that netnews isn't gatewayed to email; we all
know it is done all the time. I suppose we could simply prohibit gatewaying of
objects of this sort unless you're willing to reassemble them as part of the
gateway process.

This one definitely needs further discussion and thought. At a minimum it is
more than I can wrap my head around at this late hour ;-)

                                Ned