RE2: Re: Why have the prior 2 "gcc Digest" emails *not* been digests?(fwd)

RE2: Re: Why have the prior 2 "gcc Digest" emails *not* been digests?(fwd)

[Gerald Pfeifer]

A few days ago I forwarded another message by David, which Jason and/or
Jeff were so kind to have a look at; perhaps the following provides the
crucial hint?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

---------- Forwarded message ----------
From: David Presberg <David.Presberg@conexant.com>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: David.Presberg@conexant.com, gcc-help@gcc.gnu.org
Date: Tue, 30 May 2000 11:59:58 -0400 (EDT)
Subject: RE2: Re: Why have the prior 2 "gcc Digest" emails *not* been
    digests?

Gerald --

Hmmm.  Note the following (?) randomness:

 D   gcc-digest-help@gcc.gnu.o   24May 08:29    941/31837
     "gcc Digest 24 May 2000 08:29:36 -0000 Issue 674"

 T   gcc-owner@gcc.gnu.org       25May 12:03   1469/52200
     "gcc Digest 25 May 2000 12:03:47 -0000 Issue 675"

 T   gcc-owner@gcc.gnu.org       26May 10:52   1269/45209
     "gcc Digest 26 May 2000 10:52:18 -0000 Issue 676"

 T   gcc-owner@gcc.gnu.org       27May 18:12   1193/40599
     "gcc Digest 27 May 2000 18:12:10 -0000 Issue 677"

 D   gcc-digest-help@gcc.gnu.o   28May 14:16   1126/35666
     "gcc Digest 28 May 2000 14:16:49 -0000 Issue 678"

 D   gcc-digest-help@gcc.gnu.o   29May 15:20   1056/36941
     "gcc Digest 29 May 2000 15:20:23 -0000 Issue 679"

 T*  gcc-owner@gcc.gnu.org       30May 15:30   1450/55179
     "gcc Digest 30 May 2000 15:30:32 -0000 Issue 680"

where:

"D" == (proper digest).  "T" == "Content-Type: text/plain; charset=us-ascii".

but:

"T*" == "Content-Type: multipart/mixed; 
	Boundary="0__=882568EF005567FF8f9e8a93df938690918c882568EF005567FF".

which latter is still not a proper digest-form email.

And only the proper digests have the extra header-lines that explain
about getting off the list, etc.

[...]

RE2: Re: Why have the prior 2 "gcc Digest" emails *not* been digests?(fwd)

[Gerald Pfeifer]

A few days ago I forwarded another message by David, which Jason and/or
Jeff were so kind to have a look at; perhaps the following provides the
crucial hint?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

---------- Forwarded message ----------
From: David Presberg <David.Presberg@conexant.com>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: David.Presberg@conexant.com, gcc-help@gcc.gnu.org
Date: Tue, 30 May 2000 11:59:58 -0400 (EDT)
Subject: RE2: Re: Why have the prior 2 "gcc Digest" emails *not* been
    digests?

Gerald --

Hmmm.  Note the following (?) randomness:

 D   gcc-digest-help@gcc.gnu.o   24May 08:29    941/31837
     "gcc Digest 24 May 2000 08:29:36 -0000 Issue 674"

 T   gcc-owner@gcc.gnu.org       25May 12:03   1469/52200
     "gcc Digest 25 May 2000 12:03:47 -0000 Issue 675"

 T   gcc-owner@gcc.gnu.org       26May 10:52   1269/45209
     "gcc Digest 26 May 2000 10:52:18 -0000 Issue 676"

 T   gcc-owner@gcc.gnu.org       27May 18:12   1193/40599
     "gcc Digest 27 May 2000 18:12:10 -0000 Issue 677"

 D   gcc-digest-help@gcc.gnu.o   28May 14:16   1126/35666
     "gcc Digest 28 May 2000 14:16:49 -0000 Issue 678"

 D   gcc-digest-help@gcc.gnu.o   29May 15:20   1056/36941
     "gcc Digest 29 May 2000 15:20:23 -0000 Issue 679"

 T*  gcc-owner@gcc.gnu.org       30May 15:30   1450/55179
     "gcc Digest 30 May 2000 15:30:32 -0000 Issue 680"

where:

"D" == (proper digest).  "T" == "Content-Type: text/plain; charset=us-ascii".

but:

"T*" == "Content-Type: multipart/mixed; 
	Boundary="0__=882568EF005567FF8f9e8a93df938690918c882568EF005567FF".

which latter is still not a proper digest-form email.

And only the proper digests have the extra header-lines that explain
about getting off the list, etc.

[...]

Re: RE2: Re: Why have the prior 2 "gcc Digest" emails *not* been digests? (fwd)

[Jason Molenda]

On Tue, May 30, 2000 at 10:03:38PM +0200, Gerald Pfeifer wrote:
> A few days ago I forwarded another message by David, which Jason and/or
> Jeff were so kind to have a look at; perhaps the following provides the
> crucial hint?
> 

I'll be honest - I don't have a clue.  I know next to nothing about
how ezmlm constructs its digests.  Maybe it has something to do
with the messages in the archive? I don't know.

ezmlm-get(1) says the following.  No -f option is being specified for
the gcc list, so the default (m) should be the one used.  From
/qmail/lists-gcc/gcc/editor:

|/qmail/ezmlm/ezmlm-get '/qmail/lists-gcc/gcc' || exit 0


From the man page:

       -f is an optional format specifier for -get,  -thread,  and
       -dig  requests.  It  is  allowed,  but  ignored for -index
       requests. Currently, the following are allowed:


       r      rfc1153. This is a ``plain''  non-MIME  format  for
              dumb clients.

       m      (Default.)  MIME  multipart/digest with a subset of
              ordered headers sorted.  Currently,  the  following
              headers  are  included  in the order listed: Date:,
              To:, From:, Reply-To:, Cc:, MIME-Version:, Content-
              Type:,  Message-ID:,  and  Keywords:.   This can be
              customized with the optional  file  dir/digheaders,
              which  should contain the desired headers up to but
              not including the colon.

              The format is no longer compliant with rfc1153,  as
              the  rfc1153  format  is incompatible with rfc2046,
              which which the format is (should be) compatible.

       x      MIXED: This is the same as the default MIME format,
              except  that  the  Content-Type is multipart/mixed.
              This helps circumnavigate  a  Pine  bug:  when  the
              digest   is   content-transfer-encoded,  Pine  will
              refuse to display the initial text/plain part of  a
              multipart/digest message, but display the same part
              of a multipart/mixed message. Some  MUAs  for  some
              strange  reason  treat  the  two  multipart formats
              differently. In some cases, ``x'' works better than
              ``m''.

       v      VIRGIN: This is MIME multipart/digest with messages
              returned without any header filtering.

       n      NATIVE: This is VIRGIN  format  without  threading,
              i.e.  messages are presented in numerical order and
              the message index is suppressed.

Re: RE2: Re: Why have the prior 2 "gcc Digest" emails *not* been digests? (fwd)

[Jason Molenda]

On Tue, May 30, 2000 at 10:03:38PM +0200, Gerald Pfeifer wrote:
> A few days ago I forwarded another message by David, which Jason and/or
> Jeff were so kind to have a look at; perhaps the following provides the
> crucial hint?
> 

I'll be honest - I don't have a clue.  I know next to nothing about
how ezmlm constructs its digests.  Maybe it has something to do
with the messages in the archive? I don't know.

ezmlm-get(1) says the following.  No -f option is being specified for
the gcc list, so the default (m) should be the one used.  From
/qmail/lists-gcc/gcc/editor:

|/qmail/ezmlm/ezmlm-get '/qmail/lists-gcc/gcc' || exit 0


From the man page:

       -f is an optional format specifier for -get,  -thread,  and
       -dig  requests.  It  is  allowed,  but  ignored for -index
       requests. Currently, the following are allowed:


       r      rfc1153. This is a ``plain''  non-MIME  format  for
              dumb clients.

       m      (Default.)  MIME  multipart/digest with a subset of
              ordered headers sorted.  Currently,  the  following
              headers  are  included  in the order listed: Date:,
              To:, From:, Reply-To:, Cc:, MIME-Version:, Content-
              Type:,  Message-ID:,  and  Keywords:.   This can be
              customized with the optional  file  dir/digheaders,
              which  should contain the desired headers up to but
              not including the colon.

              The format is no longer compliant with rfc1153,  as
              the  rfc1153  format  is incompatible with rfc2046,
              which which the format is (should be) compatible.

       x      MIXED: This is the same as the default MIME format,
              except  that  the  Content-Type is multipart/mixed.
              This helps circumnavigate  a  Pine  bug:  when  the
              digest   is   content-transfer-encoded,  Pine  will
              refuse to display the initial text/plain part of  a
              multipart/digest message, but display the same part
              of a multipart/mixed message. Some  MUAs  for  some
              strange  reason  treat  the  two  multipart formats
              differently. In some cases, ``x'' works better than
              ``m''.

       v      VIRGIN: This is MIME multipart/digest with messages
              returned without any header filtering.

       n      NATIVE: This is VIRGIN  format  without  threading,
              i.e.  messages are presented in numerical order and
              the message index is suppressed.