rfc1801.txt

中、英文RFC文档大全打包下载完全版 .

       different MTAs).  This is described below.

   ae-attributes Attributes from the AEs entry.

   Information in the mta-attributes and ae-info is present as a
   performance optimisation, so that routing choices can be made with a
   much smaller number of directory operations.  Using this information,
   whose presence is optional, is equivalent to looking up the
   information in the MTA. If this information is present, it shall be
   maintained to be the same as that information stored in the MTA
   entry.  Despite this maintenence requirement, use of this performance
   optimisation data is optional, and the information may always be
   looked up from the MTA entry.

   Note: It has been suggested that substantial performance optimisation
         will be achieved by caching, and that the performance gained
         from maintaining these attributes does not justify the effort
         of maintaining the entries.  If this is borne out by
         operational experience, this will be reflected in future
         versions of this specification.





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


   Route weighting is a mechanism to distinguish between different route
   choices.  A routing weight may be associated with the MTA in the
   context of a routing tree entry.  This is because routing weight will
   always be context dependent.  This will allow machines which have
   other functions to be used as backup MTAs.  The Route Weight is an
   integer in range 0--20.  The lower the value, the better the choice
   of MTA. Where the weight is equal, and no other factors apply, the
   choice between the MTAs shall be random to facilitate load balancing.
   If the MTA itself is in the list, it shall only route to an MTA of
   lower weight.  The exact values will be chosen by the manager of the
   relevant part of the routing tree.  For guidance, three fixed points
   are given:

    o  0.  For an MTA which can deliver directly to the entire subtree
       implied by the position in the routing tree.

    o  5.  For an MTA which is preferred for this point in the subtree.

    o  10.  For a backup MTA.

   When an organisation registers in multiple routing trees, the route
   weight used is dependent on the context of the subtree.  In general
   it is not possible to compare weights between subtrees.  In some
   cases, use of route weighting can be used to divert traffic away from
   expensive links.

   Attributes present in an MTA Entry are defined in various parts of
   this specification.  A summary and pointers to these sections is
   given in Section 16.

   Attributes that are available in the MTA entry and will be needed for
   making a routing choice are:

   protocolInformation

   applicationContext

   mhs-deliverable-content-length

   responderAuthenticationRequirements

   initiatorAuthenticationRequirements

   responderPullingAuthenticationRequirements

   initiatorPullingAuthenticationRequirements

   initiatorP1Mode



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


   responderP1Mode

   polledMTAs Current MTA shall be in list if message is to be pulled.

   mTAsAllowedToPoll

   supportedMTSExtensions

   If any MTA attributes are present in the mTAInfo attribute, all of
   the attributes that may affect routing choice shall be present.
   Other attributes may be present.  A full list of MTA attributes, with
   summaries of their descriptions are given in Section 16, with a
   formal definition in Figure 6.

10.3  Routing Filters

   This attribute provides for routing on information in the unmatched
   part of the O/R Address, including:

    o  Routing on the basis of an O/R Address component type

    o  Routing on the basis of a substring match of an O/R address
       component.  This might be used to route X121 addressed faxes to
       an appropriate MTA.

   When present, the procedures of analysing the routing filters shall
   be followed before other actions.  The routing filter overrides
   mTAInfo and accessMD attributes, which means that the routing filter
   must be considered first.  Only in the event that no routing filters
   match shall the mTAInfo and accessMD attributes be considered.  The
   components of the routingFilter attribute are:

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

   attribute-type This gives the attribute type to be matched, and is
       selected from the attribute types which have not been matched to
       identify the routing entry.  The filter applies to this attribute
       type.  If there is no regular expression present (as defined
       below), the filter is true if the attribute is present.  The
       value is the object identifier of the X.500 attribute type
       (e.g., at-prmd-name).

   weight This gives the weight of the filter, which is encoded as a
       Route Weight, with lower values indicating higher priority.  If
       multiple filters match, the weight of each matched filter is used
       to select between them.  If the weight is the same, then a random
       choice shall be made.




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


   dda-key If the attribute is domain defined, then this parameter may
       be used to identify the key.


   accessMD ATTRIBUTE ::= {
           SUBTYPE OF distinguishedName
           ID at-access-md}

                        Figure 4:  Indirect Access

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

   regex-match This string is used to give a regular expression match on
       the attribute value.  The syntax for regular expressions is
       defined in Appendix E.

   node This distinguished name specifies the entry which holds routing
       information for the filter.  It shall be an entry with object
       class routingInformation, which can be used to determine the MTA
       or MTA choice.  All of the attributes from this entry should be
       used, as if they had been directly returned from the current entry
       (i.e., the procedure recurses).  The current entry does not set
       defaults.

   An example of use of routing filters is now given, showing how to
   route on X121 address to a fax gateway in Germany.  Consider the
   routing point.

     PRMD=ABC, ADMD=XYZMail, C=GB

   The entry associated would have two routing filters:

   1.  One with type x121 and no regular expression, to route a default
       fax gateway.

   2.  One with type x121 and a regular expression ^9262 to route all
       German faxes to a fax gateway located in Germany with which there
       is a bilateral agreement.  This would have a lower weight, so that
       it would be selected over the default fax gateway.

10.4  Indirect Connectivity

   In some cases a part of the O/R Address space will be accessed
   indirectly.  For example, an ADMD without access from the open
   community might have an agreement with another MD to provide this
   access.  This is achieved by use of the accessMD attribute defined in
   Figure 4.  If this attribute is found, the routing algorithm shall
   read the entry pointed to by this distinguished name.  It shall be an



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


   entry with object class routingInformation, which can be used to
   determine the MTA or MTA choice and route according to the
   information retrieve to this access MD. All of the attributes from
   this entry should be used, as if they had been directly returned from
   the current entry (i.e., the procedure recurses).  The current entry
   does not set defaults.

   The attribute is called an MD, as this is descriptive of its normal
   use.  It might point to a more closely defined part of the O/R
   Address space.

   It is possible for both access MD and MTAs to be specified.  This
   might be done if the MTAs only support access over a restricted set
   of transport stacks.  In this case, the access MD shall only be
   routed to if it is not possible to route to any of the MTAs.

   This structure can also be used as an optimisation, where a set of
   MTAs provides access to several parts of the O/R Address space.
   Rather than repeat the MTA information (list of MTAs) in each
   reference to the MD, a single access MD is used as a means of
   grouping the MTAs.  The value of the Distinguished Name of the access
   MD will probably not be meaningful in this case (e.g., it might be
   the name "Access MTA List", within the organisation.)

   If the MTA routing is unable to access the information in the Access
   MD due to directory security restrictions, the routing algorithm
   shall continue as if no MTA information was located in the routing
   entry.

11.  Local Addresses (UAs)

   Local addresses (UAs) are a special case for routing:  the endpoint.
   The definition of the routedUA object class is given in Figure 5.
   This identifies a User Agent in a routing tree.  This is needed for
   several reasons:

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

   routedUA OBJECT-CLASS ::= {
       SUBCLASS OF {routingInformation}
       KIND auxiliary
       MAY CONTAIN {
                           -- from X.402
           mhs-deliverable-content-length|
           mhs-deliverable-content-types|
           mhs-deliverable-eits|
           mhs-message-store|                                         10
           mhs-preferred-delivery-methods|



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


                           -- defined here
           supportedExtensions|
           redirect|
           supportingMTA|
           userName|
           nonDeliveryInfo}
       ID oc-routed-ua}

   supportedExtensions ATTRIBUTE ::= {                                20
       SUBTYPE OF objectIdentifier
       ID at-supported-extensions}

   supportingMTA ATTRIBUTE ::= {
       SUBTYPE OF mTAInfo
       ID at-supporting-mta}

   userName ATTRIBUTE ::= {
       SUBTYPE OF distinguishedName
       ID at-user-name}                                               30

                          Figure 5: UA Attributes

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

   1.  To allow UAs to be defined without having an entry in another part
       of the DIT.

   2.  To identify which (leaf and non-leaf) nodes in a routing tree are
       User Agents.  In a pure X.400 environment, a UA (as distinct from
       a connecting part of the O/R address space) is simply identified
       by object class.  Thus an organisation entry can itself be a UA. A
       UA need not be a leaf, and can thus have children in the tree.

   3.  To allow UA parameters as defined in X.402 (e.g., the
       mhs-deliverable-eits) to be determined efficiently from the
       routing tree, without having to go to the user's entry.

   4.  To provide access to other information associated with the UA, as
       defined below.

   The following attributes are defined associated with the UA.

   supportedExtensions MTS extensions supported by the MTA, which affect
       delivery.

   supportingMTA The MTAs which support a UA directly are noted in the
       supportingMTA attribute, which may be multi-valued.  In the X.400
       model, only one MTA is associated with a UA. In practice, it is



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


       possible and useful for several MTAs to be able to deliver to a
       single UA. This attribute is a subtype of mTAInfo, and it defines
       access information for an MTA which is able to deliver to the UA.
       There may also be an mTAInfo attribute in the entry.
       Comp