[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference forty2::mailbus_400

Title:MAILBUS 400 User Forum
Notice:kits 100-109 - Infocenter //www.digital.com/info/messaging
Moderator:IOSG::MARSHALL
Created:Thu Jun 11 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3210
Total number of notes:9174

3199.0. "PerDomainBilateralInformation assistance required" by BACHUS::CLEVELAND (L'Escargot) Wed May 21 1997 16:54

Below is the description of a problem from one of our customers regarding 
interaction between '88 and '84 systems and the PerDomainBilateralInformation. 
I have included it verbatim because he has described it far better than I ever 
could!

I know this has been mentioned before and it has been suggested that the
registry be changed on the X.400 connector not to generate the Bilateral info
but this solution is not appropriate for this customer.

Has anybody any ideas on another way around this?

By the way, explanations in words of one syllable please, this one is beyond
my level of experience with this product!!   :-(

Thanks,

Brian Cleveland		CSC - Brussels		DTN 856-7098

-------------------------------------------------------------------------

MB400 is the mailbackbone in our company. It makes the connection to our
X.400 ADMD (84 connection) and links different systems within Telecom.
The most important with several thousand users is MS Exchange. Exchange
and MB400 use a 88 connection. Obviously MB400 has to downgrade every
message sent from Exchange to the ADMD. Under special circumstances some
of this messages can't be delivered by the ADMD. This problem can be
reproduced. The cause of this problem seems to be the incorrect
treatment of the PerDomainBilateralInformation by Mailbus 400 .

Below is given a short description of the problem from the ADMD support:

1. MS Exchange generates PerDomainBilateralInformation according to 88
standards. That is to say, it generates it with the optional
private-domain-identifier.
(Incidentally, I believe that because the syntax specifies a sequence of
 such domains, they are intended to refer to recipient domains. MEX
generates
C=CH,A=400NET,P=SWISSTELECOM - the originator domain id).

2. According to X.419 Blue Book Message Handling Systems - Protocol
Specifications (Melbourne 1988).
Annex B Interworking with 1984 systems.
B.2.2 Per-domain-bilateral-information:
"If a private-domain-identifier is present in an element of a
per-domain-bilateral-information then that element of
 per-domain-bilateral-information shall be deleted.
Otherwise the per-domain-bilateral-information shall be unchanged."

3. The DEC system is removing the optional private-domain-identifier
element
(P=SWISSTELECOM) and leaving only (C=CH,A=400NET). This is incorrect as
this
domain identity is not that of intended recipient OR originator.
T.RTitleUserPersonal
Name		DateLines
3199.1�Que?FORTY2::KNOWLESPer ardua ad nauseamThu May 22 1997 09:4632
    Forgive my obtuseness (as I'm not a developer - well, not of X.400
    software, anyway). But it seems to me, reading only the bit of the blue
    book that the ADMD has quoted, that MB400 is doing exactly the right
    thing. Perhaps if I was more conversant with the details of the whole
    blue book I would see why the ADMD thinks our MTA is behaving
    incorrectly.
    
    �If a private-domain-identifier is present in an element of a
    �per-domain-bilateral-information
    
    [it is, because the customer's description says Exchange put it
    there...]
    
    �					then that element of
    �per-domain-bilateral-information shall be deleted
    
    [which is what we do.]
    
    To describe this as "the incorrect treatment of the
    PerDomainBilateralInformation by Mailbus 400" strikes me as bizarre.
    
    Of course, this observation doesn't help the interworking problem; I
    hope someone with more technical nous can help on that point. Forgive
    the mild flame, but I get a bit tired of people saying `DEC [sic] is
    doing it wrong' when we have worked very hard (perhaps too hard in some
    cases) at doing it right. 
    
    b
    
    ps
    I could be a little out of my depth here, so tell me to get back in my
    pram if necessary.
3199.2FORTY2::LEAVERThu May 22 1997 12:427
Bob is right, the MTA is doing what the standard requires.

As the connection to the ADMD is 84 it should not expect that element to be
there.

Karen
-----
3199.3mmm... I see your pointBACHUS::CLEVELANDL'EscargotThu May 22 1997 14:0715
    Thanks for the response. If I knew exactly what the terms were
    referring to in the standards quoted, then I'd have a chance! 
    
    Please don't tell me to RTFM because I haven't got one !!
    
    Anyway, I have asked the customer to provide more information on why he
    believes we're wrong. On re-reading the mail in the light of what .1
    said he does rather contradict himself in saying that it should be
    removed and then complaining when it does just that!
    
    I'll let you know the outcome...
    
    Thanks again.
    
    Brian
3199.4ACISS2::LENNIGDave (N8JCX), MIG, @CYOThu May 22 1997 14:1620
    In my mind the issue revolves around which "it" should be removed;
    
    ie there is one "it" which is the bilateral info element, consisting 
    	of country, admd, and optionally prmd
    there is another "it" which is the optional prmd element itself
    
    My reading of the quoted section is that the bilateral-info element
    (ie country, admd, AND prmd) should be removed; I suspect this is 
    also the ADMD's interpretation of the paragraph. Bob/Karen's reading 
    is that just the prmd part should be removed.
    
    I couldn't say which was the "correct" interpretation without research.
    
    Dave
    
B.2.2 Per-domain-bilateral-information:
"If a private-domain-identifier is present in an element of a
per-domain-bilateral-information then that element of
 per-domain-bilateral-information shall be deleted.
Otherwise the per-domain-bilateral-information shall be unchanged."
3199.5FORTY2::LEAVERThu May 22 1997 15:056
If the problem would be solved by removing the optional
per-domain-bilateral-information itself then raise an IPMT and we will
investigate it.

Karen
-----
3199.6FORTY2::LEAVERFri May 23 1997 15:1410
This was clarified in the MHS Implementors Guide and any
per-domain-bilateral-information elements containing a private-domain-identifier
should be deleted.

So please submit a severity 3 IPMT.

Thanks.

Karen
-----
3199.7Difference in interpretation of standards?BACHUS::CLEVELANDL'EscargotMon May 26 1997 10:5123
    I've had a bit more explanation from the customer of what he means.
    I'll do as suggested in -.1 and submit an IPMT. Without making any
    commitment, is it possible to make a guess at when we might possibly 
    expect a change on this?
    
    Thanks for the assistance.
    
    Brian
    
    
An 'element' of BI (1988 mode) consists of CC, ADMD ID, and optionally
PRMD ID. If the PRMD ID 'component' is present then the complete 'element'
must be deleted.

DEC is presently deleting only a 'component' of an 'element' and not the
complete 'element'.

In simple terms, the 'element' identifies the domain for which the BI is
relevant. By deleting only a 'component' DEC is changing/corrupting this
identification.
3199.8FORTY2::LEAVERTue May 27 1997 10:457
We would hope to have a fix by the end of June.  It would help if you could
supply an archive of the message when it enters the MTA with the IPMT case.

Thanks.

Karen
-----