[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 19: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.R	Title	User	Personal Name	Date	Lines
3199.1		FORTY2::KNOWLES	Per ardua ad nauseam	`Thu May 22 1997 12:46`	32
3199.2		FORTY2::LEAVER		`Thu May 22 1997 15:42`	7
	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.3	mmm... I see your point	BACHUS::CLEVELAND	L'Escargot	`Thu May 22 1997 17:07`	15
	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.4		ACISS2::LENNIG	Dave (N8JCX), MIG, @CYO	`Thu May 22 1997 17:16`	20
	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.5		FORTY2::LEAVER		`Thu May 22 1997 18:05`	6
	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.6		FORTY2::LEAVER		`Fri May 23 1997 18:14`	10
	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.7	Difference in interpretation of standards?	BACHUS::CLEVELAND	L'Escargot	`Mon May 26 1997 13:51`	23
	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.8		FORTY2::LEAVER		`Tue May 27 1997 13:45`	7
	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 -----