OSI/MHS Configuration and Management Manual

Routing in OSI/MHS
OSI/MHS Configuration and Management Manual—424827-003
E-9
Routing Rules Defined by NIST and X.400
This scheme works well for most O/R names, but in some cases it can result in large
sequential disk searches. For example, if all users had the same organization name
and a message arrived with that organization name and domain-defined attribute 2, a
search would be made of all the records until the right one was discovered.
OSI/MHS does not attempt to match part of a field. For instance, Fred Bloggs does not
match Frederick Bloggs.
Overspecified Names
An overspecified O/R name is one that contains name components in addition to those
you specified in the OSI/MHS configuration. In such cases, OSI/MHS routes the
message, ignoring the extra fields.
For example, if a message is received for user Fred Bloggs (Surname Bloggs, Given
Name Fred) in the local domain, and an APPL object is defined for Surname Bloggs
(with no given name), the message is routed to that APPL.
Routing Rules Defined by NIST and X.400
OSI/MHS implements routing classes 1, 2, and 3 as described in the NIST
Implementation Agreements for OSI Protocols, Part 8.
OSI/MHS is consistent with the routing rules described in the 1984 and 1988 X.400
Specifications (Blue Book Recommendation X.411).
Construction of O/R Names (1984, 1988)
OSI/MHS accepts O/R name attributes associated with MPDUs in any form defined in
the 1984 or 1988 CCITT Recommendations, including teletex attributes. See
Appendix F, Routing Support for O/R Names Containing Teletex Attributes, for
information specific to teletex attributes.
Route and Link Retry Logic
The route and link-retry logic of OSI/MHS is conditioned by the settings of various
configuration attributes. For descriptions of the route and link-retry attributes and their
effects on association establishment, see Section 2, Management Environment for
OSI/MHS.