Reply to RFC 1327 Mappings in X.500

[Michael Storz <[e-mail]>]

> I started work on editing this yesterday, and working through the
> implications of various changes.
>
> Currently, the mapping is placed in the routing trees.   There is a
> note to explain why storing the mapping separately is not chosen.   I
> think that we should reverse this decision for the following reasons:
>

I have just read Kevins response to this letter.  I agree absolutely with Kevin.
I do not see any reason why to change this approach.  On the contrary, if this
results in a kind of table thing it would be totally agaist the idea of a
decentralized X.500 directory and therefore a major step backward.

>
> 1) There are severe difficulties with maintaining consistency between
> 1327 mappings held in multiple routing trees.  This has been exposed
> in review.
>

The main source for the mappings is the Open Tree. I see two reasons why
somebody maintains additional mappings in private trees:

1) because different mappings are needed locally (I use this a lot for our
   domains)
2) problems with accessing the data in the Open Tree

The functionality of 1) is needed. Therefore any approach must give me this
possibility and hence this could lead to inconsistent mappings, if the data is
not managed carefully. This is a problem of humans and cannot be changed by any
approach.

To help people to maintain their mappings good tools are need, but there is no
need to change the algorithm. For example lookupORname and lookupDomain
provided with Mail*Hub are a first step in the right direction. With these
commands you get the information how the mapping is done, which components
remain etc. Based on duaperl and such commands you can write the needed tools,
like the examples listOT and pingMTAs from Kevin. This is something the vendor
of an X.400 package must do.

If 2) is the cause of the inconsistency, then this is a sign that X.500 is not
working as stable as DNS for example. But then it makes no sense to try to treat
the symptoms. You have to cure the real cause, which is the working of X.500.
If X.500 does not work then every replication will fail.

> 2) A gateway needs good access to all of the mappings.   The new
> approach makes replication much easier.

Totally wrong approach. Yes, a gateway needs good access to the offical
mappings. But it does not need a better access to this information than a MTA
needs access to the routing information. Your replication approach would mean
to replicate all worldwide information stored in X.500, which makes absolutely
no sense.

Maybe you think these new tables would be similar to the RARE-Mapping-Tables in
size.  This is not correct.  The size of the mapping information in the open
tree will be much bigger than the RARE tables. On the contrary, I am missing the
possibility to specify the mapping of whole mail addresses and not only the
mapping of domains.

What is needed is to have fast access to the information which is needed very
often. This information you will only get with good caching strategies. That
means caches in the local DSA, in the local DUA and in the daemons which are
working with this information. Again this is a matter of the implementation and
a point where you can distinguish different implementations.

>
> 3) The "ommitted component" stuff fits very very badly into the open
> routing tree

I thought you be would be more convinced of your own proposals :-) I think that
both proposals for the mapping from X.400 to RFC 822 fit in the open routing
tree.  You are right, a solution without empty components would be more elegant.
But the reason why we have to deal now with these mappings is a direct
consequence of RFC 1327.  RFC 1327 would also be more elegant and simpler if
there would be no empty components and no need to deal with them.  But they
exist.

>
> 4) Having a separate area gives a much easier and more manageable
> migration/relationship with the table approach

I do not agree. With your new approach there is no migration, it is only a
different way how to distribute the tables. Again, to make it manageable you
need the right tools but not a new approach.

>
>
> I believe that this is a strong case, and will change the I-D in this
> manner.    What do others think?
>

Don't do that, just forget it.  We should conzentrate to find a solution for the
empty component problem.  This is as Kevin said a minor technical problem
compared to the whole design.  Your new suggestion is like an earthquake for the
design and not only a little repair work.

>
> Steve

Regards,

Michael