Subject: Charset in newgroup sample

From: Julien ÉLIE <[email-masked]>
Date: Sun, 1 Mar 2009 23:54:08 +0100

Hi,

In the sample of newgroup control message:

      Control: newgroup example.admin.info moderated
      MIME-Version: 1.0
      Content-Type: multipart/mixed; boundary="nxtprt"
      Content-Transfer-Encoding: 8bit

      This is a MIME control message.
      --nxtprt
      Content-Type: application/news-groupinfo

      For your newsgroups file:
      example.admin.info      About the example.* groups (Moderated)

      --nxtprt
      Content-Type: text/plain

      A moderated newsgroup for announcements about new newsgroups in
      the example.* hierarchy.

      --nxtprt--

wouldn't it be better to put the charsets in order to highlight the
fact they are useful (though it is said the default is US-ASCII)?
I fear people might still forget it...

      Content-Type: multipart/mixed; boundary="nxtprt"; charset=us-ascii
      Content-Type: application/news-groupinfo; charset=us-ascii
      Content-Type: text/plain; charset=us-ascii

or another one if you want (iso-8858-1 and utf-8 are also fine for instance
but RFC 2046 states it SHOULD be the lowest common denominator us-ascii,
enough for that sample).

Why mention the charset?  RFC 2046 also states:

   In order to eliminate such ambiguity and variations in the
   future, it is strongly recommended that new user agents explicitly
   specify a character set as a media type parameter in the Content-Type
   header field.

In our case, the most important is the second one.  Incidentally,
I wonder what happens when the first one is defined to utf-8 and
the second one is undefined.  Is it utf-8 (out of transitivity)
or us-ascii?

-- 
Julien ÉLIE

« Plus un ordinateur possède de RAM, plus vite il peut générer un message d'erreur. »

---

From: Russ Allbery <[email-masked]>
Date: Sun, 01 Mar 2009 18:27:20 -0800

> fact they are useful (though it is said the default is US-ASCII)?

Yeah, probably a good idea.  I'll make that change.

>      Content-Type: multipart/mixed; boundary="nxtprt"; charset=us-ascii

As near as I can tell from RFC 2046, charset is not a valid parameter for
multipart/* content types.  It's only supposed to go on the final
constituent parts.  Among other things, this avoids...

> the second one is undefined.  Is it utf-8 (out of transitivity)

...that problem.  :)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 2 Mar 2009 08:19:04 +0100

Hi Russ,

> Yeah, probably a good idea.  I'll make that change.

Thanks for your commit.

>> the second one is undefined.  Is it utf-8 (out of transitivity)

All right!  Thanks!

-- 
Julien ÉLIE

« There's a way of transferring funds that is even faster
  than electronic banking.  It's called marriage. » (Sam Kinison)

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 2 Mar 2009 20:00:13 +0100

Hi,

> constituent parts.  Among other things, this avoids...

I also see that RFC 2046 only accepts US-ASCII for the preamble of
a MIME message (I thought a charset for multipart/mixed would be useful
for it, but it is in fact useless):

    preamble := discard-text
    discard-text := *(*text CRLF) *text
    text = <any CHAR, including bare CR & bare LF, but NOT including CRLF>
    CHAR = <any ASCII character> ; (  0-177,  0.-127.)

It is therefore impossible to write "This is a MIME control message."
in Chinese.

The parts are defined as:

    body-part := MIME-part-headers [CRLF *OCTET]
    OCTET := <any 0-255 octet value>

That's fine.

-- 
Julien ÉLIE

« -- Il l'aura voulu.
  -- Tu crois vraiment ? » (Astérix)