In <820uL0Eutsq8IAVV(_at_)pillar(_dot_)turnpike(_dot_)com> Ian Bell
<ianbell(_at_)turnpike(_dot_)com> writes:
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.
yEnc includes a CRC check for each part (that is good enough for checking
integrity, though MD5, which is more costly, may be needed for some other
purposes).
I believe yEnc also makes provision for stitching parts together. That
might not be such a good thing (is an encoding really the right place to
do that?) but I see that other, more appropriate, mechanisms are under
discussion in this thread.
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, ... For this reason, it is specified
that entities of type "message/partial" must always have a
content-transfer-encoding of 7bit (the default)...
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?
Yes, in an earlier draft of Usefor, we did relax this restriction for use
withint Netnews. But then we had an attack of "MIME compliance fever" and
took it out again :-( . Of course, if Ned will let us put it back again
........
But seriously, message/partial is flawed in many ways, as I think others
on this thread have agreed. The Usefor draft is pretty lukewarm about it,
though it does suggest using the References-header so that reading agents
that do threading can at least offer the parts in the right order (so you
will see at once whether any are missing).
But, ideally, we need a mechanism with the following properties:
1. It should be possible to decode any part into its intended form without
reference to the other parts. This means each part must contain the
Content-Type, charset etc. So even if the part turns out to be a message
written in Chinese characters, you can at least read that bit and obtain
some clue as to whether you are interested enough to go looking for the
other bits. In the case of a pure binary, it may or may not be useful to
see just a bit in the middle, depending on the format (but even a clip out
of the middle of a long video could be useful if the format allows it,
which I imagine mpeg does).
2. It should be possible, given a few of the parts, to determine what
parts are missing, and to identify those parts as part of the whole if and
when they eventually turn up.
3. The mechanism should facilitate automatic reassembly of the parts.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5