Reply to presentation address for mta

Kevin Jordan <> Wed, 25 January 1995 13:55 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa02263; 25 Jan 95 8:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02259; 25 Jan 95 8:55 EST
Received: from by CNRI.Reston.VA.US id aa04860; 25 Jan 95 8:55 EST
Received: by; Wed, 25 Jan 95 07:54:09 -0600
X-From: Wed Jan 25 07:54 CST 1995
Received: from localhost by; Wed, 25 Jan 95 07:42:40 -0600
To: MHS Mail <>
cc: MHSDS list <>
Subject: Reply to presentation address for mta
In-reply-to: Your message of "Wed, 25 Jan 95 11:47:33 +0700" <9501251047.AA03124@karl.wtk.suresnes>
Date: Wed, 25 Jan 95 07:42:39 -0600
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Kevin Jordan <>
Message-Id: <>

> I am wondering about one attribute in the mta object class :
> callingPresentationAddress. As the applicationEntity object
> class already defines an attribute called presentationAddress,
> why is there a need to have two different attributes. Note that
> the callingSelectorValidity is understandable as it will drive
> the local MTA when checking on presentation address (useful with
> RFC 1006 by example).

The callingPresentationAddress attribute allows for the case where an
MTA initiates connections from a different address than it accepts them on.
This situation actually occurs in current X.400 communities including
the Internet X.400 community.  Note that the callingPresentationAddress
attribute may also be multivalued.  This allows all of the presentation
addresses from which an MTA may initiate calls to be registered.  This is
particularly useful in the case where an MTA can initiate calls over a
variety of network layers (for example X.25, CLNP, RFC1006).  Its NSAP address
will be different in each of these cases.  When a call is received from
such an MTA, the called MTA can take whatever calling NSAP has been delivered
to it and use this to search the directory for the MTA entry containing a
callingPresentationAddress attribute value which matches.