Re: MHS-DS: Directory Support for mapping between X.400 and RFC822 addresses

Steve Hardcastle-Kille <S.Kille@isode.com> Sun, 03 January 1993 19:21 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04937; 3 Jan 93 14:21 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04933; 3 Jan 93 14:21 EST
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa13052; 3 Jan 93 14:21 EST
Received: by mercury.udev.cdc.com; Sun, 3 Jan 93 13:12:54 -0600
X-From: S.Kille@isode.com Sun Jan 3 13:12 CST 1993
Received: from haig.cs.ucl.ac.uk by mercury.udev.cdc.com id SMTP-0032b473aa2000601; Sun, 3 Jan 93 13:12:35 -0600
Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP id <g.01339-0@haig.cs.ucl.ac.uk>; Sun, 3 Jan 1993 17:56:33 +0000
Received: from localhost.cs.ucl.ac.uk by glengoyne.isode.com with SMTP (PP) id <04799-0@glengoyne.isode.com>; Sun, 3 Jan 1993 17:57:15 +0000
To: Urs Eppenberger <Eppenberger@switch.ch>
cc: mhs-ds@mercury.udev.cdc.com
Subject: Re: MHS-DS: Directory Support for mapping between X.400 and RFC822 addresses
Phone: +44-71-223-4062
In-reply-to: Your message of 17 Nov 92 09:50:57 +0100. <1465*Eppenberger@switch.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 03 Jan 1993 17:56:58 +0000
Message-ID: <4797.726083818@isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Hardcastle-Kille <S.Kille@isode.com>

 >From:  Urs Eppenberger <Eppenberger@switch.ch>
 >To:    mhs-ds@mercury.udev.cdc.com
 >Subject: MHS-DS: Directory Support for mapping between X.400 and RFC822 
	 addresses
 >Date:  17 Nov 92 09:50:57 +0100

 >Typos: 
 >Figure 1 line 14 should probably read ...x400-to-rfc822-...

ta

 >
 >The last sentence in the last paragraph of chapter 3 shoudl probybly go to
 >the end of chapter 2 (?)

yes

 >
 >General:
 >The distribution of the mapping tables is very dangerous. (Just check a
 >little bit in the DNS and you will find thousands of wrong entries, especially
 >for reverse mappings.)
 >I suggest to modify the proposal to make it possible to introduce the
 >distributed mappings step by step, for example
 >1. global mappings at a single point in the DIT
 >2. mappings split per country and stored at C=xx for each country
 >3. mappings at the 'natural' place in the DIT
 >4. speed up the mapping using nonAuthoritativeORAddress attributes
 >
 >It is not possible to go to step 3 as long as we have table based RFC1327
 >implementations.

I think that we need to make a decision and go for it.  The first
version of this document was done the other way round (with separate
subtrees).   

The document argues why it has made the proposed choice!   In
practice, introduction will be reasonably straightforward, as
initially each country is likely to have its X.400 and 822 information
stored in relatively few DSAs.   If it really seems impossible to
introduce this stuff.

 >
 >The concept of speeding up the mapping process using nonAuthoritativeORaddress
 >is a source of inconsistency and wrong configuration. I suggest not to
 >introduce it until appropriate checking tools are available.
 >

I'll add a note about this.

 >
 >Steve, you face the same problems as I had with my routing document. You 
 >design a documentation format which supports everything you wanted. But you 
 >will need to add a considerable amount of text on how to really use it in an 
 >operational environment.
 >It is not possible to finalise the definition first and then write the
 >documents about how to use it. (This error has been made with X.400.) We need
 >to progress the ideas on how to use it in parallel in order to influence
 >the storage concept at an early stage. I indeed suggest to slow down the
 >progress on the 8 documents and introduce a period of let's say 5 month to
 >do some thinking on how to use it. (I'm a burned child, 80% of the troubles
 >I had in the last 5 years had their roots in RFC987 and 1148 :-))

Agreed - we need to try it out before casting anything in concrete.
I'm sorry to have caused you so much grief in the past!

 >
 >Kind regards,
 >
 >Urs.


Steve