Reply to More on implications of 22.2

"Kevin E. Jordan" <Kevin.E.Jordan@cdc.com> Wed, 06 July 1994 03:21 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15907; 5 Jul 94 23:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15897; 5 Jul 94 23:21 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa09614; 5 Jul 94 23:21 EDT
Received: by mercury.udev.cdc.com; Tue, 5 Jul 94 22:19:57 -0500
X-From: kej@mercury.udev.cdc.com Tue Jul 5 22:19 CDT 1994
Received: from localhost by mercury.udev.cdc.com; Tue, 5 Jul 94 22:19:54 -0500
To: Steve Kille <S.Kille@isode.com>
cc: mhs-ds@mercury.udev.cdc.com
Subject: Reply to More on implications of 22.2
In-reply-to: Your message of "Tue, 05 Jul 94 15:00:57 BST" <19836.773416857@glengoyne.isode.com>
Date: Tue, 05 Jul 1994 22:19:53 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Kevin E. Jordan" <Kevin.E.Jordan@cdc.com>
Message-Id: <2e1a22da0f76002@mercury.udev.cdc.com>

> 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.  

I understand the strong tendency to use only read operations.  In most cases,
this is a good idea.  However, when this leads to proliferation of aliases,
it is probably -not- a good idea and an alternative approach should be
considered. 

> 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 agree that it is very bad to mis-deliver mail.  However, prevention
of mis-delivery can be achieved without having to rely upon aliases.  For
example, a search operation using an exact match filter can achieve the
same result.  This may require that administrators create multivalued
commonName and/or mhsORAddresses attributes in every entry for which
underspecified addressing is desired (a form of "conscious choice"), but this
is far better than having to create many aliases for the same user because
it is MUCH easier to administer.

> 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.   

Thank you.  I agree that it is premature to mandate either solution at this
time.

> 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?

Agreed.