Date: Wed, 02 Jun 1999 21:24:51 -0400
From: John C Klensin <klensin@mci.net>
Subject: Re: Message-ID (was: RE: Take 2: References/In-Reply-To replaceme nt
 text)
In-reply-to: <v04020a3db37b835960b3@[130.237.150.138]>
To: Jacob Palme <jpalme@dsv.su.se>
Cc: IETF working group on revision of mail standards <drums@cs.utk.edu>
Message-id: <EXECMAIL.990602212451.D@dataarch1.mci.net>
MIME-version: 1.0
Content-type: Text/Plain; charset=us-ascii
Priority: NORMAL
References: <v04020a3db37b835960b3@[130.237.150.138]>
 <199906021335.JAA01766@astro.cs.utk.edu>

On Thu, 03 Jun 1999 03:08:33 +0200 Jacob Palme <jpalme@dsv.su.se>
wrote:
 
> Shortcoming of existing software should not limit
> ourselves. Globally unique Message-IDs can perform many
> useful functions, if they were correctly used:
> 
> - Coordination of duplicates of the same message
> - Loop control
> - Commands for users to recognize and traverse threads
>...

In case it isn't clear, I completely agree with all of this.  If
Jacob and I disagree about any of it, that disagreement probably
lies in...

> This is not a comment on the general issue of using
> FQDNs to generate Message-IDs. For the record, I strongly
> support this principle, but what I write above is only
> a comment on John's statements about the uselessness of
> Message-IDS.

In principle, I think they are a great idea, and I'd like to see
much wider support of exactly the sort of facilities Jacob 
identifies.   In practice, there have been so many sloppy 
practices in implementing and inappropriate copying or 
rewriting of Message-IDs that I'm a little pessimistic about the
use of the current mechanism, especially in the absence of 
heuristics to untangle and clean up the messes.  That, in turn, 
leads to an entirely pragmatic inclination to abandon 
"Message-ID:" and replace it with "Message-ID2:" with an 
associated very clear set of rules, semantics, requirements, and
expectations.

None of which has much to do with the question in front of DRUMS.

   john