Re: More on implications of 22.2
Steve Kille <S.Kille@isode.com> Tue, 05 July 1994 16:03 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04695; 5 Jul 94 12:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04691; 5 Jul 94 12:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12460; 5 Jul 94 12:03 EDT
Received: from mercury91.udev.cdc.com by IETF.CNRI.Reston.VA.US id aa04684; 5 Jul 94 12:03 EDT
Received: by mercury.udev.cdc.com; Tue, 5 Jul 94 11:02:00 -0500
X-From: S.Kille@isode.com Tue Jul 5 11:01 CDT 1994
Received: from zeus.cdc.com by mercury.udev.cdc.com; Tue, 5 Jul 94 09:00:57 -0500
Received: from glengoyne.isode.com by zeus.cdc.com; Tue, 5 Jul 94 09:00:47 -0500
To: "Kevin E. Jordan" <Kevin.E.Jordan@cdc.com>
Cc: mhs-ds@mercury.udev.cdc.com
Subject: Re: More on implications of 22.2
Phone: +44-81-332-9091
In-reply-to: Your message of Mon, 04 Jul 1994 12:21:25 -0500. <2e1845165c6b002@mercury.udev.cdc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19799.773416756.1@glengoyne.isode.com>
Date: Tue, 05 Jul 1994 15:00:57 +0100
Message-ID: <19836.773416857@glengoyne.isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille@isode.com>
Kevin, These are good points. Let me, for the record, not the converse case: 1) Here, and in general, the spec aims to use the read operation to the maximum extent. This is because it is a reasonable assumption that all DSA implementations in the context of any level of fanout will optimimse the performance of the read operation. 2) Under-specified O/R address has some serious policy implications, in particular relating to mis-delivery of mail (e.g., a secretary getting mail that should have been sent to a VP). In general it is better to non-deliver mail than to mis-deliver it. Use of aliases ensures that matching of under-specified O/R addresses is a conscious choice, where searching may lead to unpredicatble mis-delivery. I will add some text which will allow the searching option. In the long term, we can use experience to decide whether to mandate one direction or to continue to allow both. I have a couple of errors to fix in this document as well as adding some text here. Rather than confuse people with an immediate update, I suggest we defer the update until people have read this document. What do you think? Steve
- More on implications of 22.2 Kevin E. Jordan
- Re: More on implications of 22.2 Steve Kille
- Reply to More on implications of 22.2 Kevin E. Jordan
- Re: Reply to More on implications of 22.2 Richard Letts
- Re: More on implications of 22.2 Harald.T.Alvestrand