Re: bilateralTable attribute

[Steve Kille <[e-mail]>]

Kevin,

I'm replying to your original message on this, primarily to
demonstrate that I do keep track of issues, even if I am unresponsive
at times!

As Harald has pointed out, the key ASN.1 is missing from the spec.
Interestingly, I did type the data, but simply forgot to include the
file in the parent document.   Here is the missing text:

bilateralTable ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
        SINGLE VALUE
        ::= at-bilateral-table


I think that the case for multiple tables has been argued
convincingly.   However, I note that the GO-MHS WEP type of
collaboration would be much better handled by use of a private routing
community, rather than just a shared MTA table.   The reason for this
is that the community would effectively correlate routing as well as
MTA information.   I will make some appropriate notes.

It has been suggested that the syntax be changed to SEQUENCE.   This
would be needed if an order is necessary on the tables.   I think that
unordered tables will suffice, and that the simpler change of making
the bilateralTable multi-value is better.   I propose to do it this
way.    Any comments?


Steve



 >From:  Kevin "E." Jordan <[e-mail]>
 >To:    [e-mail]
 >Subject: bilateralTable attribute
 >Date:  Mon, 19 Jul 93 11:51:14 -0500

 >After you left Amsterdam, I heard some very good arguments in support of
 >making the bilateralTable attribute a sequence of DN's instead of a single
 >DN.  This would seem to be very useful to the GO-MHS community as it would
 >allow them to define a large shared table of the participating MTA's along
 >with their names and presentation addresses.  It would provide the basis for
 >rejecting connections from MTA's outside of the community.  In addition,
 >some MTA's may need to define truly bilateral agreements.  So, there appears
 >to be a legitimate need to turn the bilateralTable attribute into a sequence.
 >Let's do it.  Can you think of a good reason that this change should not
 >be made?