Errors-to: owner-drums@CS.UTK.EDU
Date: Thu, 27 Jul 1995 16:21:52 +0200 (MET DST)
From: Jacob Palme <jpalme@dsv.su.se>
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
Cc: ietf-drums <drums@CS.UTK.EDU>
Subject: Re: Message-ID mandatory
In-Reply-To: <199507271020.MAA24756@mars.dsv.su.se>
Message-Id: <Pine.SUN.3.91.950727161604.10651D-100000@ester>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 27 Jul 1995, Eric Thomas wrote:

> What I don't like with this proposal  is that you get a very long message
> ID, possibly in the  150-200 byte range, and it may  contain all sorts of
> special characters. This is bound to create trouble. Of course personally
> I think that if a C program  made the assumption a message ID would never
> be more  than 40  bytes and  crashes, the programmer  is getting  what he
> deserves. But unfortunately  99% of the victims will  think otherwise and
> this will make your RFC very  impopular. I think you should just generate
> a new unique message ID.

What about a checksum, in that case, of the concatenated string.
A checksum can be short, and still have a very very small risk
of being identical to the checksum of a different string. And
a checksum can easily be encoded into a string which does not
include any characters with syntax problems. The checksum would
have the same advantage, that any system which generates a
Message-ID in this way would get the same ID.

I guess you have encountered the same problem when you wrote
Listserv? Listserv perhaps does assign Message-ID-s to messages
it receives, before expanding them. And from what you say I
conclude that Listserv does not try to use an algorithm
which would give the same Message-ID as that generated by
another system (e.g. another Listserv-er) would generate.

(I have a vague memory that we did discuss this matter a year
ago or so, in a personal mail exchange. Did we not?)

------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme