rfc1801.txt

RFC 的详细文档！

   ---------------------------------------------------------------------

   routingInformation OBJECT-CLASS ::= {
       SUBCLASS OF top
       KIND auxiliary
       MAY CONTAIN {
           subtreeInformation|
           routingFilter|
           routingFailureAction|
           mTAInfo|
           accessMD|                                                  10
           nonDeliveryInfo|
           badAddressSearchPoint|
           badAddressSearchAttributes}
       ID oc-routing-information}
                   -- No naming attributes as this is not a
                   -- structural object class



   subtreeInformation ATTRIBUTE ::= {                                 20
       WITH SYNTAX SubtreeInfo
       SINGLE VALUE



Kille                         Experimental                     [Page 17]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


       ID at-subtree-information}

   SubtreeInfo ::= ENUMERATED {
       all-children-present(0),
       not-all-children-present(1) }


   routingFilter ATTRIBUTE ::= {                                      30
       WITH SYNTAX RoutingFilter
       ID at-routing-filter}


   RoutingFilter ::= SEQUENCE{
           attribute-type OBJECT-IDENTIFIER,
           weight RouteWeight,
           dda-key String OPTIONAL,
           regex-match IA5String OPTIONAL,
           node DistinguishedName }                                   40

   String ::= CHOICE {PrintableString, TeletexString}

   routingFailureAction ATTRIBUTE ::= {
       WITH SYNTAX RoutingFailureAction
       SINGLE VALUE
       ID at-routing-failure-action}

   RoutingFailureAction ::= ENUMERATED {
               next-level(0),                                         50
               next-tree-only(1),
               next-tree-first(2),
               stop(3)  }


   mTAInfo ATTRIBUTE ::= {
       WITH SYNTAX MTAInfo
       ID at-mta-info}

   MTAInfo ::= SEQUENCE {                                             60
               name DistinguishedName,
               weight [1] RouteWeight DEFAULT preferred-access,
               mta-attributes [2] SET OF Attribute OPTIONAL,
               ae-info  SEQUENCE OF SEQUENCE {
                   aEQualifier PrintableString,
                   ae-weight RouteWeight DEFAULT preferred-access,
                   ae-attributes SET OF Attribute OPTIONAL} OPTIONAL
   }

   RouteWeight ::= INTEGER  {endpoint(0),                             70



Kille                         Experimental                     [Page 18]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


                   preferred-access(5),
                   backup(10)} (0..20)

                 Figure 3:  Routing Information at a Node

   ---------------------------------------------------------------------

   For example, information might be associated with the (PRMD) node:

    PRMD=ABC, ADMD=XYZMail, C=GB

   If this node was in the open community routing tree, then the
   information represents information published by the owner of the PRMD
   relating to public access to that PRMD. If this node was present in
   another routing tree, it would represent information published by the
   owner of the routing tree about access information to the referenced
   PRMD. The attributes associated with a routingInformation node
   provide the following information:

   Implicit That the node corresponds to a partial or entire valid O/R
       address.  This is implicit in the existence of the entry.

   Object Class If the node is a UA. This will be true if the node is of
       object class routedUA. This is described further in Section 11.
       If it is not of this object class, it is an intermediate node in
       the O/R Address hierarchy.

   routingFilter A set of routing filters, defined by the routingFilter
       attribute.  This attribute provides for routing on information in
       the unmatched part of the O/R Address.  This is described in
       Section 10.3.

   subtreeInformation Whether or not the node is authoritative for the
       level below is specified by the subtreeInformation attribute.  If
       it is authoritative, indicated by the value all-children-present,
       this will give the basis for (permanently) rejecting invalid O/R
       Addresses.  The attribute is encoded as enumerated, as it may be
       later possible to add partial authority (e.g., for certain
       attribute types).  If this attribute is missing, the node is
       assumed to be non-authoritative (not-all-children-present).
       The value all-children-present simply means that all of the child
       entries are present, and that this can be used to determine
       invalid addresses.  There are no implications about the presence
       of routing information.  Thus it is possible to verify an entire
       address, but only to route on one of the higher level components.

       For example, consider the node:




Kille                         Experimental                     [Page 19]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


        MHS-O=Zydeco, PRMD=ABC, ADMD=XYZMail, C=GB

       An organisation which has a bilateral agreement with this
       organisation has this entry in its routing tree, with no children
       entries.  This is marked as non-authoritative.  There is a second
       routing tree maintained by Zydeco, which contains all of the
       children of this node, and is marked as authoritative.  When
       considering an O/R Address

        MHS-G=Random + MHS-S=Unknown, MHS-O=Zydeco,
        PRMD=ABC, ADMD=XYZMail, C=GB

       only the second, authoritative, routing tree can be used to
       determine that this address is invalid.  In practice, the manager
       configuring the non-authoritative tree, will be able to select
       whether an MTA using this tree will proceed to full verification,
       or route based on the partially verified information.

   mTAInfo A list of MTAs and associated information defined by the
       mTAInfo attribute.  This information is discussed further in
       Sections 15 and 18.  This information is the key information
       associated with the node.  When a node is matched in a lookup, it
       indicates the validity of the route, and a set of MTAs to connect
       to.  Selection of MTAs is discussed in Sections 18 and
       Section 10.2.

   routingFailureAction An action to be taken if none of the MTAs can be
       used directly (or if there are no MTAs present) is defined by the
       routingFailureAction attribute.  Use of this attribute and
       multiple routing trees is described in Section 10.1.

   accessMD The accessMD attribute is discussed in Section 10.4.  This
       attribute is used to indicate MDs which provide indirect access
       to the part of the tree that is being routed to.

   badAddressSearchPoint/badAddressSearchAttributes The
       badAddressSearchPoint and badAddressSearchAttributes are
       discussed in Section 17.  This attribute is for when an address
       has been rejected, and allows information on alternative addresses
       to be found.

10.1  Multiple routing trees

   A routing decision will usually be made on the basis of information
   contained within multiple routing trees.  This section describes the
   algorithms relating to use of multiple routing trees.  Issues
   relating to the use of X.500 and handling of errors is discussed in
   Section 14.  The routing decision works by examining a series of



Kille                         Experimental                     [Page 20]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


   entries (nodes) in one or more routing trees.  This information is
   summarised in Figure 3.  Each entry may contain information on
   possible next-hop MTAs.  When an entry is found which enables the
   message to be routed, one of the routing options determined at this
   point is selected, and a routing decision is made.  It is possible
   that further entries may be examined, in order to determine other
   routing options.  This sort of heuristic is not discussed here.

   When a single routing tree is used, the longest possible match based
   on the O/R address to be routed to is found.  This entry, and then
   each of its parents in turn is considered, ending with the routing
   tree root node (except in the case of the open routing tree, which
   does not have such a node).  When multiple routing trees are
   considered, the basic approach is to treat them in a defined order.
   This is supplemented by a mechanism whereby if a matched node cannot
   be used directly, the routing algorithm will have the choice to move
   up a level in the current routing tree, or to move on to the next
   routing tree with an option to move back to the first tree later.
   This option to move back is to allow for the common case where a tree
   is used to specify two things:

   1.  Routing information private to the MTA (e.g., local UAs or routing
       info for bilateral links).

   2.  Default routing information for the case where other routing has
       failed.

   The actions allow for a tree to be followed, for the private
   information, then for other trees to be used, and finally to fall
   back to the default situation.  For very complex configurations it
   might be necessary to split this into two trees.  The options defined
   by routingFailureAction, to be used when the information in the entry
   does not enable a direct route, are:

   next-level Move up a level in the current routing tree.  This is the
       action implied if the attribute is omitted.  This will usually be
       the best action in the open community routing tree.

   next-tree-only Move to the next tree, and do no further processing on
       the current tree.  This will be useful optimisation for a routing
       tree where it is known that there is no useful additional routing
       information higher in the routing tree.

   next-tree-first Move to the next tree, and then default back to the
       next level in this tree when all processing is completed on
       subsequent trees.  This will be useful for an MTA to operate in
       the sequence:




Kille                         Experimental                     [Page 21]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


       1.  Check for optimised private routes

       2.  Try other available information

       3.  Fall back to a local default route

   stop This address is unroutable.  No processing shall be done in any
       trees.

   For the root entry of a routing tree, the default action and next-
   level are interpreted as next-tree-only.

10.2  MTA Choice

   This section considers how the choice between alternate MTAs is made.
   First, it is useful to consider the conditions why an MTA is entered
   into a node of the routing tree:

    o  The manager for the node of the tree shall place it there.  This
       is a formality, but critical in terms of overall authority.

    o  The MTA manager shall agree to it being placed there.  For a well
       operated MTA, the access policy of the MTA will be set to enforce
       this.

    o  The MTA will in general (for some class of message) be prepared
       to route to any valid O/R address in the subtree implied by the
       address.  The only exception to this is where the MTA will route
       to a subset of the tree which cannot easily be expressed by
       making entries at the level below.  An example might be an MTA
       prepared to route to all of the subtree, with certain explicit
       exceptions.

   Information on each MTA is stored in an mTAInfo attribute, which is
   defined in Figure 3.  This attribute contains:

   name The Distinguished Name of the MTA (Application Process)

   weight A weighting factor (Route Weight) which gives a basis to
       choose between different MTAs.  This is described in Section 10.2.

   mta-attributes Attributes from the MTA's entry.  Information on the
       MTA will always be stored in the MTA's entry.  The MTA is
       represented here as a structure, which enables some of this entry
       information to be represented in the routing node.  This is
       effectively a maintained cache, and can lead to considerable
       performance optimisation.  For example if ten MTAs were
       represented at a node, another MTA making a routing decision might



Kille                         Experimental                     [Page 22]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995