Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA06459; Sat, 30 Jan 1999 15:40:49 -0500 (EST) Received: by cs.cs.utk.edu (bulk_mailer v1.11); Sat, 30 Jan 1999 15:40:05 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id PAA06397; Sat, 30 Jan 1999 15:40:04 -0500 (EST) Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id PAA06383; Sat, 30 Jan 1999 15:39:59 -0500 (EST) Received: from p6.jck.com ("port 1247"@[206.99.215.34]) by a4.jck.com (PMDF V5.1-11 #C3296) with SMTP id <0F6E00F1A42JSO@a4.jck.com> for drums@cs.utk.edu; Sat, 30 Jan 1999 15:39:55 -0500 (EST) Date: Sat, 30 Jan 1999 15:39:42 -0500 (Eastern Standard Time) From: John C Klensin Subject: Re(2): stripped-down client configuration (Address, MX RRs, A RR-only?) In-reply-to: <19990130201949.014005@relay.skynet.be> To: Brad Knowles Cc: drums@cs.utk.edu Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.5 Build (42) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Priority: NORMAL X-Authentication: none List-Unsubscribe: Speaking as a participant, not as editor... On Sat, 30 Jan 1999 20:19:49 +0100 Brad Knowles wrote: > As I said, I think this gets down to initial message injection versus > transport of a previously injected message. I feel that name->mx->a is > the only correct method in the latter case, but I believe you're asking > too much of (stupid) MUA authors to expect them to handle it in the > former case. >... > Any standard that makes "requirements" that are blatantly ignored for > something like this risks simply alienating the programmers, system > administrators, users, etc... that it is supposed to help serve. >... You are getting a little hyperbolic in applying this argument to this situation. Many MUA authors do use name->mx->a, some don't. I suggest that it is probably useful for us to provide some guidance as to what is expected here, and maybe the reasons why. > I think we need to make a clean and clear break between initial > message injection and the transport of previously injected messages. We > can do this with separate sections, we can do this with specific language > that calls out what is appropriate where, or we can do this with totally > separate standards documents. Frankly, I don't care which, but I think > the time has come where we need to make that break. >... We can do this in the SUBMIT document? john