Reply to multilateral agreements

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

> there is a problem with changing the syntax of the existing
> BilateralTable attribute: I can't find it.
> Figure 7 of chap 18 gives the OBJECT CLASS of the
> mtaBilateralTableEntry, and the text points to the "bilateralTable"
> entry which is defined in figure 18.
> 
> Figure 18 is a set of object identifier assignments; the
> at-bilateral-table is assigned there.

You're right, the formal syntax for the bilateralTable attribute seems to
have been omitted.  However, it was originally agreed that this attribute
would be a simple distinguished name.

> Since this text is not in the document (?????, Steve????),
> I think the simplest change would be to put into it
> (forgive my bad ASN.1 :-)
> 
> bilateralTable ATTRIBUTE
>    WITH ATTRIBUTE-SYNTAX DistinguishedName
>    MULTI VALUE
>    ::= at-bilateral-table
> 
> That would give anyone enough information to find both the
> truly private table and any shared ones.
> The only disadvantage I can see is that it cannot impose
> sequencing on the access to the tables (same argument as goes
> with the routingTreeList attribute).

Sequencing is very important.  Normally, an MTA should check for a private
bilateral agreement first, then check for a multilateral agreement.  If more
than one multilateral table exists, the order in which these are checked would
probably be significant.  If "bilateralTable" is simply changed to a multivalued
attribute, there would be no ordering imposed upon the individual DN values,
and the MTA might receive them in a different order each time it reads them
from the DSA.

The multilateralTable attribute I proposed was explicitly defined as a 
SEQUENCE so that a specific order could be specified for the individual DN's
registered within it.

> What do you think? Does it break existing code?

Unfortunately, it -would- break existing code.  Our implementation has already
been deployed at many customer sites, and it defines the bilateralTable
attribute as a single-valued DN.  We agreed some time ago that we should avoid
redefining the syntax of existing attributes, and define new attributes
when enhancements were needed.  In this particular case, there also exists a
subtle semantic difference between a bilateral agreement and a multilateral
agreement, so this gives us an even better reason to register multilateral
agreements separately from bilateral ones.