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