revised 822, and Reference: fields, etc.

Hugh Sasse <hgs@dmu.ac.uk> Wed, 24 November 1999 16:59 UTC

Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07209 for <drums-archive@odin.ietf.org>; Wed, 24 Nov 1999 11:59:29 -0500 (EST)
Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA21791; Wed, 24 Nov 1999 11:58:53 -0500 (EST)
Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 24 Nov 1999 11:58:19 -0500
Received: by CS.UTK.EDU (cf v2.9s-UTK) id LAA21746; Wed, 24 Nov 1999 11:58:18 -0500 (EST)
Received: from macondo.dmu.ac.uk (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id LAA21731; Wed, 24 Nov 1999 11:58:13 -0500 (EST)
Received: from macondo.dmu.ac.uk (146.227.1.4 -> macondo.dmu.ac.uk) by CS.UTK.EDU (smtpshim v1.0); Wed, 24 Nov 1999 11:58:13 -0500
Received: from helios.dmu.ac.uk (root@helios.dmu.ac.uk [146.227.1.1]) by macondo.dmu.ac.uk (8.8.8/8.8.8) with ESMTP id RAA00248 for <drums@cs.utk.edu>; Wed, 24 Nov 1999 17:08:42 GMT
Received: from helios.dmu.ac.uk (hgs@helios.dmu.ac.uk [146.227.1.1]) by helios.dmu.ac.uk (8.9.1/8.9.1) with ESMTP id QAA17519 for <drums@cs.utk.edu>; Wed, 24 Nov 1999 16:57:53 GMT
Date: Wed, 24 Nov 1999 16:57:52 +0000
From: Hugh Sasse <hgs@dmu.ac.uk>
To: drums@cs.utk.edu
Subject: revised 822, and Reference: fields, etc.
Message-ID: <Pine.GSU.4.10.9911241638420.13757-100000@helios.dmu.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>

With reference to:

Internet Message Format Standard

http://www.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-07.txt

I would like to make the following comments, if I may, although I would be
the first to say I have a lot to learn in this area.

One concern I have is that there is no recommended upper limit for
In-Reply-To: and Reference: message-id lists.  If a conversation continues
for a long time then it seems to me that these fields could grow to be
very large, possibly longer than the message bodies. I wonder if a token
to say "this list has been truncated" would be useful, to stop these
getting ridiculously big, whilest acknowledging they have been trimmed?
It might be something like an ellipsis (...) at the end of the field.

Once one has reference to some earlier messages, they will hold references
to still earlier messages, so the information will not be lost.

If this were to be allowed, then I think it might be useful to define:
    a recommended lower limit for the number of IDs in a list which an
	MTA SHOULD accept
    a recommended lower limit for the number of IDs left after such a list
	has been truncated 
    a recommended upper limit for the number of IDs an MTA SHOULD put in
	such a field

I hope these comments and suggestions are of some help.
	Thank you,
	Hugh
	hgs@dmu.ac.uk