Charles Lindsey wrote:
There is a proposal afoot, known as "yEnc", for encoding binary Netnews
articles so that they will pass through 8bit transport systems, such as
NNTP. See <http://www.yenc.org>. The perceived benefit is that it reduces
the size of an article by around 30%, as compared with Base64 or uuencode,
and that is a useful benefit not only for transport, but also for storage
space on newsservers.
[...]
Charles has left out a number of important relevant issues
which have been discussed on the usefor mailing list.
First, the encoding method is not at issue. The issue isn't
yEnc vs. base64, or message size, transmission bandwidth, or
storage space.
The difference of opinion boils down to the means of wrapping
and tagging the encoded data.
One plan for the relevant headers runs roughly:
MIME-Version: 1.0
Content-Type: application/x-yyencoded
Content-Disposition: attachment; filename="foo.yenc"
Content-Features: ( Type="video/mpeg" )
Content-Transfer-Encoding: 8bit
where Content-Type parameters and/or additional
Content-Disposition parameters might be used to
supplement the Content-Features header for the benefit
of user agents that do not yet handle Content-Features.
Call this (or any of the equivalent variations on the theme)
plan A.
This is flatly prohibited by RFC 2048 section 2.2.1.
The other proposal (Charles') runs roughly:
MIME-Version: 1.0
Content-Type: video/mpeg
Content-Transfer-Encoding: yenc
Content-Disposition: attachment
where there also might be additional parameters and/or a
Content-Features header. Call this plan B.
Plan A requires no changes to existing RFCs and does not
mandate changes to existing transfer agents.
On the contrary, it is a gross violation of existing RFCs. See above.
Optionally,
the media type could be officially registered rather than
using an experimental subtype, but that does not affect
the gist of the plan. Note that the encoding information
relative to the original file which was encoded via yEnc is
carried implicitly in the Content-Type header, while the
Content-Transfer-Encoding header explicitly specifies the
domain of the body content as 8bit. Content-Features and/or
parameters used with Content-Type and/or Content-Disposition
convey information to regenerate the original (decoded)
file ancillary information (type and name). Obviously,
applications which wish to be able to handle this form of
encoding need to be able to recognize the media type and
features and/or parameters, however (and this is an
important point) no transport agent need know about the
details.
Plan B would require an RFC to amend RFC 2045. That RFC would
need to specify "yenc" as a new token for use as a
Content-Transfer-Encoding value and would need to specify
the domain associated with that value as 8bit.
Wrong again. The MIME RFCs explicitly lay the groundwork for additional
encodings to be defined and registered. There is no need to amend anything.
That may
lead to interoperability problems:
1. RFC 2045 does not specify what domain should be used for
unrecognized Content-Transfer-Encoding values. The domain
is needed by transfer agents so that they can determine
whether or not the message can be transported via a
given transport mechanism, and if so, what options (e.g.
8BITMIME for ESMTP) might be required. This also applies
to news, since there is no widely available transport for
binary data. Currently, standard Content-Transfer-Encoding
values of "binary" and "8bit" specify the respective domains;
everything else (including the default when no
Content-Transfer-Encoding header is present) has a 7bit
domain. No doubt some transfer agents will assume a 7bit
domain given an unrecognized value, and interoperability
cannot be expected if 8bit (yEnc) data is sent over (an
assumed) 7bit transport mechanism.
2. As far as I know, there are no current implementations of
transport agents which recognize a Content-Transfer-Encoding
value of "yenc". Leaving aside the requirement for at
implementations for standardization, there is the formidable
task of updating ALL transport agents (including embedded
systems) to recognize a new value and its associated encoding
method and domain. That task would certainly take years. That
is why the RFC 2045 advice should not be brushed aside casually:
"Unlike media subtypes, a proliferation of Content-Transfer-Encoding
values is both undesirable and unnecessary."
and
"Unlike media types and subtypes, the creation of new Content-
Transfer-Encoding values is STRONGLY discouraged, as it seems likely
to hinder interoperability with little potential benefit"
The need to add support to transfer agents is certainly an issue. But
it exists in both cases; slipping something through isn't the same
as handling it properly.
Your plan A, however, requires agents be updated to understand that
content type information is now in a different place. So instead of
exploiting what amounts to a simple plugin interface in any reasonably
constructed agent, you are now talking about creating a entirely new
way of expressing type information. Not only that, but the old mechanism
has to be supported as well.
The result is a huge increase in complexity.
No necessity for a new Content-Transfer-Encoding value has been
established, as Plan A does everything that Plan B would do
without the need for a new value and without requiring wholesale
modification of transport agents. No benefit has been established,
as the encoding method and its compactness are not at issue.
Indeed, there are a number of disadvantages to Plan B, not
least of which is hindrance of interoperability.
Another disadvantage of Plan B is that it is inherently
inapplicable to composite media types (multipart and message)
as only "7bit", "8bit", and "binary" values may be used with
those. As plan A uses "8bit", it is more flexible than plan B
in that respect.
I dispute every point in your analysis.
Ned