Gnus development mailing list
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bmork@dod.no>
Subject: Re: content-transfer-encoding=8bit
Date: Mon, 14 Dec 1998 22:42:01 GMT	[thread overview]
Message-ID: <871zm2uz0m.fsf@duckman.mork.no> (raw)
In-Reply-To: <m3emq2liho.fsf@vvv.vsu.ru>


Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> Hi,
> 
> i wonder, shouldn't the "content-transfer-encoding=8bit" header be put
> into `main' headers of a multipart message, rather then into the
> message parts? imho, "content-transfer-encoding=8bit" only has `real'
> value when used in the main message headers, and is useless in the
> headers of a MIME part.

Nope. Different parts can have different encoding. From RFC2045:

3.  MIME Header Fields

   MIME defines a number of new RFC 822 header fields that are used to
   describe the content of a MIME entity.  These header fields occur in
   at least two contexts:

    (1)   As part of a regular RFC 822 message header.

    (2)   In a MIME body part header within a multipart
          construct.

   The formal definition of these header fields is as follows:

     entity-headers := [ content CRLF ]
                       [ encoding CRLF ]
                       [ id CRLF ]
                       [ description CRLF ]
                       *( MIME-extension-field CRLF )

     MIME-message-headers := entity-headers
                             fields
                             version CRLF
                             ; The ordering of the header
                             ; fields implied by this BNF
                             ; definition should be ignored.

     MIME-part-headers := entity-headers
                          [ fields ]
                          ; Any field not beginning with
                          ; "content-" can have no defined
                          ; meaning and may be ignored.
                          ; The ordering of the header
                          ; fields implied by this BNF
                          ; definition should be ignored.


> i.e., gnus should not put "content-transfer-encoding=8bit" into
> headers of MIME parts, but should put "content-transfer-encoding=8bit"
> into main headers iff a part exists which requires that c-t-t should
> be 8bit.

Only text types can be 8bit "encoded" because of the line length
restriction (998 octets), NUL restriction, and CRLF restriction (must 
be paired).

It's often necessary to mix 8bit and base64 if you have a name like 
mine and want to send binaries :-)


Bjørn
.



      reply	other threads:[~1998-12-14 22:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-14 17:51 content-transfer-encoding=8bit Vladimir Volovich
1998-12-14 22:42 ` Bjørn Mork [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871zm2uz0m.fsf@duckman.mork.no \
    --to=bmork@dod.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).