Reply to bilateralTable attribute

["Kevin E. Jordan" <[e-mail]>]

> I agree with this analysis.   Use of SEQUENCE would allow tables to
> overlap, because it makes the tables ordered.  I did make this
> observation in my note, but didn't spell out the consequences as
> clearly as you have.   
> 
> Because I belive that this will be rare (the examples cited, would be
> handled better by multiple routing trees), I think that the simpler
> solution is better.   
> 
> If you remain unconvinced, let me know quickly, and I will move to the
> other solution.   It is more general, and not much more complex (and
> Julian will probably only throw a small rock at me for adding yet
> another attribute syntax).    

I remain unconvinced.

I don't see how usage of multiple routing trees solves the problem.  The
location(s) of an MTA's bilateral table(s) is/are defined in its own directory
entry, right?  This is also where the MTA's routingTreeList is defined.
An MTA's bilateral tables hold its half of the bilateral agreements it has
registered with peers.  An MTA discovers information about other MTA's by
traversing routing trees, but it does not read the bilateral tables of other
MTA's because the information contained in those tables defines their halves
of bilateral agreements. Besides, ACL's may prevent reading the tables
of other MTA's because the information contained in those tables may be
sensitive.

The DN of the MTA's own entry will usually be configured statically.  In fact,
it is probably the -only- piece of configuration information that needs to be
configured statically for an MTA which conforms to the MHS-DS specifications.
At startup, the MTA will use this statically configured piece of information
to find and read its own entry, where it will find its bilateral table
attribute (among other attributes).  An MTA doesn't discover its bilateral
table attribute by traversing routing trees while looking up recipient O/R,
does it?  

I suppose that a site could define multiple MTA's, perhaps all running on the
same host system, and cause outbound messages to be directed to the proper
internal MTA on the basis of recipient addresses, and this would implicitly
cause the proper bilateral table(s) to be used.  This seems outrageously
complex, however.