Message-Id: <v03005711ad769b9a4595@resnick1.isdn.uiuc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 20 Mar 1996 23:50:14 -0600
To: drums@cs.utk.edu
From: Pete Resnick <presnick@qualcomm.com>
Subject: Multiple To: headers

RFC 822, page 17, section 4.1 currently reads as follows:

            This specification permits multiple  occurrences  of  most
            fields.   Except  as  noted,  their  interpretation is not
            specified here, and their use is discouraged.

That I take to mean that the semantics of multiple fields are undefined
except as noted. Given that, we don't do a great deal to bend over
backwards to do anything with multiple occurences of fields. For instance,
when doing a reply, we will choose the first Subject: line to include in
the reply, and will choose the first To: address to put in a reply if the
user has selected "Reply to all." But all in all, this seems silly; there
are perfectly good ways to put multiple recipients on a To: line, and there
is really no reason to generate such awful things.

Unfortunately, there are at least some beasties out there that are
generating multiple To: lines. This to me seems to indicate that it was not
strongly enough "discouraged" in 822. And of course, for every one that is
generated, we get some user who complains because our reply all command
doesn't go looking for multiple To:'s.

Are there any objections to strengthening this to say MUST NOT generate and
MAY interpret, as against what it almost is now (SHOULD NOT generate and
MAY interpret)? I would even settle for a direct SHOULD NOT generate, but
simply "discouraging" clearly does not work. In any case, most people I
have communicated with agree that this is a silly practice.

Comments?

pr

--
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated
Home: (217)337-1905 / Fax: (217)337-1980