OSI/MHS Configuration and Management Manual

Routing in OSI/MHS
OSI/MHS Configuration and Management Manual424827-003
E-8
Underspecified and Overspecified O/R Names
Underspecified Names
OSI/MHS can route underspecified messages to local recipients in the same domain.
For example, if a message is received for user Fred Bloggs (Surname Bloggs, Given
Name Fred) in the local domain, and the corresponding APPL object has been added
as Fred Bloggs Jr (Surname Bloggs, Given Name Fred, Qualifier Jr), the message is
still routed to that APPL, if it is unique. (If another APPL identifies Fred Bloggs S., the
message cannot be routed.)
This mechanism is independent of the main routing algorithm and is used only when
the main routing algorithm has failed to route a message for a particular recipient.
This scheme works by using certain components of the O/R name and checking for a
unique match in the set of local users. To determine uniqueness, the router takes a
component of the O/R name and ascertains that it occurs for only one user, while all
other fields in the message match those specified for the local user. O/R name
components are used as alternate keys for access to the User Database.
Here are the O/R name components used for matching, in order of priority:
1. common Name
2. personalName (Surname + Given Name)
3. personalName (Surname only)
4. network address
5. numeric user ID
6. domain-defined attribute 1
7. organizational unit name 1
8. organization name
The rationale for this order is that items higher on the list are more likely to have
unique matches in the database than items lower on the list.
Whenever a message has been received and cannot be routed by the main routing
logic, OSI/MHS checks whether the recipient is in the local domain. If not, a routing
failure is reported. If the message is in the domain, a check is made to find the first
O/R name component (from the list of components used for matching) that is present
in the message. If none is found, a routing failure is reported.
If a match is found, that component becomes the key for searching the database.
Whenever a record is read, all the other fields in the O/R name in the message are
compared with those in the record. If all the fields are the same, the record is
considered a match. If no records or matches are found, a routing failure is reported.
If exactly one match is found, there is a unique underspecified user to whom the
message can be routed. If more than one match is found, a routing failure is reported
because the match is not unique. The routing failure is reported as soon as the
second match is found.