Re: More on implications of 22.2

[[e-mail]]

Steve,
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