Subject: Re: Regarding 8bitMIME support ...
From: Keith Moore <[email-masked]>
To: "dhananjay" <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Thu, 15 May 2003 23:48:46 -0400
List-Id: <ietf-822.imc.org>

> I would like to know flow for following 2 cases :
> 1. 8bit MTA sending mail to 7bit MTA with Subject line in header having 8bit
> characters.
>     RFC2822 says "A field body may be composed of any US-ASCII characters,
> except for CR and LF." So, such situation is quite possible.

nope.  US-ASCII characters are all in the range 0-127.  
unencoded non-ASCII characters are illegal in message headers.

now they do sometimes appear, and when they do appear, you can use RFC 2047
encoding.  but most of the time you don't have any reliable idea about what
the character set should be.

> 2. 8bit MTA sending mail to 7bit MTA with Message body text having 8bit
> characters.
>      In this case, 8bit MTA will have to encode message body text into
> base64/QP and send it as attachment to original header of message.

no, it should not be an attachment.  merely changing the body from 8bit
to quoted-printable or base64 does not create an attachment.

From: "dhananjay" <[email-masked]>
To: "IETF RFC-822 list" <[email-masked]>
Subject: Re: Regarding 8bitMIME support ...
Date: Thu, 15 May 2003 18:38:33 -0700
Sender: [email-masked]

> 1. 8bit MTA sending mail to 7bit MTA with Subject line in header
> having 8bit characters.
> That is a non-conformant message header.  I think the safest thing to do
> is leave it unchanged.  If the 7bit MTA corrupts it or bounces it, the
> fault lies with the sender for sending an invalid header.  If you try to
> transform the header, you are assuming that you can interpret the 80..FF
> bytes, but the standards don't give you any clue how to interpret those
> bytes in headers, because they're forbidden.

Great. Relieved for now.

> > RFC2822 says "A field body may be composed of any US-ASCII characters,
> > except for CR and LF." So, such situation is quite possible.
>
> US-ASCII is only 0..7F.  A message header obeying that requirement
> cannot contain bytes with the highest bit set.

Yes. But RFC uses word "may" and not "MUST", thats why I thought such
situation where user adding 8 bit chars in field body of header is possible.

> > 2. 8bit MTA sending mail to 7bit MTA with Message body text having
> > 8bit characters.  In this case, 8bit MTA will have to encode message
> > body text into base64/QP and send it as attachment to original header
> > of message.
>
> I see no need for an attachment.  After encoding the body using
> quoted-printable or base64, simply alter the Content-Transfer-Encoding
> header field (which came in saying 8bit) to say quoted-printable or
> base64.

Oh yes. This is the way. I hope picture is getting clear to me (though
slowly) with all the valuable comments that I received from so many
community members. Thanks to all of you.

Regards,
Dhananjay.

Date: Fri, 16 May 2003 01:10:10 +0000
From: "Adam M. Costello" <[email-masked]>
To: IETF RFC-822 list <[email-masked]>
Subject: Re: Regarding 8bitMIME support ...
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

dhananjay <[email-masked]> wrote:

> 1. 8bit MTA sending mail to 7bit MTA with Subject line in header
> having 8bit characters.

That is a non-conformant message header.  I think the safest thing to do
is leave it unchanged.  If the 7bit MTA corrupts it or bounces it, the
fault lies with the sender for sending an invalid header.  If you try to
transform the header, you are assuming that you can interpret the 80..FF
bytes, but the standards don't give you any clue how to interpret those
bytes in headers, because they're forbidden.

> RFC2822 says "A field body may be composed of any US-ASCII characters,
> except for CR and LF." So, such situation is quite possible.

US-ASCII is only 0..7F.  A message header obeying that requirement
cannot contain bytes with the highest bit set.

> 2. 8bit MTA sending mail to 7bit MTA with Message body text having
> 8bit characters.  In this case, 8bit MTA will have to encode message
> body text into base64/QP and send it as attachment to original header
> of message.

I see no need for an attachment.  After encoding the body using
quoted-printable or base64, simply alter the Content-Transfer-Encoding
header field (which came in saying 8bit) to say quoted-printable or
base64.

AMC

From: "dhananjay" <[email-masked]>
To: "IETF RFC-822 list" <[email-masked]>
Subject: Re: Regarding 8bitMIME support ...
Date: Thu, 15 May 2003 17:35:58 -0700
Sender: [email-masked]

>
> dhananjay <[email-masked]> wrote:
>
> > Now, consider a scenario where a mail client (supporting 8bit) sends
> > an email with a binary-converted-to-8bit attachment
> >
> > Also, could you please point out some mail clients dealing 8bit.
>
> Do you understand that currently there is no binary-to-8bit
> conversion registered in the transfer-encoding registry
> (http://www.iana.org/assignments/transfer-encodings)?  There is a draft
> for deflate-8bit (draft-freed-mime-newenc-00), but I would be surprised
> if any mail clients implemented it already, since it's likely to change.
>
> Currently, the only standard way to get an 8bit message body is for the
> body to originate as 8bit (for example, plain text in almost any charset
> except ASCII); there is no standard conversion from binary to 8bit.
I would like to know flow for following 2 cases :
1. 8bit MTA sending mail to 7bit MTA with Subject line in header having 8bit
characters.
    RFC2822 says "A field body may be composed of any US-ASCII characters,
except for CR and LF." So, such situation is quite possible.
    In this case dealing with 7bit MTA becomes very tough, as sending 8bit
MTA will have to parse each possible header field body, and do necessary
encoding to QP, and poor 8bit MTA has no way out.

2. 8bit MTA sending mail to 7bit MTA with Message body text having 8bit
characters.
     In this case, 8bit MTA will have to encode message body text into
base64/QP and send it as attachment to original header of message. So, user
sees message body text as attachment.
     is such change in mail structure allowed ?

Regards,
Dhananjay.

Date: Thu, 15 May 2003 09:55:19 -0500
To: "dhananjay" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Regarding 8bitMIME support ...
Cc: "Keith Moore" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 5/14/03 at 11:25 PM -0700, dhananjay wrote:

>Also, could you please point out some mail clients dealing 8bit. I
>could not find 8bit CTE configuration setting in outlook. It has just base64
>and QP options.

I know Macintosh Eudora has a setting to send 8BITMIME (in the 
optional "esoteric" settings panel for ports and protocols). I'm 
pretty Windows Eudora has the same thing somewhere. This only works 
for text, not for other attachments.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Thu, 15 May 2003 08:42:20 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding 8bitMIME support ...
Sender: [email-masked]

On Thu, 15 May 2003 09:57:07 +0200
Arnt Gulbrandsen <[email-masked]> wrote:

> Keith Moore writes:
> > p.s. these days almost all SMTP servers can deal with 8bit message 
> > bodies (NOT headers) even if they don't advertise the 8bitmime 
> > extension.  so there are at least a few  implementations that just 
> > send 8bitmime messages without converting, and they mostly seem to 
> > get away with it.  it's certainly a lot simpler, and these days, it 
> > may even be less error-prone.  it's easy to write an 8-bit to 7-bit 
> > converter that corrupts messages.
> 
> Spammers just-send-8. 

last I knew, so did qmail.  so maybe the ability to filter just-send-8 is a
good thing :)

Keith

Date: Thu, 15 May 2003 08:41:10 -0400
From: Keith Moore <[email-masked]>
To: "dhananjay" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding 8bitMIME support ...
Sender: [email-masked]

>       Now, consider a scenario where a mail client (supporting 8bit) sends
> an email with a binary-converted-to-8bit attachment to my MTA, A. My MTA
> connects to non-8bit remote MTA, B. Now, my MTA converts attachment from
> 8bit to base64, and sends it.
>       Given this, when any mail client connects to MTA B, it downloads the
> attachment and applies base64 conversion. Now, will that client be able to
> retrieve original binary attachment, OR it will get 8bit attachment ?

nothing should ever be converting from binary to 8bit.  the only reason
to convert from binary to anything is when sending to a 7-bit-only MTA;
and then you have to use base64 or q-p.  one reason you don't convert to
8bit (or for that matter 7bit) is that neither 8bit nor 7bit can represent
all octet values.  8bit and 7bit were not really intended as encodings,
they were intended as a way to mark unencoded text.  these days everyone
supports MIME so there's not as much need to transmit unencoded text.

even assuming there were a binary-to-8bit converter, it would only make
sense for text objects that used short lines and CRLF line endings.

>        Also, could you please point out some mail clients dealing 8bit. I
> could not find 8bit CTE configuration setting in outlook. It has just base64
> and QP options.

I don't know of any.  I don't think 8bit is used very often.

Keith

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Regarding 8bitMIME support ...
Cc: [email-masked], [email-masked]
Date: Thu, 15 May 2003 09:57:07 +0200
Sender: [email-masked]

Keith Moore writes:
> p.s. these days almost all SMTP servers can deal with 8bit message 
> bodies (NOT headers) even if they don't advertise the 8bitmime 
> extension.  so there are at least a few  implementations that just 
> send 8bitmime messages without converting, and they mostly seem to 
> get away with it.  it's certainly a lot simpler, and these days, it 
> may even be less error-prone.  it's easy to write an 8-bit to 7-bit 
> converter that corrupts messages.

Spammers just-send-8. In this day and age, it probably is a bad idea to 
do what spammers do: So many people are fed up and will filter on 
anything that looks good, just to get rid of some spam.

I noticed that stock postfix can filter on just-send-8 now.

--Arnt

Date: Thu, 15 May 2003 07:32:48 +0000
From: "Adam M. Costello" <[email-masked]>
To: [email-masked]
Subject: Re: Regarding 8bitMIME support ...
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

dhananjay <[email-masked]> wrote:

> Now, consider a scenario where a mail client (supporting 8bit) sends
> an email with a binary-converted-to-8bit attachment
>
> Also, could you please point out some mail clients dealing 8bit.

Do you understand that currently there is no binary-to-8bit
conversion registered in the transfer-encoding registry
(http://www.iana.org/assignments/transfer-encodings)?  There is a draft
for deflate-8bit (draft-freed-mime-newenc-00), but I would be surprised
if any mail clients implemented it already, since it's likely to change.

Currently, the only standard way to get an 8bit message body is for the
body to originate as 8bit (for example, plain text in almost any charset
except ASCII); there is no standard conversion from binary to 8bit.

AMC

From: "dhananjay" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Regarding 8bitMIME support ...
Date: Wed, 14 May 2003 23:25:38 -0700
Sender: [email-masked]

Hi Keith,
     Thanks a lot for reply.
     First of all, I can not get away with 7bit email servers by sending
8bit to them. I have to convert.

     So, I would need to convert each body part separately, based on its
CTE, and definitely I would need to choose between QP and base64 based on
the thumb rule as you specified.

      Now, consider a scenario where a mail client (supporting 8bit) sends
an email with a binary-converted-to-8bit attachment to my MTA, A. My MTA
connects to non-8bit remote MTA, B. Now, my MTA converts attachment from
8bit to base64, and sends it.
      Given this, when any mail client connects to MTA B, it downloads the
attachment and applies base64 conversion. Now, will that client be able to
retrieve original binary attachment, OR it will get 8bit attachment ?

       Also, could you please point out some mail clients dealing 8bit. I
could not find 8bit CTE configuration setting in outlook. It has just base64
and QP options.

       Any help is most appreciated.

Regards,
Dhananjay.

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "dhananjay" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 14, 2003 8:33 PM
Subject: Re: Regarding 8bitMIME support ...

>
> first, you cannot simply encode the entire message in quoted-printable or
> base64.  each component of a message/rfc822 or multipart/* body part must
be
> considered separately.
>
> you should not re-encode a body part which is already 7-bit compatible
> (i.e. you should not re-encode a 7bit, quoted-printable, or base64 body
part)
>
> a binary or 8bit body part should be re-encoded.  as a rule of thumb,
> if the content-type is text/* you can use quoted-printable; otherwise,
> use base64.
>
> Keith
>
> p.s. these days almost all SMTP servers can deal with 8bit message bodies
(NOT
> headers) even if they don't advertise the 8bitmime extension.  so there
are at
> least a few  implementations that just send 8bitmime messages without
> converting, and they mostly seem to get away with it.  it's certainly a
lot
> simpler, and these days, it may even be less error-prone.  it's easy to
write
> an 8-bit to 7-bit converter that corrupts messages.
>
>
> > Hi,
> >     I am working on enhancing MTA to support SMTP extensions (especially
8
> > bit MIME support). I am not clear about following issue :
> >
> >     If remote MTA does not support 8bit MIME, then the sender MTA should
> > convert message from 8 bit to 7 bit and send the message. Now, there can
be
> > 3 approaches (apart from perm error NDR generation) that I am aware of :
> >     1. The sender MTA should first convert whole message to original
> > encoding (octet stream), and then apply base 64 encoding on that to get
7
> > bit. But, this seems to be very length procedure and tedious processing.
> >
> >      2. The sender MTA should apply quoted-printable encoding (one can
use
> > even base64 encoding also .. as final aim is 7bit output ?) directly on
8
> > bit MIME message. But, then we lose track of original message format
> > (say,octet stream). And, mail clients trying to retrieve message from
this
> > remote MTA will not be able to get original message format (octet
stream).
> > They will be able to decode the message to 8bit MIME, but not from 8 bit
> > MIME to octet stream (original message format), as we have lost track of
> > octet stream -> 8bit MIME encoding.
> >
> >     3. The sender MTA should apply either quoted printable or base 64
> > encoding on whole message (except original headers), and send that as
> > attachment to original headers. But, this means, user will get original
> > message as a attachment.
> >
> >      Now, I am not able to make out whether my approaches are right and
> > which way to go ?
> >
> > Regards,
> > Dhananjay.
> >
>

Date: Wed, 14 May 2003 23:33:36 -0400
From: Keith Moore <[email-masked]>
To: "dhananjay" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding 8bitMIME support ...
Sender: [email-masked]

first, you cannot simply encode the entire message in quoted-printable or
base64.  each component of a message/rfc822 or multipart/* body part must be
considered separately.

you should not re-encode a body part which is already 7-bit compatible
(i.e. you should not re-encode a 7bit, quoted-printable, or base64 body part)

a binary or 8bit body part should be re-encoded.  as a rule of thumb,
if the content-type is text/* you can use quoted-printable; otherwise,
use base64. 

Keith

p.s. these days almost all SMTP servers can deal with 8bit message bodies (NOT
headers) even if they don't advertise the 8bitmime extension.  so there are at
least a few  implementations that just send 8bitmime messages without
converting, and they mostly seem to get away with it.  it's certainly a lot
simpler, and these days, it may even be less error-prone.  it's easy to write
an 8-bit to 7-bit converter that corrupts messages.

> Hi,
>     I am working on enhancing MTA to support SMTP extensions (especially 8
> bit MIME support). I am not clear about following issue :
> 
>     If remote MTA does not support 8bit MIME, then the sender MTA should
> convert message from 8 bit to 7 bit and send the message. Now, there can be
> 3 approaches (apart from perm error NDR generation) that I am aware of :
>     1. The sender MTA should first convert whole message to original
> encoding (octet stream), and then apply base 64 encoding on that to get 7
> bit. But, this seems to be very length procedure and tedious processing.
> 
>      2. The sender MTA should apply quoted-printable encoding (one can use
> even base64 encoding also .. as final aim is 7bit output ?) directly on 8
> bit MIME message. But, then we lose track of original message format
> (say,octet stream). And, mail clients trying to retrieve message from this
> remote MTA will not be able to get original message format (octet stream).
> They will be able to decode the message to 8bit MIME, but not from 8 bit
> MIME to octet stream (original message format), as we have lost track of
> octet stream -> 8bit MIME encoding.
> 
>     3. The sender MTA should apply either quoted printable or base 64
> encoding on whole message (except original headers), and send that as
> attachment to original headers. But, this means, user will get original
> message as a attachment.
> 
>      Now, I am not able to make out whether my approaches are right and
> which way to go ?
> 
> Regards,
> Dhananjay.
> 

Date: Wed, 14 May 2003 04:57:30 +0000
From: "Adam M. Costello" <[email-masked]>
To: [email-masked]
Subject: Re: Regarding 8bitMIME support ...
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

dhananjay <[email-masked]> wrote:

> If remote MTA does not support 8bit MIME, then the sender MTA should
> convert message from 8 bit to 7 bit and send the message.  Now, there
> can be 3 approaches (apart from perm error NDR generation) that I am
> aware of :
>
> 1. The sender MTA should first convert whole message to original
> encoding

For the five content-transfer-encodings defined by RFC 2045, this is
a no-op.  (For 8bit or binary, the conversion is just the identity
function, which is a no-op.  For 7bit, base64, or quoted-printable, the
message doesn't need 8BITMIME anyway, so just send it.)

I guess you must be concerned about how to handle other
content-transfer-encodings, besides the five defined in RFC 2045.  In
that case, I guess you're right, you need to undo it and then apply an
encoding that yields a 7bit output (like base64 or quoted-printable).

Perhaps this suggests that any new content-transfer-encoding that
produces 8bit output should be co-designed with a 7bit sibling, so that
there would be a shortcut from one to the other.  For example, maybe
the 8bit version should limit its line length to 747 bytes rather than
998, so that the 7bit version could be the same thing except that each
line is base64-encoded.  Then it would be easy to convert directly from
either one to the other.

AMC

From: "dhananjay" <[email-masked]>
To: <[email-masked]>
Subject: Regarding 8bitMIME support ...
Date: Tue, 13 May 2003 19:58:40 -0700
Sender: [email-masked]

Hi,
    I am working on enhancing MTA to support SMTP extensions (especially 8
bit MIME support). I am not clear about following issue :

    If remote MTA does not support 8bit MIME, then the sender MTA should
convert message from 8 bit to 7 bit and send the message. Now, there can be
3 approaches (apart from perm error NDR generation) that I am aware of :
    1. The sender MTA should first convert whole message to original
encoding (octet stream), and then apply base 64 encoding on that to get 7
bit. But, this seems to be very length procedure and tedious processing.

     2. The sender MTA should apply quoted-printable encoding (one can use
even base64 encoding also .. as final aim is 7bit output ?) directly on 8
bit MIME message. But, then we lose track of original message format
(say,octet stream). And, mail clients trying to retrieve message from this
remote MTA will not be able to get original message format (octet stream).
They will be able to decode the message to 8bit MIME, but not from 8 bit
MIME to octet stream (original message format), as we have lost track of
octet stream -> 8bit MIME encoding.

    3. The sender MTA should apply either quoted printable or base 64
encoding on whole message (except original headers), and send that as
attachment to original headers. But, this means, user will get original
message as a attachment.

     Now, I am not able to make out whether my approaches are right and
which way to go ?

Regards,
Dhananjay.

Date: Sat, 03 May 2003 14:54:51 -0700 (PDT)
From: [email-masked]
Subject: Re: More micalg oddities
To: Bruce Lilly <[email-masked]>
Cc: IETF-822 Mailing List <[email-masked]>
Sender: [email-masked]

> RFC 1847 again, section 2.1:

>     The attribute token for the micalg parameter is "micalg", i.e.,

>      parameter := "micalg" "=" value

>     The Message Integrity Check (MIC) is the name given to the quantity
>     computed over the body part with a message digest or hash function,
>     in support of the digital signature service.  Valid value tokens are
>     defined by the specification for the value of the protocol parameter.
>     The value may be a comma (",") separated list of tokens, indicating
>     the use of multiple MIC algorithms.  As a result, the comma (",")
>     character is explicitly excluded from the list of characters that may
>     be included in a token used as a value of the micalg parameter.  If
>     multiple MIC algorithms are specified, the purpose and use of the
>     multiple algorithms is defined by the protocol.

> That seems rather odd, as "value" is not defined specifically for the
> micalg parameter, and the definition immediately preceding the quoted
> text (for value as used in the protocol parameter) doesn't seem to be
> applicable. "token" is mentioned in the text, and Content-Type header
> field parameter values are specified in RFC 2045 as amended by RFC 2231.
> The really odd part is that the quoted text above mentions that the
> value can be a comma-separated list and mentions excluding comma. But
> comma is in the list of tspecials defined in RFC 2045, and therefore
> can never be part of a "token" and cannot appear unquoted (and unencoded)
> in a parameter value.

Oh please, this isn't rocket science. Surely it is obvious that multiple hash
algorithms can be applied to the same object simultaneuously. In situations
where multiple hashes are needed by the signature, the micalg parameter permits
specification of more than one. Comma is the separator used to delineate
multiple values, so comma is specifically excluded from the characters that
can be used in the name of a hash.

You're confusing the word token used in the generic sense of "a semantic
unit of information" and the token ABNF production.

And no, I don't think the text is at all unclear in its present form. You're
going far out of your way to assign a nonsensical interpretation to the
words.

> Content-Type: multipart/signed ; micalg="md5,sha1"

> is syntactically legal per RFC 2045, but the micalg parameter value is
> a single quoted-string (as opposed to a token) and not a comma-separated
> list of tokens.

No, it is a list of tokens. Just not a list of tokens in the ABNF sense.

> RFC 2045/2231 Content-Type parameter syntax doesn't seem to provide for a
> list of values in a parameter, unlike RFC 2298's syntax for the
> Disposition-Notification-Options header field, which does explicitly
> provide for a list in disposition-notification-parameters.

Which is why the list has to be embedded in a single value.

> To further complicate matters, RFC 3335 section 5.3.1 refers to "the"
> micalg value used by the sender in multipart/signed (not a list of
> values) and the usage in the Received-content-MIC MDN field would
> seem to preclude use of multiple algorithms (and that section is
> where 3335 refers to an IANA registered MIC algorithm ID).  Unless,
> that is, multiple Received-Content-MIC fields may appear in an MDN --
> RFC 3335 is silent on that matter.

It seems fairly obvious that if the value is a list you'd simply put the
list into a single header field.

> So how does all this tie together? Does RFC 1847 require a third level of
> parsing (after the low-level RFC 822 parsing and the Content-Type field
> parsing) to see if the parameter value contains commas?

Of course it does.

> Is it even
> possible to use a list of values as suggested in 1847?

Of course it is.

> If so, does
> 1847 really mean a quoted-string (or continuation equivalent) rather
> than a list of tokens (which is not permitted by the 2045 syntax)?

It really means a list of tokens inside of a quoted string. This is really
silly, you know.

				Ned

Date: Sat, 03 May 2003 14:24:41 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: IETF-822 Mailing List <[email-masked]>
Organization: Bruce Lilly
To: IETF-822 Mailing List <[email-masked]>
Subject: More micalg oddities
Sender: [email-masked]

RFC 1847 again, section 2.1:

    The attribute token for the micalg parameter is "micalg", i.e.,

     parameter := "micalg" "=" value

    The Message Integrity Check (MIC) is the name given to the quantity
    computed over the body part with a message digest or hash function,
    in support of the digital signature service.  Valid value tokens are
    defined by the specification for the value of the protocol parameter.
    The value may be a comma (",") separated list of tokens, indicating
    the use of multiple MIC algorithms.  As a result, the comma (",")
    character is explicitly excluded from the list of characters that may
    be included in a token used as a value of the micalg parameter.  If
    multiple MIC algorithms are specified, the purpose and use of the
    multiple algorithms is defined by the protocol.

That seems rather odd, as "value" is not defined specifically for the
micalg parameter, and the definition immediately preceding the quoted
text (for value as used in the protocol parameter) doesn't seem to be
applicable. "token" is mentioned in the text, and Content-Type header
field parameter values are specified in RFC 2045 as amended by RFC 2231.
The really odd part is that the quoted text above mentions that the
value can be a comma-separated list and mentions excluding comma. But
comma is in the list of tspecials defined in RFC 2045, and therefore
can never be part of a "token" and cannot appear unquoted (and unencoded)
in a parameter value.

So,

Content-Type: multipart/signed ; micalg="md5,sha1"

is syntactically legal per RFC 2045, but the micalg parameter value is
a single quoted-string (as opposed to a token) and not a comma-separated
list of tokens.

Even

Content-Type: multipart/signed ; micalg*0=md5 ; micalg*1="," ; micalg*2=sha1

isn't really a comma-separated list; it's equivalent to the earlier
version, i.e. a string that happens to contain a quoted comma.

RFC 2045/2231 Content-Type parameter syntax doesn't seem to provide for a
list of values in a parameter, unlike RFC 2298's syntax for the
Disposition-Notification-Options header field, which does explicitly
provide for a list in disposition-notification-parameters.

To further complicate matters, RFC 3335 section 5.3.1 refers to "the"
micalg value used by the sender in multipart/signed (not a list of
values) and the usage in the Received-content-MIC MDN field would
seem to preclude use of multiple algorithms (and that section is
where 3335 refers to an IANA registered MIC algorithm ID).  Unless,
that is, multiple Received-Content-MIC fields may appear in an MDN --
RFC 3335 is silent on that matter.

So how does all this tie together? Does RFC 1847 require a third level of
parsing (after the low-level RFC 822 parsing and the Content-Type field
parsing) to see if the parameter value contains commas?  Is it even
possible to use a list of values as suggested in 1847?  If so, does
1847 really mean a quoted-string (or continuation equivalent) rather
than a list of tokens (which is not permitted by the 2045 syntax)?

Date: Sat, 03 May 2003 12:30:13 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: IETF-822 Mailing List <[email-masked]>
Organization: Bruce Lilly
To: IETF-822 Mailing List <[email-masked]>
Subject: MICALG registry?
Sender: [email-masked]

RFC 1847 provides for a required micalg parameter with a
multipart/signed composite media type. But 1847 lists no
values for that parameter, nor does it refer to any sort
of registry of values for it.

RFC 3335 makes use of the micalg parameter and defines
two initial values, md5 and sha1.  But again there's no
mention of any registry or registration procedure for
micalg values.

The closest thing to a registry that I could find is
http-dig-alg, but that's HTTP-specific.

Is there a micalg registry?