Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id DAA02881; Fri, 8 Dec 1995 03:28:41 -0500 Received: by cs.cs.utk.edu (bulk_mailer v1.3); Fri, 8 Dec 1995 03:28:23 -0500 Received: from garage.qualcomm.com by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id DAA02864; Fri, 8 Dec 1995 03:28:21 -0500 Received: from [129.46.54.51] (annex-p11.qualcomm.com) by garage.qualcomm.com (post.office MTA v1.9.1 ID# 0-11142) with ESMTP id AAB1184; Fri, 8 Dec 1995 00:27:43 -0800 X-Sender: jwn2@mage.qualcomm.com Message-Id: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailer: Eudora [Macintosh version 3.0a63-1.96] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Fri, 8 Dec 1995 02:27:38 -0600 To: Jacob Palme , Jim Conklin From: jwn2@qualcomm.com (John Noerenberg) Subject: Re: Clarify amibuities) Cc: ietf-drums At 1:24 PM 12/7/95, Jacob Palme wrote: >On Wed, 6 Dec 1995, Jim Conklin wrote: >> What we have with Reply-To is really not an ambiguity but a situation in >> which the header is used in multiple, non-ambiguous ways, all of which meet >> the needs of certain situations, and each of which results in the reply >> mail being delivered to the address to which the sender (whether it be an >> individual or an agent) intends the reply to be delivered. > >What is the difference between "multiple, non-ambiguous ways" and >"ambiguous"? I do not understand. If the same header is used in >different ways, with no indication of which way is intended >when it is used, then to my understanding if English this is >ambiguous. > Jim is arguing that in each context in which Reply-To is used (two have been mentioned, directing replies to lists and directing personal replies), the intended destination of a reply to a message is clear: the destination of a reply to this message must be sent to the value of the Reply-To field. This seems unambiguous to me, and perfectly implementable. Ambiguities for the interpretation of Reply-To are introduced in the presence of a Sender field. The semantics of Sender have always been confusing to me. Reading over the definition of Sender, I'm inclined to think it is an anachronism we can discard. Discarding Sender eliminates ambiguities for Reply-To. I suggest deprecating Sender. That kills 2 birds with one stone. :-) best, john noerenberg jwn2@qualcomm.com In Dallas 12/3 - 12/8 for IETF ---------------------------------------------------------------------- Whoso neglects learning in his youth, Loses the past and is dead for the future -- Euripides, Phrixus, [c. 420 B.C.] ----------------------------------------------------------------------