Re: Reply to bilateralTable attribute

[Steve Kille <[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).    


Steve



 >From:  Kevin "E." Jordan <[e-mail]>
 >To:    [e-mail]
 >Subject: Reply to bilateralTable attribute
 >Date:  Tue, 22 Mar 94 13:30:28 -0600

 >> 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
 >> 
 >> 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?
 >
 >Suppose that two organizations are members of a broad community and this
 >community has established a common "multilateral" table.  Suppose that the two
 >organizations establish a bilateral agreement to exchange special passwords,
 >or use special presentation addresses, or define more lenient authentication
 >requirements when connecting to each other.  If the attribute is defined
 >as multivalued, and  not as a SEQUENCE, then a calling MTA may not see
 >the values in the same order each time that it reads them.  Thus, the calling
 >parameters used by the calling MTA might differ from one call to the next.
 >Similarly, the authentication parameters used by the responding MTA might
 >differ from one call to the next.  Won't this cause problems?  At the
 >very least, it will generate unpredictable behavior.