ietf-822
[Top] [All Lists]

Re: Content-Transfer-Encoding and yEnc

2002-04-03 04:12:29

In <3CAA68DF(_dot_)588D3293(_at_)erols(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> writes:


Charles has left out a number of important relevant issues
which have been discussed on the usefor mailing list.

Yes, it has been discussed on the Usefor list. No, there is NO intention
to include this in the current Usefor document. 

First, the encoding method is not at issue. The issue isn't
yEnc vs. base64, or message size, transmission bandwidth, or
storage space.

On the contrary, that is EXACTLY the point at issue. 'yEnc' is just
another encoding, which might or might not stand alongside base64 and Q-P.


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

Which is a gross misuse of the Content-Type header. If the object really
is a video/mpeg, then normal MIME usage requires that the Content-Type
say so.

Yes, you might shoe horn this through existing channels by this trick, but
it leave no convenient possibility to convert it to CTE: base64 on the fly
so that it may continue its travels as a normal MIME object.


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.

And observe that Plan B follows both the spirit and the letter of the
overall MIME scheme.


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

Yes, there is a small glitch in RFC 2045, insofar as it does not specify a
default domain to be assumed when the CTE is unregognized. A 'domain=8bit'
parameter for CTE might have been a nice idea.

This also applies
  to news, since there is no widely available transport for
  binary data.

But this problem most emphatically DOES NOT apply to news, since all known
transports (notably NNTP) support at least 8bit and some (notably UUCP)
support binary. Either of these is adequate to transport yEnc. Since this
CTE is primarily intended for News, no problem arises until it comes to be
gatewayed into Email. That is a problem for the gateway to sort out, and
at least Plan B provides a possibility to turn it into something
immediately acceptable to the existing Email system. Not that I expect
such gatewaying to be commonly required.


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 regard that as a considerable AD-vantage of Plan B. Composite media
types SHOULD NOT be encoded as a whole. That is not current MIME practice,
and I don't want to make it so.

======== new but related topic ===========

The successor to RFC 2045 should probably specify a default
domain where an unrecognized Content-Transfer-Encoding value
is encountered. To ensure interoperability, the worst case
should probably be used, viz. "binary".

The obvious default is '8bit'. 

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