Re: More on implications of 22.2 Wed, 06 July 1994 10:18 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa01055; 6 Jul 94 6:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01051; 6 Jul 94 6:18 EDT
Received: from by CNRI.Reston.VA.US id aa02587; 6 Jul 94 6:18 EDT
Received: by; Wed, 6 Jul 94 05:18:28 -0500
X-From: Wed Jul 6 05:18 CDT 1994
Received: from by; Wed, 6 Jul 94 05:18:19 -0500
Received: from by; Wed, 6 Jul 94 05:18:00 -0500
Received: from localhost (hta@localhost) by (8.6.9/8.6.9) with SMTP id UAA01015; Tue, 5 Jul 1994 20:51:21 +0200
Message-Id: <>
X-Authentication-Warning: Host localhost didn't use HELO protocol
To: "\"Kevin \" E. \" Jordan\"" <>
Subject: Re: More on implications of 22.2
In-reply-to: Your message of "Mon, 04 Jul 1994 12:21:25 MET DST." <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Date: Tue, 05 Jul 1994 20:51:20 +0200

on reading, re-reading and re-re-reading 22.2, I have to agree with Kevin.
The paragraph refers to behaviour that is mandated by X.400 (without
supplying a chapter-and-verse reference; at the moment I can't think of
where it is specified), and suggests one specific means of handling
this matter (using aliases for variant forms of a name).

The paragraph may suggest that the requirements of X.4XX para yy may
be satisfied using aliases, and may mandate that all such aliases
may be followed, but should not say that this is the only way to
support this functionality.

What IS critical, however, is that routing is set up in such a way
that no MTA anywhere in the world falsely rejects a message because
it cannot find the info in the directory; that is, MTAs using a
private mechanism for resolving underspecified O/R names MUST put
information at the appropriate O or OU level identifying an MTA
for this level and "not all subordinate entries listed".

This will ensure that misspelled O/R names cannot be rejected at
the originator, but must be transferred to the recipient organization
before being rejected, but this is unavoidable where a private resolution'
mechanism exists.

BUT: I think that the current language is adequate for releasing as a
Experimental RFC, and we can modify this later "in the light of experience".

           Harald A