21.  Policy and Authorisation

21.1  Simple MTA Policy

   The routing trees will generally be configured in order to identify
   MTAs which will route to the destination.  A simple means is
   identified to specify an MTA's policy.  This is defined in Figure 14.
   If this attribute is omitted, the MTA shall route all traffic to the
   implied destinations from the context of the routing tree for any
   MTAs that have valid access to the routing tree.

   The multi-valued attribute gives a set of policies which the MTA will
   route.  O/R Addresses are represented by a prefix, which identifies a
   subtree.  A distinguished name encoding of O/R Address is used.
   There are three components:

   from This gives a set of O/R addresses which are granted permission
       by this attribute value.  If omitted, "all" is implied.

   to This gives the set of acceptable destinations.  If omitted,
       "all" is implied.

   from-excludes This defines (by prefix) subtrees of the O/R address
       tree which are explicitly excluded from the "from" definition.
       If omitted, there are no exclusions.

   to-excludes This defines (by prefix) subtrees of the O/R address tree
       which are explicitly excluded from the "to" definition.  If
       omitted, there are no exclusions.

   This simple policy will suffice for most cases.  In particular, it
   gives sufficient information for most real situations where a policy
   choice is forced, and the application of this policy would prevent a
   message being routed.

   This simple prefixing approach does not deal explicitly with alias
   dereferencing.  The prefixes refer to O/R addresses where aliases
   have been dereferenced.  To match against these prefixes, O/R
   addresses being matched need to be "normalised by being looked up in
   the directory to resolve alias values.  If the lookup fails, it shall
   be assumed that the provided address is already normalised.  This
   means that policy may be misinterpreted for parts of the DIT not
   referenced in the directory.

   The originator refers to the MTS originator, and the recipient to the
   MTS recipient, following any list expansion or redirect.  This simple
   policy does not apply to delivery reports.  Any advertised route
   shall work for delivery reports, and it does not makes sense to
   regulate this on the basis of the sender.

21.2  Complex MTA Policy

   MTAs will generally have a much more complex policy mechanism, such
   as that provided by PP MTA [10].  Representing this as a part of the
   routing decision is not done here, but may be addressed in future
   versions.  Some of the issues which need to be tackled are:

    o  Use of charging and non-charging nets

    o  Policy dependent on message size

    o  Different policy for delivery reports.

    o  Policy dependent on attributes of the originator or
       recipient (e.g., mail from students)

    o  Content type and encoded information types

    o  The path which the message has traversed to reach the MTA

    o  MTA bilateral agreements

    o  Pulling messages

    o  Costs.  This sort of policy information may also be for
       information only.

   MTAs may apply more complex routing policies.  However, this shall
   not lead to the rejection of messages which might otherwise be
   correctly routed on the published policy information.  Policies
   relating to submission do not need to be public.  They can be private
   to the MTA.

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

   redirect ATTRIBUTE ::= {
           WITH SYNTAX Redirect
           SINGLE VALUE
           ID at-redirect}

   Redirect ::= SEQUENCE OF SEQUENCE {
           or-name ORName,
           reason RedirectionReason, -- from X.411
           filter CHOICE {                                            10
                   min-size [1] INTEGER,
                   max-size [2] INTEGER,
                   content [3] ContentType,
                   eit [4] ExternalEncodedInformationType } OPTIONAL
           }

                      Figure 15:  Redirect Definition

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

22.  Delivery

22.1  Redirects

   There is a need to specify redirects in the Directory.  This will be
   useful for alternate names where an equivalent name (synonym) defined
   by an alias is not natural.  An example where this might be
   appropriate is to redirect mail to a new O/R address where a user had
   changed organisation.  A mechanism is given to allow conditional
   (filtered) redirects for different types of messages.  This allow
   small messages, large messages, or messages containing specific EITs
   or content to be redirected.  The definitions are given in Figure 15.

   Redirection is specified by the redirect attribute.  If present, this
   attribute shall be processed before supportingMTA and
   nonDeliveryInfo.  These two attributes shall only be considered if it
   is determined that no redirection applies.  The redirect attribute is
   a sequence of elements which are considered in the order specified.
   Each element is examined in turn.  The first element which applies is
   used, and no further elements are examined.  Use of an element for
   redirection, shall follow the X.400 procedures for redirection, and
   an element shall not be used if prevented by a service control.  If
   the redirect attribute is processed and no redirection is generated,
   processing shall continue irrespective of service controls.  If non-
   delivery is intended in this event, this shall be achieved by use of
   the nonDeliveryInfo attribute.

   The components have the following interpretations:

   or-name This X.400 O/R Name is for use in the redirection.  This O/R
       Name will contain an optional directory name and optional O/R
       address.  One or both of the must be present.  If the O/R Address
       element is present, the Directory Name, if present, is for
       information only.  and is to be placed in the X.400 redirection.
       If the O/R address element is absent, the Directory Name shall be
       present and shall be looked up to determine the O/R address of the
       redirected recipient.  The O/R Address of the intended recipient
       will either be present or derived by lookup.  Routing shall be
       done on the basis of this O/R Address.

   reason This is the reason information to be placed in the X.400
       redirect, and it shall take one of the following values of
       RedirectReason defined in X.411:

       recipient-assigned-alternate-recipient;
       recipient-MD-assigned-alternate-recipient; or alias.  It shall not
       have the value originator-requested-alternate-recipient.

   filter If filter is absent, the redirect is mandoatory and shall be
       followed.  If the filter is present, use of the redirect under
       consideration depends on the type of filter as follows:

       min-size Follow redirect if the message (MT content) is larger
           than min-size (measured in kBytes).

       max-size Follow redirect if the message (MT content) is smaller
           than max-size (measured in kBytes).

       content Follow redirect if message content is of type content.

       eit Follow redirect if the encoded information types registered
           in the envelope contain eit.

   When a delivery report is sent to an address which would be
   redirected, X.400 would ignore the redirect.  This means that every
   O/R address would need to have a valid means of delivery.  This would
   seem to be awkward to manage.  Therefore, the redirect shall be
   followed, and the delivery report delivered to the redirected
   address.

   These redirects are handled directly by the MTA. Redirects can also
   be initiated by the UA, for example in the context of a P7
   interaction.

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

   nonDeliveryInfo ATTRIBUTE ::= {
           WITH SYNTAX NonDeliveryReason
           SINGLE VALUE
           ID at-non-delivery-info}

   NonDeliveryReason ::= SEQUENCE {
           reason INTEGER (0..ub-reason-codes),
           diagnostic INTEGER (0..ub-diagnostic-codes) OPTIONAL,
           supplementaryInfo PrintableString OPTIONAL }               10

                   Figure 16:  Non Delivery Information

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

22.2  Underspecified O/R Addresses

   X.400 requires that some underspecified O/R Addresses are handled in
   a given way (e.g., if a surname is given without initials or given
   name).  Where an underspecified O/R Address is to be treated as if it
   were another O/R Address, an alias shall be used.  If the O/R Address

   is to be rejected as ambiguous, an entry shall be created in the DIT,
   and forced non-delivery specified for this reason.

   Note: It is also possible to handle this situation by searching.  An
         MTA conforming to this specification may handle underspecified
         addresses in this manner.  The choice of mechanism will be
         reviewed after operational experience with both approaches.

22.3  Non Delivery

   It is possible for a manager to define an address to non-deliver with
   specified reason and diagnostic codes.  This might be used for a
   range of management purposes.  The attribute to do this is defined in
   Figure 16.  If a nonDeliveryInfo attribute is present, any
   supportingMTA attribute shall be ignored and the message non-
   delivered.

22.4  Bad Addresses

   If there is a bad address, it is desirable to do a directory search
   to find alternatives.  This is a helpful user service and may be
   supported.  This function is invoked after address checking has
   failed, and where this is no user supplied alternate recipient.  This
   function would be an MTA-chosen alternative to administratively
   assigned alternate recipient.

   Attributes to support handling of bad addresses are defined in Figure
   17.  The attributes are:

   badAddressSearchPoint This gives the point (or list of points) from
       which to search.

   badAddressSearchAttributes This gives the set of attribute types to
       search on.  The default is common name.

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

   badAddressSearchPoint ATTRIBUTE ::= {
           SUBTYPE OF distinguishedName
           ID at-bad-address-search-point}

   badAddressSearchAttributes ATTRIBUTE ::= {
           WITH SYNTAX AttributeType
           ID at-bad-address-search-attributes}

   alternativeAddressInformation EXTENSION                            10
           AlternativeAddressInformation
           ::= id-alternative-address-information
                   -- X.400(92) continues to use MACRO notation

   AlternativeAddressInformation ::= SET OF SEQUENCE {
           distinguished-name DistinguishedName OPTIONAL,
           or-address ORAddress OPTIONAL,
           other-useful-info SET OF Attribute }

                     Figure 17:  Bad Address Pointers

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

   Searches are always single level, and always use approximate match.
   If a small number of matches are made, this is returned to the
   originator by use of the per recipient AlternativeAddressInformation
   in the delivery report (DR). This shall be marked non-critical, so
   that it will not cause the DR to be discarded (e.g., in downgrading
   to X.400(1984)).  This attribute allows the Distinguished Name and
   O/R Address of possible alternate recipients to be returned with the
   delivery report.  There is also the possibility to attach extra
   information in the form of directory attributes.  Typically this
   might be used to return attributes of the entry which were matched in
   the search.  A summary of the information shall also be returned
   using the delivery report supplementary information filed (e.g.,
   "your message could not be delivered to smith, try J. Smith or P.
   Smith"), so that the information is available to user agents not
   supporting this extension.  Note the length restriction of this field
   is 256 (ub-supplementary-info-length) in X.400(1988).

   If the directory search fails, or there are no matches returned, a
   delivery report shall be returned as if this extra check had not been
   made.

   Note: It might be useful to allow control of search type, and also
         single level vs subtree.  This issue is for further study.

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

   localAccessUnit ATTRIBUTE ::= {
           WITH SYNTAX AccessUnitType
           ID at-local-access-unit}

   AccessUnitType ::= ENUMERATED {
           fax (1),
           physical-delivery (2),
           teletex (3),
           telex (4) }                                                10

   accessUnitsUsed ATTRIBUTE ::= {
           WITH SYNTAX SelectedAccessUnit
           ID at-access-units-used}

   SelectedAccessUnit ::= SEQUENCE {
           type AccessUnitType,
           providing-MTA DistinguishedName,
           filter SET OF ORAddress OPTIONAL }

                     Figure 18:  Access UnitAttributes

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

23.  Submission

   A message may be submitted with Distinguished Name only.  If the MTA
   to which the message is submitted supports this service, this section
   describes how the mapping is done.

23.1  Normal Derivation

   The Distinguished Name is looked up to find the attribute mhs-or-
   addresses.  If the attribute is single value, it is straightforward.
   If there are multiple values, one O/R address shall be selected at
   random.

23.2  Roles and Groups

   Some support for roles is given.  If there is no O/R address, and the
   entry is of object class role, then the roleOccupant attribute shall
   be dereferenced, and the message submitted to each of the role
   occupants.  Similarly, if the entry is of object class group, where
   the groupMember attribute is used.

24.  Access Units

   Attributes needed for support of Access Units, as defined in
   X.400(88), are defined in Figure 18.  The attributes defined are:

   localAccessUnit This defines the list of access units supported by
       the MTA.

   accessUnitsUsed This defines which access units are used by the MTA,
       giving the type and MTA. An O/R Address filter is provided to
       control which access unit is used for a given recipient.  For a
       filter to match an address, all attributes specificed in the
       filter shall match the given address.  This is specified as an O/R
       Address, so that routing to access units can be filtered on the
       basis of attributes not mapped onto the directory (e.g., postal
       attributes).  Where a remote MTA is used, it may be necessary to
       use source routing.

   Note 1: This mechanism might be used to replace the routefilter
       mechanism of the MTS routing.  Comments are solicited.

   Note 2: It has been proposed to add a more powerful filter mechanism.
       Comments are solicited.

   Note 3: The utility of this specification as a mechanism to route
       faxes and other non MHS messages has been noted, but not explored.
       Comments as to how and if this should be developed are solicited.

   These three issues are for further study.

25.  The Overall Routing Algorithm

   Having provided all the pieces, a summary of how routing works can be
   given.

   The core of the X.400 routing is described in Section 10.  A sequence
   of routing trees are followed.  As nodes of the routing tree are
   matched, a set of MTAs will be identified for evaluation as possible
   next hops.  If all of these are rejected, the trees are followed
   further.  (It might be argued that the trees should be followed to
   find alternate routes in the case that only one MTA is acceptable.
   This is not proposed.)  A set of MTAs is evaluated on the following
   criteria:

    o  If an MTA is the local MTA, deliver locally.

    o  Supported protocols.  The MTA shall support a protocol that the
       current MTA supports, as described in Section 18.2.

       (Note that this could be an RFC 822 protocol, as well as an
       X.400 protocol.)

    o  The protocols shall share a common transport community, as
       described in Section 18.1.

    o  There shall be no capability restrictions in the MTA which
       prevents transfer of the current message, as described in
       Section 18.3.

    o  There shall be no policy restrictions in the MTA which prevents
       transfer of the current message, as described in Section 21.

    o  The authentication requirements of the MTA shall be met by the
       local MTA, as described in Section 20.2.

    o  If the authentication (Section 20.2) indicates that a bilateral
       agreement is present, the MTA shall be listed in the local set of
       bilateral agreements, as described in Section 17.

    o  In cases where the recipient UA's capabilities can be determined,
       there should either be no mismatch, or there shall be an ability
       to use local or remote reformatting capabilities, as described
       in [12].

26.  Performance

   The routing algorithm has been designed with performance in mind.  In
   particular, care has been taken to use only the read function, which
   will in general be optimised.  Routing trees may be configured so
   that routing decisions can be made with only two directory reads.
   More complex configurations will not require a substantially larger
   number of operations.

27.  Acknowledgements

   This memo is the central document of a series of specifications [14,
   15, 16], and to other work in progress.  The acknowledgements for all
   of this work is given here.  Previous work, which significantly
   influenced these specifications is described in Section 3.  This lead
   to an initial proposal by the editor, which was subsequently split
   into eight documents.  Work on this specifications has been done by
   the IETF MHS-DS working group.  Special credit is given to the joint
   chairs of this group: Harald Alvestrand (Uninett) and Kevin Jordan
   (CDC). Credit is given to all members of the WG. Those who have made
   active contribution include:  Piete Brooks (Cambridge University);
   Allan Cargille (University of Wisconsin); Jim Craigie (JNT); Dennis
   Doyle (SSS); Urs Eppenberger (SWITCH); Peter Furniss; Christian

   Huitema (Inria); Marko Kaittola (Dante); Sylvain Langlois (EDF); Lucy
   Loftin (AT&T GIS); Julian Onions (NEXOR); Paul-Andre Pays (Inria);
   Colin Robbins (NEXOR); Michael Roe (Cambridge University); Jim
   Romaguera (Netconsult); Michael Storz (Leibniz Rechenzentrum); Mark
   Wahl (ISODE Consortium); Alan Young (ISODE Consortium).

   This work was partly funded by the COSINE Paradise project.

28.  References

    [1] The Directory --- overview of concepts, models and services,
        1993. CCITT X.500 Series Recommendations.

    [2] J.N. Chiappa. A new IP routing and addressing architecture,
        1991.

    [3] A. Consael, M. Tschicholz, O. Wenzel, K. Bonacker, and M. Busch.
        DFN-Directory nutzung durch MHS, April 1990. GMD Report.

    [4] P. Dick-Lauder, R.J. Kummerfeld, and K.R. Elz. ACSNet - the
        Australian alternative to UUCP. In EUUG Conference, Paris, pages
        60--69, April 1985.

    [5] Eppenberger, U., "Routing Coordination for X.400 MHS Services
        Within a Multi Protocol / Multi Network Environment Table Format
        V3 for Static Routing", RFC 1465, SWITCH, May 1993.

    [6] K.E. Jordan. Using X.500 directory services in support of X.400
        routing and address mapping, November 1991. Private Note.

    [7] S.E. Kille. MHS use of directory service for routing.  In IFIP
        6.5 Conference on Message Handling, Munich, pages 157--164.
        North Holland Publishing, April 1987.

    [8] S.E. Kille. Topology and routing for MHS.  COSINE Specification
        Phase 7.7, RARE, 1988.

    [9] Kille, S., "Encoding Network Addresses to support operation over
        non-OSI lower layers", RFC 1277, Department of Computer Science,
        University College London, November 1991.

   [10] S.E. Kille. Implementing X.400 and X.500:  The PP and QUIPU
        Systems. Artech House, 1991.  ISBN 0-89006-564-0.

   [11] Kille, S., "A Representation of Distinguished Names
        (OSI-DS 23 (v5))", RFC 1485, Department of Computer Science,
        University College London, January 1992.

   [12] Kille, S., Mhs use of X.500 directory to support mhs content
        conversion, Work in Progress, July 1993.

   [13] Kille, S., "Use of the X.500 directory to support routing for
        RFC 822 and related protocols", Work in Progress, July 1993.

   [14] Kille, S., "Representing tables and subtrees in the X.500
        directory", Work in Progress, September 1994.

   [15] Kille, S., "Representing the O/R Address hierarchy in the X.500
        directory information tree", Work in Progress, September 1994.

   [16] Kille, S., "Use of the X.500 directory to support mapping
        between X.400 and RFC 822 addresses", Work in Progress,
        September 1994.

   [17] Lauder, P., Kummerfeld, R., and A. Fekete. Hierarchical network
        routing. In Tricomm 91, 1991.

   [18] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
        SG 5/VII / ISO/IEC JTC1, Message Handling:  System and Service
        Overview.

   [19] Zen and the ART of navigating through the dark and murky regions
        of the message transfer system:  Working document on MTS
        routing, September 1991. ISO SC 18 SWG Messaging.

29.  Security Considerations

   Security issues are not discussed in this memo.

30.  Author's Address

   Steve Kille
   ISODE Consortium
   The Dome
   The Square
   Richmond
   TW9 1DT
   England

   Phone:  +44-81-332-9091
   EMail:  S.Kille@ISODE.COM
   X.400:  I=S; S=Kille; O=ISODE Consortium; P=ISODE;
   A=Mailnet; C=FI;

   DN: CN=Steve Kille,
   O=ISODE Consortium, C=GB

   UFN: S. Kille, ISODE Consortium, GB

A  Object Identifier Assignment

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

mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}

routing OBJECT IDENTIFIER ::= {mhs-ds 3}

oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}

                                                                    10
oc-mta OBJECT IDENTIFIER ::= {oc 1}
oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2}
oc-routing-information OBJECT IDENTIFIER ::= {oc 3}
oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4}
oc-routed-ua OBJECT IDENTIFIER ::= {oc 8}
oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6}
oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7}

at-access-md OBJECT IDENTIFIER ::= {at 1}
at-access-units-used OBJECT IDENTIFIER ::= {at 2}                   20
at-subtree-information OBJECT IDENTIFIER ::= {at 3}
at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4}
at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5}

at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7}


at-global-domain-id OBJECT IDENTIFIER ::= {at 10}
at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11}
at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}30
at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13}
at-initiator-pulling-authentication-requirements
                                           OBJECT IDENTIFIER ::= {at 14}
at-local-access-unit OBJECT IDENTIFIER ::= {at 15}
at-redirect OBJECT IDENTIFIER ::= {at 46}
at-mta-info OBJECT IDENTIFIER ::= {at 40}
at-mta-name OBJECT IDENTIFIER ::= {at 19}

at-mta-will-route OBJECT IDENTIFIER ::= {at 21}
at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22}
at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}40
at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24}
at-responder-pulling-authentication-requirements
                                           OBJECT IDENTIFIER ::= {at 25}

at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26}
at-routing-failure-action OBJECT IDENTIFIER ::= {at 27}
at-routing-filter OBJECT IDENTIFIER ::= {at 28}
at-routing-tree-list OBJECT IDENTIFIER ::= {at 29}
at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30}
at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31}
at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32}
at-supporting-mta OBJECT IDENTIFIER ::= {at 33}                     50
at-transport-community OBJECT IDENTIFIER ::= {at 34}
at-user-name OBJECT IDENTIFIER ::= {at 35}
at-non-delivery-info OBJECT IDENTIFIER ::= {at 47}
at-polled-mtas  OBJECT IDENTIFIER ::= {at 37}
at-bilateral-table OBJECT IDENTIFIER {at 45}
at-supported-extension OBJECT IDENTIFIER {at 42}
at-supported-mts-extension OBJECT IDENTIFIER {at 43}
at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44}

id-alternative-address-information OBJECT IDENTIFIER ::= {id 1}     60

                Figure 19:  Object Identifier Assignment

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

B  Community Identifier Assignments

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

ts-communities OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) ts-communities (4)}


tc-cons OBJECT IDENTIFIER ::= {ts-communities 1}    -- OSI CONS
tc-clns OBJECT IDENTIFIER ::= {ts-communities 2}    -- OSI CLNS
tc-internet OBJECT IDENTIFIER ::= {ts-communities 3}-- Internet+RFC1006
tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25
                                                    -- Without CONS10
tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5}     -- IXI (Europe)
tc-janet OBJECT IDENTIFIER ::= {ts-communities 6}   -- Janet (UK)

     Figure 20:  Transport Community Object Identifier Assignments

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

C  Protocol Identifier Assignments

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

mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4)n enterprises(1) isode-consortium (453) mail-protocol (5)}

ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1}      -- p1(1984)
ac-smtp  OBJECT IDENTIFIER ::= {mail-protocol 2}        -- SMTP
ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3}         -- UUCP Mail
ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4}     -- JNT Mail
(UK)
ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5} -- p1(1988) in
X.410 mode
ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6}      -- p3(1984) 10

           Figure 21:  Protocol Object Identifier Assignments

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

D  ASN.1 Summary

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

MHS-DS-Definitions
DEFINITIONS ::=
BEGIN

 -- assign OID to module
 -- define imports and exports

routingTreeRoot OBJECT-CLASS ::= {
    SUBCLASS OF {routingInformation|subtree}
    ID oc-routing-tree-root}                                        10

routingTreeList ATTRIBUTE ::= {
        WITH SYNTAX RoutingTreeList
        SINGLE VALUE
        ID at-routing-tree-list}

RoutingTreeList ::= SEQUENCE OF RoutingTreeName

RoutingTreeName ::= DistinguishedName
                                                                    20
routingInformation OBJECT-CLASS ::= {
    SUBCLASS OF top
    KIND auxiliary
    MAY CONTAIN {

        subtreeInformation|
        routingFilter|
        routingFailureAction|
        mTAInfo|
        accessMD|
        nonDeliveryInfo|                                            30
        badAddressSearchPoint|
        badAddressSearchAttributes}
    ID oc-routing-information}
                -- No naming attributes as this is not a
                -- structural object class



subtreeInformation ATTRIBUTE ::= {
    WITH SYNTAX SubtreeInfo                                         40
    SINGLE VALUE
    ID at-subtree-information}

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


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


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

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

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

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

MTAInfo ::= SEQUENCE {
            name DistinguishedName,                                 80
            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),
                preferred-access(5),                                90
                backup(10)} (0..20)

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

routedUA OBJECT-CLASS ::= {
    SUBCLASS OF {routingInformation}
    KIND auxiliary
    MAY CONTAIN {                                                  100
                        -- from X.402
        mhs-deliverable-content-length|
        mhs-deliverable-content-types|
        mhs-deliverable-eits|
        mhs-message-store|
        mhs-preferred-delivery-methods|
                        -- defined here
        supportedExtensions|
        redirect|
        supportingMTA|                                             110
        userName|
        nonDeliveryInfo}
    ID oc-routed-ua}

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

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

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

mTAName ATTRIBUTE ::= {
    SUBTYPE OF name
    WITH SYNTAX DirectoryString{ub-mta-name-length}
    SINGLE VALUE                                                   130
    ID at-mta-name}
                        -- used for naming when
                        -- MTA is named in O=R Address Hierarchy

globalDomainID ATTRIBUTE ::= {
    WITH SYNTAX GlobalDomainIdentifier
    SINGLE VALUE
    ID at-global-domain-id}
                        -- both attributes present when MTA
                        -- is named outside O=R Address Hierarchy  140
                        -- to enable trace to be written

mTAApplicationProcess OBJECT-CLASS ::= {
    SUBCLASS OF {application-process}
    KIND auxiliary
    MAY CONTAIN {
        mTAWillRoute|
        globalDomainID|
        routingTreeList|
        localAccessUnit|                                           150
        accessUnitsUsed
    }
    ID oc-mta-application-process}

mTA OBJECT CLASS ::= {   -- Application Entity
    SUBCLASS OF {mhs-message-transfer-agent}
    KIND structural
    MAY CONTAIN {
        mTAName|
        globalDomainID|         -- per AE variant                  160
        responderAuthenticationRequirements|
        initiatorAuthenticationRequirements|
        responderPullingAuthenticationRequirements|
        initiatorPullingAuthenticationRequirements|
        initiatorP1Mode|
        responderP1Mode|
        polledMTAs|
        protocolInformation|
        respondingRTSCredentials|
        initiatingRTSCredentials|                                  170

        callingPresentationAddress|
        callingSelectorValidity|
        bilateralTable|
        mTAWillRoute|
        mhs-deliverable-content-length|
        routingTreeList|
        supportedMTSExtensions|
        mTAsAllowedToPoll
        }
    ID oc-mta}                                                     180

mTABilateralTableEntry OBJECT-CLASS ::=
    SUBCLASS OF {mTA| distinguishedNameTableEntry}
    ID oc-mta-bilateral-table-entry}

bilateralTable ATTRIBUTE ::= {
        WITH SYNTAX SEQUENCE OF DistinguishedName
        SINGLE VALUE
        ID at-bilateral-table}
                                                                   190
supportedMTSExtensions ATTRIBUTE ::= {
    SUBTYPE OF objectIdentifier
    ID at-supported-mts-extensions}

restrictedSubtree OBJECT-CLASS ::= {
        SUBCLASS OF {top}
        KIND auxiliary
        MAY CONTAIN {
                subtreeDeliverableContentLength|
                subtreeDeliverableContentTypes|                    200
                subtreeDeliverableEITs}
        ID oc-restricted-subtree}

subtreeDeliverableContentLength ATTRIBUTE ::= {
        SUBTYPE OF mhs-deliverable-content-length
        ID at-subtree-deliverable-content-length}

subtreeDeliverableContentTypes ATTRIBUTE ::= {
        SUBTYPE OF mhs-deliverable-content-types
        ID at-subtree-deliverable-content-types}                   210

subtreeDeliverableEITs ATTRIBUTE ::= {
        SUBTYPE OF mhs-deliverable-eits
        ID at-subtree-deliverable-eits}


initiatorP1Mode ATTRIBUTE ::= {
    WITH SYNTAX P1Mode

    SINGLE VALUE
    ID at-initiator-p1-mode}                                       220

responderP1Mode ATTRIBUTE ::= {
    WITH SYNTAX P1Mode
    SINGLE VALUE
    ID at-responder-p1-mode}

P1Mode ::= ENUMERATED {
    push-only(0),
    pull-only(1),
    twa(2) }                                                       230

polledMTAs ATTRIBUTE ::= {
    WITH SYNTAX PolledMTAs
    ID at-polled-mtas}

PolledMTAs ::= SEQUENCE {
        mta DistinguishedName,
        poll-frequency INTEGER OPTIONAL --frequency in minutes
        }
                                                                   240
mTAsAllowedToPoll ATTRIBUTE ::= {
        SUBTYPE OF distinguishedName
        ID at-mtas-allowed-to-poll}


responderAuthenticationRequirements ATTRIBUTE ::= {
   WITH SYNTAX AuthenticationRequirements
   SINGLE VALUE
   ID at-responder-authentication-requirements}
                                                                   250
initiatorAuthenticationRequirements ATTRIBUTE ::= {
   WITH SYNTAX AuthenticationRequirements
   SINGLE VALUE
   ID at-initiator-authentication-requirements}

responderPullingAuthenticationRequirements ATTRIBUTE ::= {
   WITH SYNTAX AuthenticationRequirements
   SINGLE VALUE
   ID at-responder-pulling-authentication-requirements}
                                                                   260
initiatorPullingAuthenticationRequirements ATTRIBUTE ::= {
   WITH SYNTAX AuthenticationRequirements
   SINGLE VALUE
   ID at-initiator-pulling-authentication-requirements}

AuthenticationRequirements ::= BITSTRING {

    mta-name-present(0),
    aet-present(1),
    aet-valid(2),
    network-address(3),                                            270
    simple-authentication(4),
    strong-authentication(5),
    bilateral-agreement-needed(6)}

respondingRTSCredentials ATTRIBUTE ::= {
        WITH SYNTAX RTSCredentials
        SINGLE VALUE
        ID at-responding-rts-credentials}

                                                                   280
initiatingRTSCredentials ATTRIBUTE ::= {
        WITH SYNTAX RTSCredentials
        SINGLE VALUE
        ID at-initiating-rts-credentials}


RTSCredentials ::= SEQUENCE {
        request [0] MTAandPassword OPTIONAL,
        response [1] MTAandPassword OPTIONAL }
                                                                   290

MTAandPassword ::= SEQUENCE {
        MTAName,
        Password }              -- MTAName and Password
                                -- from X.411


callingPresentationAddress ATTRIBUTE ::= {
        SUBTYPE OF presentationAddress
        MULTI VALUE                                                300
        ID at-calling-presentation-address}

callingSelectorValidity ATTRIBUTE ::= {
        WITH SYNTAX CallingSelectorValidity
        SINGLE VALUE
        ID at-calling-selector-validity}

CallingSelectorValidity ::= ENUMERATED {
        all-selectors-fixed(0),
        tsel-may-vary(1),                                          310
        all-selectors-may-vary(2) }

mTAWillRoute ATTRIBUTE ::= {
    WITH SYNTAX MTAWillRoute

    ID at-mta-will-route}

MTAWillRoute ::= SEQUENCE {
        from [0]        SET OF ORAddressPrefix OPTIONAL,
        to [1]          SET OF ORAddressPrefix OPTIONAL,
        from-excludes [2]       SET OF ORAddressPrefix OPTIONAL,   320
        to-excludes [3]         SET OF ORAddressPrefix OPTIONAL }

ORAddressPrefix ::= DistinguishedName

redirect ATTRIBUTE ::= {
        WITH SYNTAX Redirect
        SINGLE VALUE
        ID at-redirect}

Redirect ::= SEQUENCE OF SEQUENCE {                                330
        or-name ORName,
        reason RedirectionReason, -- from X.411
        filter CHOICE {
                min-size [1] INTEGER,
                max-size [2] INTEGER,
                content [3] ContentType,
                eit [4] ExternalEncodedInformationType } OPTIONAL
        }

nonDeliveryInfo ATTRIBUTE ::= {                                    340
        WITH SYNTAX NonDeliveryReason
        SINGLE VALUE
        ID at-non-delivery-info}

NonDeliveryReason ::= SEQUENCE {
        reason INTEGER (0..ub-reason-codes),
        diagnostic INTEGER (0..ub-diagnostic-codes) OPTIONAL,
        supplementaryInfo PrintableString OPTIONAL }

badAddressSearchPoint ATTRIBUTE ::= {                              350
        SUBTYPE OF distinguishedName
        ID at-bad-address-search-point}

badAddressSearchAttributes ATTRIBUTE ::= {
        WITH SYNTAX AttributeType
        ID at-bad-address-search-attributes}

alternativeAddressInformation EXTENSION
        AlternativeAddressInformation
        ::= id-alternative-address-information                     360
                -- X.400(92) continues to use MACRO notation

AlternativeAddressInformation ::= SET OF SEQUENCE {
        distinguished-name DistinguishedName OPTIONAL,
        or-address ORAddress OPTIONAL,
        other-useful-info SET OF Attribute }

localAccessUnit ATTRIBUTE ::= {
        WITH SYNTAX AccessUnitType
        ID at-local-access-unit}                                   370

AccessUnitType ::= ENUMERATED {
        fax (1),
        physical-delivery (2),
        teletex (3),
        telex (4) }

accessUnitsUsed ATTRIBUTE ::= {
        WITH SYNTAX SelectedAccessUnit
        ID at-access-units-used}                                   380

SelectedAccessUnit ::= SEQUENCE {
        type AccessUnitType,
        providing-MTA DistinguishedName,
        filter SET OF ORAddress OPTIONAL }
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
          enterprises(1) isode-consortium (453) mhs-ds (7)}

routing OBJECT IDENTIFIER ::= {mhs-ds 3}
                                                                   390
oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}
oc-mta OBJECT IDENTIFIER ::= {oc 1}
oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2}
oc-routing-information OBJECT IDENTIFIER ::= {oc 3}
oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4}
oc-routed-ua OBJECT IDENTIFIER ::= {oc 8}                          400
oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6}
oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7}

at-access-md OBJECT IDENTIFIER ::= {at 1}
at-access-units-used OBJECT IDENTIFIER ::= {at 2}
at-subtree-information OBJECT IDENTIFIER ::= {at 3}
at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4}
at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5}

at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7}          410

at-global-domain-id OBJECT IDENTIFIER ::= {at 10}
at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11}
at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}
at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13}
at-initiator-pulling-authentication-requirements
                                         OBJECT IDENTIFIER ::= {at 14}
at-local-access-unit OBJECT IDENTIFIER ::= {at 15}
at-redirect OBJECT IDENTIFIER ::= {at 46}
at-mta-info OBJECT IDENTIFIER ::= {at 40}                          420
at-mta-name OBJECT IDENTIFIER ::= {at 19}

at-mta-will-route OBJECT IDENTIFIER ::= {at 21}
at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22}
at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}
at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24}
at-responder-pulling-authentication-requirements
                                         OBJECT IDENTIFIER ::= {at 25}
at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26}
at-routing-failure-action OBJECT IDENTIFIER ::= {at 27}
at-routing-filter OBJECT IDENTIFIER ::= {at 28}                    430
at-routing-tree-list OBJECT IDENTIFIER ::= {at 29}
at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30}
at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31}
at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32}
at-supporting-mta OBJECT IDENTIFIER ::= {at 33}
at-transport-community OBJECT IDENTIFIER ::= {at 34}
at-user-name OBJECT IDENTIFIER ::= {at 35}
at-non-delivery-info OBJECT IDENTIFIER ::= {at 47}
at-polled-mtas  OBJECT IDENTIFIER ::= {at 37}
at-bilateral-table OBJECT IDENTIFIER {at 45}                       440
at-supported-extension OBJECT IDENTIFIER {at 42}
at-supported-mts-extension OBJECT IDENTIFIER {at 43}
at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44}

id-alternative-address-information OBJECT IDENTIFIER ::= {id 1}

ts-communities OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) ts-communities (4)}

                                                                   450
tc-cons OBJECT IDENTIFIER ::= {ts-communities 1}    -- OSI CONS
tc-clns OBJECT IDENTIFIER ::= {ts-communities 2}    -- OSI CLNS
tc-internet OBJECT IDENTIFIER ::= {ts-communities 3}-- Internet+RFC1006
tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25
                                                    -- Without CONS
tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5}     -- IXI (Europe)
tc-janet OBJECT IDENTIFIER ::= {ts-communities 6}   -- Janet (UK)

mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) mail-protocol (5)} 460

ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1}      -- p1(1984)
ac-smtp  OBJECT IDENTIFIER ::= {mail-protocol 2}        -- SMTP
ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3}         -- UUCP Mail
ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4}     -- JNT Mail (UK)
ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5}
                                               -- p1(1988) in X.410 mode
ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6}      -- p3(1984)
END

                       Figure 22:  ASN.1 Summary

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

E  Regular Expression Syntax

   This appendix defines a form of regular expression for pattern
   matching.  This pattern matching is derived from commonly available
   regular expression software including UNIX egrep(1) The matching is
   modified to be case insensitive.

    A regular expression (RE) specifies a set of character strings to
    match against - such as "any string containing digits 5 through
    9".  A member of this set of strings is said to be matched by the
    regular expression.

    Where multiple matches are present in a line, a regular expression
    matches the longest of the leftmost matching strings.

    Regular expressions can be built up from the following
    "single-character" RE's:

     c    Any ordinary character not listed below.  An ordinary
          character matches itself.

     \    Backslash.  When followed by a special character, the RE
          matches the "quoted" character, cancelling the special nature
          of the character.

     .    Dot.  Matches any single character.

     ^    As the leftmost character, a caret (or circumflex) con-
          strains the RE to match the leftmost portion of a string.  A
          match of this type is called an "anchored match" because it is
          "anchored" to a specific place in the string.  The ^ character
          loses its special meaning if it appears in any position other

          than the start of the RE.

     $    As the rightmost character, a dollar sign constrains the RE to
          match the rightmost portion of a string.  The $ character
          loses its special meaning if it appears in any position other
          than at the end of the RE.

     ^RE$ The construction ^RE$ constrains the RE to match the entire
          string.

     [c...]
          A nonempty string of characters, enclosed in square brackets
          matches any single character in the string.  For example,
          [abcxyz] matches any single character from the set `abcxyz'.
          When the first character of the string is a caret (^), then
          the RE matches any charac- ter except those in the remainder
          of the string.  For example, `[^45678]' matches any character
          except `45678'.  A caret in any other position is interpreted
          as an ordinary character.

     []c...]
          The right square bracket does not terminate the enclosed
          string if it is the first character (after an initial `^', if
          any), in the bracketed string.  In this position it is treated
          as an ordinary character.

     [l-r]
          The minus sign (hyphen), between two characters, indicates a
          range of consecutive ASCII characters to match.  For example,
          the range `[0-9]' is equivalent to the string `[0123456789]'.
          Such a bracketed string of characters is known as a character
          class.  The `-' is treated as an ordinary character if it
          occurs first (or first after an initial ^) or last in the
          string.

          The following rules and special characters allow for
          con-structing RE's from single-character RE's:

          A concatenation of RE's matches a concatenation of text
          strings, each of which is a match for a successive RE in the
          search pattern.

     *    A regular expression, followed by an asterisk (*) matches zero
          or more occurrences of the regular expression.  For example,
          [a-z][a-z]* matches any string of one or more lower case
          letters.

     +    A regular expression, followed by a plus character (+) matches
          one or more occurrences of the regular expression.  For
          example, [a-z]+ matches any string of one or more lower case
          letters.

     ?    A regular expression, followed by a question mark (?) matches
          zero or one occurrences of the regular expression.  For
          example, ^[a-z]?[0-9]* matches a string starting with an
          optional lower case letter, followed by zero or more digits.

     {m}
     {m,}
     {m,n}
          A regular expression, followed by {m}, {m,}, or {m,n} matches
          a range of occurrences of the regular expression.  The values
          of m and n must be non-negative integers less than 256; {m}
          matches exactly m occurrences; {m,} matches at least m
          occurrences; {m,n} matches any number of occurrences between m
          and n inclusive.  Whenever a choice exists, the regular
          expression matches as many occurrences as possible.

     |    Alternation: two regular expressions separated by `|' or
          NEWLINE match either a match for the first or a match for the
          second.

     (...)
          A regular expression enclosed between the character sequences
          ( and ) matches whatever the unadorned RE matches.

    The order of precedence of operators at the same parenthesis level
    is `[ ]' (character classes), then `*' `+' `?' '{m,n}' (closures),
    then concatenation, then `|' (alternation) and NEWLINE.