home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1649 < prev    next >
Text File  |  1995-09-15  |  28KB  |  788 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Hagens
  8. Request for Comments: 1649             Advanced Network & Services, Inc.
  9. Category: Informational                                        A. Hansen
  10.                                                                  UNINETT
  11.                                                                July 1994
  12.  
  13.  
  14.          Operational Requirements for X.400 Management Domains
  15.                         in the GO-MHS Community
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  This memo
  20.    does not specify an Internet standard of any kind.  Distribution of
  21.    this memo is unlimited.
  22.  
  23. 1.  Introduction
  24.  
  25.    There are several large, operational X.400 services currently
  26.    deployed. Many of the organizations in these services are connected
  27.    to the Internet.  A number of other Internet-connected organizations
  28.    are beginning to operate internal X.400 services (for example, U.S.
  29.    government organizations following U.S. GOSIP).  The motivation for
  30.    this document is to foster a Global Open Message Handling System
  31.    (GO-MHS) Community that has full interoperability with the existing
  32.    E-mail service based on RFC-822 (STD-11).
  33.  
  34.    The goal of this document is to unite regionally operated X.400
  35.    services on the various continents into one GO-MHS Community (as seen
  36.    from an end-user's point of view).  Examples of such regional
  37.    services are the COSINE MHS Service in Europe and the XNREN service
  38.    in the U.S.
  39.  
  40.    A successful GO-MHS Community is dependent on decisions at both the
  41.    national and international level. National X.400 service providers
  42.    are responsible for the implementation of the minimum requirements
  43.    defined in this document. In addition to these minimum requirements,
  44.    national requirements may be defined by each national service
  45.    provider.
  46.  
  47.    This document refers to other documents which are published as RFCs.
  48.    These documents are [1], [2], [3], [4], [6] and [7] in the reference
  49.    list.
  50.  
  51.    This document handles issues concerning X.400 1984 and X.400 1988 to
  52.    1984 downgrading. Issues concerning pure X.400 1988 are left for
  53.    further study.
  54.  
  55.  
  56.  
  57.  
  58. Hagens & Hansen                                                 [Page 1]
  59.  
  60. RFC 1649               X.400 Management in GO-MHS              July 1994
  61.  
  62.  
  63.    We are grateful to Allan Cargille and Lawrence Landweber for their
  64.    input and guidance on this paper. This paper is also a product of
  65.    discussions in the IETF X.400 Operations WG and the RARE WG-MSG
  66.    (former RARE WG1 (on MHS)).
  67.  
  68. 1.1.  Terminology
  69.  
  70.    This document defines requirements, recommendations and conventions.
  71.    Throughout the document, the following definitions apply: a
  72.    requirement is specified with the word shall.  A recommendation is
  73.    specified with the word should.  A convention is specified with the
  74.    word might.  Conventions are intended to make life easier for RFC-822
  75.    systems that don't follow the host requirements.
  76.  
  77. 1.2.  Profiles
  78.  
  79.    Different communities have different profile requirements.  The
  80.    following is a list of such profiles.
  81.  
  82.     o U.S. GOSIP - unspecified version
  83.     o ENV - 41201
  84.     o UK GOSIP for X.400(88)
  85.  
  86.    In the case when mail traffic is going from the RFC-822 mail service
  87.    to the GO-MHS Community, the automatic return of contents when mail
  88.    is non-delivered should be requested by RFC 1327 gateways and should
  89.    be supported at the MTA that generates the non-delivery report.
  90.    However, it should be noted that this practice maximizes the cost
  91.    associated with delivery reports.
  92.  
  93. 2.  Architecture of the GO-MHS Community
  94.  
  95.    In order to facilitate a coherent deployment of X.400 in the GO-MHS
  96.    Community it is necessary to define, in general terms, the overall
  97.    structure and organization of the X.400 service.  This section is
  98.    broken into several parts which discuss management domains, lower
  99.    layer connectivity issues, and overall routing issues.
  100.  
  101.    The GO-MHS Community will operate as a single MHS community, as
  102.    defined in reference [1].
  103.  
  104. 2.1.  Management Domains
  105.  
  106.    The X.400 model supports connectivity between communities with
  107.    different service requirements; the architectural vehicle for this is
  108.    a Management Domain. Management domains are needed when different
  109.    administrations have different specific requirements.  Two types of
  110.    management domains are defined by the X.400 model: an Administration
  111.  
  112.  
  113.  
  114. Hagens & Hansen                                                 [Page 2]
  115.  
  116. RFC 1649               X.400 Management in GO-MHS              July 1994
  117.  
  118.  
  119.    Management Domain (ADMD) and a Private Management Domain (PRMD).
  120.  
  121.    Throughout the world in various countries there are different
  122.    organizational policies for MDs.  All of these policies are legal
  123.    according to the X.400 standard.  Currently, X.400 service providers
  124.    in a country (inside or outside the GO-MHS Community), are organized
  125.    as:
  126.  
  127.     a) One or several ADMDs.
  128.     b) One or several PRMDs and with no ADMDs present in
  129.        the country, or that are not connected to any ADMD.
  130.     c) One or several PRMDs connected to one or several ADMDs.
  131.  
  132.    Or in combinations of a), b) and c).  At this stage it is not
  133.    possible to say which model is the most effective.  Thus, the GO-MHS
  134.    Community shall allow every model.
  135.  
  136. 2.2.  The RELAY-MTA
  137.  
  138.    The X.400 message routing decision process takes as input the
  139.    destination O/R address and produces as output the name (and perhaps
  140.    connection information) of the MTA who will take responsibility of
  141.    delivering the message to the recipient. The X.400 store and forward
  142.    model permits a message to pass through multiple MTAs.  However, it
  143.    is generally accepted that the most efficient path for a message to
  144.    take is one where a direct connection is made from the originator to
  145.    the recipient's MTA.
  146.  
  147.    Large scale deployment of X.400 in the GO-MHS Community will require
  148.    a well deployed directory infrastructure to support routing. In the
  149.    GO-MHS Community X.500 is considered to be the best protocol for such
  150.    an infrastructure.  In this environment, a routing decision can be
  151.    made by searching the directory with a destination O/R address in
  152.    order to obtain the name of the next hop MTA. This MTA may be a
  153.    central entry point into an MD, or it may be the destination MTA
  154.    within an MD.
  155.  
  156.    Deployment of X.400 without a well deployed Directory infrastructure,
  157.    will require the use of static tables to store routing information.
  158.    These tables (keyed on O/R addresses), will be used to map a
  159.    destination O/R address to a next hop MTA.  In order to facilitate
  160.    efficient routing, one could build a table that contains information
  161.    about every MTA in every MD.  However, this table would be enormous
  162.    and very dynamic, so this is not feasible in practice.  Therefore, it
  163.    is necessary to use the concept of a RELAY-MTA.
  164.  
  165.    The purpose of a RELAY-MTA is to act as a default entry point into an
  166.    MD. The MTA that acts as a RELAY MTA for an MD shall be capable of
  167.  
  168.  
  169.  
  170. Hagens & Hansen                                                 [Page 3]
  171.  
  172. RFC 1649               X.400 Management in GO-MHS              July 1994
  173.  
  174.  
  175.    accepting responsibility for all messages that it receives that are
  176.    destined for well-defined recipients in that MD.
  177.  
  178.    The use of a RELAY-MTA for routing is defined by reference [1].
  179.    RELAY-MTAs in the GO-MHS Community shall route according to reference
  180.    [1].
  181.  
  182. 2.3.  Lower Layer Stack Incompatibilities
  183.  
  184.    A requirement for successful operation of the GO-MHS Community is
  185.    that all users can exchange messages. The GO-MHS Community is not
  186.    dependent on the traditional TCP/IP lower layer protocol suite.  A
  187.    variety of lower layer suites are used as carriers of X.400 messages.
  188.  
  189.    For example, consider Figure 1.
  190.  
  191.      -----------------------------------------------------
  192.      !                                                   !
  193.      !            PRMD A                                 !
  194.      !        --------------------                       !
  195.      !        !   o       x      !                       !
  196.      !        !                  !                       !
  197.      !        !     o        w   !                       !
  198.      !        !          z       !                       !
  199.      !        --------------------                       !
  200.      !                                PRMD B             !
  201.      !                            ------------------     !
  202.      !                            !      o     o   !     !
  203.      !    PRMD C                  !  o             !     !
  204.      !  ------------------        !      o     z   !     !
  205.      !  !       o        !        !                !     !
  206.      !  !  o        x    !        ------------------     !
  207.      !  !     o        w !                               !
  208.      !  !        o       !                               !
  209.      !  ------------------                               !
  210.      !                                                   !
  211.      !               Key: Each character the in          !
  212.      !                    the boxes illustrates an MTA.  !
  213.      !                                                   !
  214.      !                    x: TP0/RFC1006/TCP RELAY-MTA   !
  215.      !                    w: TP4/CLNP RELAY-MTA          !
  216.      !                    z: TP0/CONS/X.25 RELAY-MTA     !
  217.      !                    o: MTA                         !
  218.      -----------------------------------------------------
  219.  
  220.                  Figure 1: A Deployment Scenario
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hagens & Hansen                                                 [Page 4]
  227.  
  228. RFC 1649               X.400 Management in GO-MHS              July 1994
  229.  
  230.  
  231.    PRMD A has three RELAY-MTAs which collectively provide support for
  232.    the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks.  (Note: it is
  233.    acceptable for a single RELAY-MTA to support more than one stack.
  234.    Three RELAY-MTAs are shown in this figure for clarity.)  Thus, PRMD A
  235.    is reachable via these stacks.  However, since PRMD B only supports
  236.    the TP0/CONS/X.25 stack, it is not reachable from the TP0/RFC 1006 or
  237.    the TP4/CLNS stack. PRMD C supports TP0/RFC1006 and TP4/CLNS. Since
  238.    PRMD B and PRMD C do not share a common stack, how is a message from
  239.    PRMD C to reach a recipient in PRMD B?
  240.  
  241.    One solution to this problem is to require that PRMD B implement a
  242.    stack in common with PRMD C. However this may not be a politically
  243.    acceptable answer to PRMD B.
  244.  
  245.    Another solution is to implement a transport service bridge (TSB)
  246.    between TP0/RFC 1006 in PRMD C to TP0/CONS in PRMD B.  This will
  247.    solve the problem for PRMD C and B.  However, the lack of coordinated
  248.    deployment of TSB technology makes this answer alone unacceptable on
  249.    an international scale.
  250.  
  251.    The solution to this problem is to define a coordinated mechanism
  252.    that allows PRMD B to advertise to the world that it has made a
  253.    bilateral agreement with PRMD A to support reachability to PRMD B
  254.    from the TP0/RFC 1006 stack.
  255.  
  256.    This solution does not require that every MTA or MD directly support
  257.    all stacks. However, it is a requirement that if a particular stack
  258.    is not directly supported by an MD, the MD will need to make
  259.    bilateral agreements with other MD(s) in order to assure that
  260.    connectivity from that stack is available.
  261.  
  262.    Thus, in the case of Figure 1, PRMD B can make a bilateral agreement
  263.    with PRMD A which provides for PRMD A to relay messages which arrive
  264.    on either the TP4/CLNP stack or the TP0/RFC 1006 stack to PRMD B
  265.    using the TP0/CONS stack.
  266.  
  267.    The policies described in reference [1] define this general purpose
  268.    solution.  It is a requirement that all MDs follow the rules and
  269.    policies defined by reference [1].
  270.  
  271. 3.  Description of GO-MHS Community Policies
  272.  
  273.    A GO-MD is a Management Domain in the GO-MHS Community.
  274.  
  275.    The policies described in this section constitute a minimum set of
  276.    common policies for GO-MDs. They are specified to ensure
  277.    interoperability between:
  278.  
  279.  
  280.  
  281.  
  282. Hagens & Hansen                                                 [Page 5]
  283.  
  284. RFC 1649               X.400 Management in GO-MHS              July 1994
  285.  
  286.  
  287.     - all GO-MDs.
  288.     - all GO-MDs and the RFC-822 mail service (SMTP).
  289.     - all GO-MDs and other X.400 service providers.
  290.  
  291. 3.1.  X.400 Address Registration
  292.  
  293.    An O/R address is a descriptive name for a UA that has certain
  294.    characteristics that help the Service Providers to locate the UA.
  295.    Every O/R address is an O/R name, but not every O/R name is an O/R
  296.    address.  This is explained in reference [5], chapter 3.1.
  297.  
  298.    Uniqueness of X.400 addresses shall be used to ensure end-user
  299.    connectivity.
  300.  
  301.    Mailboxes shall be addressed according to the description of O/R
  302.    names, Form 1, Variant 1 (see reference [5], chapter 3.3.2). The
  303.    attributes shall be regarded as a hierarchy of:
  304.  
  305.     Country name (C)
  306.     Administration domain name (ADMD)
  307.     [Private domain name] (PRMD)
  308.     [Organization name] (O)
  309.     [Organizational Unit Names] (OUs)
  310.     [Personal name] (PN)
  311.     [Domain-defined attributes] (DDAs)
  312.  
  313.    Attributes enclosed in square brackets are optional.  At least one of
  314.    PRMD, O, OU and PN names shall be present in an O/R address. At least
  315.    one of PN and DDA shall be present.
  316.  
  317.    In general a subordinate address element shall be unique within the
  318.    scope of its immediately superior element. An exception is PRMD, see
  319.    section 3.1.3.  There shall exist registration authorities for each
  320.    level, or mechanisms shall be available to ensure such uniqueness.
  321.  
  322. 3.1.1.  Country (C)
  323.  
  324.    The values of the top level element, Country, shall be defined by the
  325.    set of two letter country codes, or numeric country codes in ISO
  326.    3166.
  327.  
  328. 3.1.2.  Administration Management Domain (ADMD)
  329.  
  330.    The values of the ADMD field are decided on a national basis.  Every
  331.    national decision made within the GO-MHS community shall be supported
  332.    by a GO-MD.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Hagens & Hansen                                                 [Page 6]
  339.  
  340. RFC 1649               X.400 Management in GO-MHS              July 1994
  341.  
  342.  
  343. 3.1.3.  Private Management Domain (PRMD)
  344.  
  345.    The PRMD values should be unique within a country.
  346.  
  347. 3.1.4.  Organization (O)
  348.  
  349.    Organization values shall be unique within the context of the
  350.    subscribed PRMD or ADMD if there is no PRMD.  For clarification, the
  351.    following situation is legal:
  352.  
  353.     1) C=FI; ADMD=FUMAIL; O=FUNET.
  354.     2) C=FI; ADMD=FUMAIL; PRMD=NOKIA; O=FUNET.
  355.  
  356.    In this case 1) and 2) are different addreses. (Note that 2) at this
  357.    point is a hypotethical address). O=FUNET is a subscriber both at
  358.    ADMD=FUMAIL, 1), and at PRMD=NOKIA, 2).
  359.  
  360. 3.1.5.  Organizational Units (OUs)
  361.  
  362.    If used, a unique hierarchy of OUs shall be implemented. The top
  363.    level OU is unique within the scope of the immediately superior
  364.    address element (i.e., Organization, PRMD or ADMD).  Use of multiple
  365.    OUs may be confusing.
  366.  
  367. 3.1.6.  Given Name, Initials, Surname (G I S)
  368.  
  369.    Each Organization can define its own Given-names, Initials, and
  370.    Surnames to be used within the Organization. In the cases when
  371.    Surnames are not unique within an O or OU, the Given-name and/or
  372.    Initial shall be used to identify the Originator/Recipient. In the
  373.    rare cases when more than one user would have the same combination of
  374.    G, I, S under the same O and/or OUs, each organization is free to
  375.    find a practical solution, and provide the users with unique O/R
  376.    addresses.
  377.  
  378.    Either one of Given-name or Initials should be used, not both.
  379.    Periods shall not be used in Initials.
  380.  
  381.    To avoid problems with the mapping of the X.400 addresses to RFC-822
  382.    addresses, the following rules might be used. ADMD, PRMD, O, and OU
  383.    values should consist of characters drawn from the alphabet (A-Z),
  384.    digits (0-9), and minus.  Blank or Space characters should be
  385.    avoided.  No distinction is made between upper and lower case. The
  386.    last character shall not be a minus sign or period.  The first
  387.    character should be either a letter or a digit (see reference [6] and
  388.    [7]).
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Hagens & Hansen                                                 [Page 7]
  395.  
  396. RFC 1649               X.400 Management in GO-MHS              July 1994
  397.  
  398.  
  399. 3.1.7.  Domain Defined Attributes (DDAs)
  400.  
  401.    The GO-MHS Community shall allow the use of domain defined
  402.    attributes.  Note: Support for DDAs is mandatory in the functional
  403.    profiles, and all software must upgrade to support DDAs.  The
  404.    following DDAs shall be supported by a GO-MD:
  405.  
  406.     "RFC-822" - defined in reference [3].
  407.  
  408.    The following DDAs should be supported by a GO-MD:
  409.  
  410.     "COMMON" - defined in reference [2].
  411.  
  412. 3.2.  X.400 88 -> 84 Downgrading
  413.  
  414.    The requirements in reference [2] should be implemented in GO-MDs
  415.  
  416. 3.3.  X.400 / RFC-822 address mapping
  417.  
  418.    All GO-MHS Community end-users shall be reachable from all end-users
  419.    in the RFC-822 mail service in the Internet (SMTP), and vice versa.
  420.  
  421.    The address mapping issue is split into two parts:
  422.  
  423.     1) Specification of RFC-822 addresses seen from the X.400 world.
  424.     2) Specification of X.400 addresses seen from the RFC-822 world.
  425.  
  426.    The mapping of X.400 and RFC-822 addresses shall be performed
  427.    according to reference [3].
  428.  
  429. 3.3.1.  Specification of RFC-822 Addresses seen from the X.400 World
  430.  
  431.    Two scenarios are described:
  432.  
  433.     A. The RFC-822 end-user belongs to an organization with no defined
  434.        X.400 standard attribute address space.
  435.     B. The RFC-822 end-user belongs to an organization with a defined
  436.        X.400 standard attribute address space.
  437.  
  438.    Organizations belong to scenario B if their X.400 addresses are
  439.    registered according to the requirements in section 3.1.
  440.  
  441. 3.3.1.1.  An Organization with a defined X.400 Address Space
  442.  
  443.    An RFC-822 address for an RFC-822 mail user in such an organization
  444.    shall be in the same address space as a normal X.400 address for
  445.    X.400 users in the same organization.  RFC-822 addresses and X.400
  446.    addresses are thus sharing the same address space.  Example:
  447.  
  448.  
  449.  
  450. Hagens & Hansen                                                 [Page 8]
  451.  
  452. RFC 1649               X.400 Management in GO-MHS              July 1994
  453.  
  454.  
  455.    University of Wisconsin-Madison is registered under C=US;
  456.    ADMD=Internet; PRMD=XNREN; with O=UW-Madison and they are using OU=cs
  457.    to address end-users in the CS-department.  The RFC-822 address for
  458.    RFC-822 mail users in the same department is: user@cs.wisc.edu.
  459.  
  460.    An X.400 user in the GO-MHS Community will address the RFC-822 mail
  461.    user at the CS-department with the X.400 address:
  462.  
  463.     C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user;
  464.  
  465.    This is the same address space as is used for X.400 end-users in the
  466.    same department.
  467.  
  468. 3.3.1.2.  An Organization with no defined X.400 Address Space
  469.  
  470.    RFC-822 addresses shall be expressed using X.400 domain defined
  471.    attributes.  The mechanism used to define the RFC-822 recipient will
  472.    vary on a per-country basis.
  473.  
  474.    For example, in the U.S., a special PRMD named "Internet" is defined
  475.    to facilitate the specification of RFC-822 addresses.  An X.400 user
  476.    can address an RFC-822 recipient in the U.S. by constructing an X.400
  477.    address such as:
  478.  
  479.     C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;
  480.  
  481.    The first part of this address:
  482.  
  483.     C=us; ADMD=Internet; PRMD=Internet;
  484.  
  485.    denotes the U.S. portion of the Internet community and not a specific
  486.    "gateway". The 2nd part:
  487.  
  488.     DD.RFC-822=user(a)some.place.edu
  489.  
  490.    is the RFC-822 address of the RFC-822 mail user after substitution of
  491.    non-printable characters according to reference [3]. The RFC-822
  492.    address is placed in an X.400 Domain Defined Attribute of type RFC-
  493.    822 (DD.RFC-822).
  494.  
  495.    Each country is free to choose its own method of defining the RFC-822
  496.    community.  For example in Italy, an X.400 user would refer to an
  497.    RFC-822 user as:
  498.  
  499.     C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it
  500.  
  501.    In the UK, an X.400 user would refer to an RFC-822 user as:
  502.  
  503.  
  504.  
  505.  
  506. Hagens & Hansen                                                 [Page 9]
  507.  
  508. RFC 1649               X.400 Management in GO-MHS              July 1994
  509.  
  510.  
  511.     C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk
  512.  
  513. 3.3.2.  Specification of X.400 Addresses seen from the RFC-822 World
  514.  
  515.    If an X.400 organization has a defined RFC-822 address space, RFC-822
  516.    users will be able to address X.400 recipients in RFC-822/Internet
  517.    terms.  This means that the address of the X.400 user, seen from an
  518.    RFC-822 user, will generally be of the form:
  519.  
  520.     Firstname.Lastname@some.place.edu
  521.  
  522.    where the some.place.edu is a registered Internet domain.
  523.  
  524.    This implies the necessity of maintaining and distributing address
  525.    mapping tables to all participating RFC-1327 gateways. The mapping
  526.    tables shall be globally consistent.  Effective mapping table
  527.    coordination procedures are needed.
  528.  
  529.    If an organization does not have a defined RFC-822 address space, an
  530.    escape mapping (defined in reference [3]) shall be used. In this
  531.    case, the address of the X.400 user, seen from an RFC-822 user, will
  532.    be of the form:
  533.  
  534.     "/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
  535.                                     some.gateway.edu
  536.  
  537.    Note that reference [7] specifies that quoted left-hand side
  538.    addresses must be supported and that these addresses may be greater
  539.    than 80 characters long.
  540.  
  541.    This escape mapping shall also be used for X.400 addresses which do
  542.    not map cleanly to RFC-822 addresses.
  543.  
  544.    It is recommended that an organization with no defined RFC-822
  545.    address space, should register RFC-822 domains at the appropriate
  546.    registration entity for such registrations. This will minimize the
  547.    number of addresses which must use the escape mapping.
  548.  
  549.    If the escape mapping is not used, RFC-822 users will not see the
  550.    difference between an Internet RFC-822 address and an address in the
  551.    GO-MHS Community.  For example:
  552.  
  553.    The X.400 address:
  554.  
  555.     C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;
  556.  
  557.    will from an RFC-822 user look like:
  558.  
  559.  
  560.  
  561.  
  562. Hagens & Hansen                                                [Page 10]
  563.  
  564. RFC 1649               X.400 Management in GO-MHS              July 1994
  565.  
  566.  
  567.        Firstname.Lastname@cpg.cdc.com
  568.  
  569. 3.4.  Routing Policy
  570.  
  571.    To facilitate routing in the GO-MHS Community before an X.500
  572.    infrastructure is deployed, the following two documents, a RELAY-MTA
  573.    document and a Domain document, are defined.  These documents are
  574.    formally defined in reference [1]. The use of these documents is
  575.    necessary to solve the routing crisis that is present today. However,
  576.    this is a temporary solution that will eventually be replaced by the
  577.    use of X.500.
  578.  
  579.    The RELAY-MTA document will define the names of RELAY-MTAs and their
  580.    associated connection data including selector values, NSAP addresses,
  581.    supported protocol stacks, and supported X.400 protocol version(s).
  582.  
  583.    Each entry in the Domain document consists of a sub-tree hierarchy of
  584.    an X.400 address, followed by a list of MTAs which are willing to
  585.    accept mail for the address or provide a relay service for it. Each
  586.    MTA name will be associated with a priority value. Collectively, the
  587.    list of MTA names in the Domain document make the given address
  588.    reachable from all protocol stacks. In addition, the list of MTAs may
  589.    provide redundant paths to the address, so in this case, the priority
  590.    value indicates the preferred path, or the preferred order in which
  591.    alternative routes should be tried.
  592.  
  593.    The RELAY-MTA and Domain documents are coordinated by the group
  594.    specified in the Community document.  The procedures for document
  595.    information gathering and distribution, are for further study.
  596.  
  597. 3.5.  Minimum Statistics/Accounting
  598.  
  599.    The following are not required for all MTAs. The information is
  600.    provided as guidelines for MTA managers.  This is helpful for
  601.    observing service use and evaluating service performance.
  602.  
  603.    This section defines the data which should be kept by each MTA.
  604.    There are no constraints on the encoding used to store the data
  605.    (i.e., format).
  606.  
  607.    For each message/report passing the MTA, the following information
  608.    should be collected.
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Hagens & Hansen                                                [Page 11]
  619.  
  620. RFC 1649               X.400 Management in GO-MHS              July 1994
  621.  
  622.  
  623.    The following fields should be collected.
  624.  
  625.     Date
  626.     Time
  627.     Priority
  628.     Local MTA Name
  629.     Size
  630.  
  631.    The following fields are conditionally collected.
  632.  
  633.     From MTA Name (fm)
  634.     To MTA Name (tm)
  635.     Delta Time (dt)
  636.     Message-id (id)
  637.  
  638.    At least one of 'fm' and 'tm' should be present.  If one of 'fm' and
  639.    'tm' is not present, 'id' should be present. If both 'fm' and 'tm'
  640.    are present, then 'dt' indicates the number of minutes that the
  641.    message was delayed in the MTA.  If 'id' cannot be mapped locally
  642.    because of log file formats, 'id' is not present and every message
  643.    creates two lines: one with 'fm' empty and one with 'tm' empty. In
  644.    this case, 'date' and 'time' in the first line represent the date and
  645.    time the message entered the MTA.  In the second line, they represent
  646.    the date and time the message left the MTA.
  647.  
  648.    The following fields are optionally collected.
  649.  
  650.     From Domain (fd)
  651.     To Domain (td)
  652.  
  653.    For route tracing, 'fd' and 'td' are useful. They represent X.400
  654.    OU's, O, PRMD, ADMD and C and may be supplied up to any level of
  655.    detail.
  656.  
  657. 4.  Community Document
  658.  
  659.    For the GO-MHS community there will exist one single COMMUNITY
  660.    document containing basic information as defined in reference [1].
  661.    First the contact information for the central coordination point can
  662.    be found together with the addresses for the file server where all
  663.    the documents are stored.  It also lists network names and stacks to
  664.    be used in the RELAY-MTA and DOMAIN documents. The GO-MHS community
  665.    must agree on its own set of mandatory and optional networks and
  666.    stacks.
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Hagens & Hansen                                                [Page 12]
  675.  
  676. RFC 1649               X.400 Management in GO-MHS              July 1994
  677.  
  678.  
  679. 5.  Security Considerations
  680.  
  681.    Security issues are not discussed in this memo.
  682.  
  683. 6.  Authors' Addresses
  684.  
  685.    Robert Hagens
  686.    Advanced Network & Services, Inc.
  687.    1875 Campus Commons Drive
  688.    Suite 220
  689.    Reston, VA 22091
  690.    U.S.A.
  691.  
  692.    Phone: +1 703 758 7700
  693.    Fax:   +1 703 758 7717
  694.    EMail: hagens@ans.net
  695.    DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US
  696.  
  697.  
  698.    Alf Hansen
  699.    UNINETT
  700.    Elgesetergt. 10
  701.    Postbox 6883, Elgeseter
  702.    N-7002 Trondheim
  703.    Norway
  704.  
  705.    Phone: +47 7359 2982
  706.    Fax:   +47 7359 6450
  707.    EMail: Alf.Hansen@uninett.no
  708.    G=Alf; S=Hansen; O=uninett; P=uninett; C=no
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Hagens & Hansen                                                [Page 13]
  731.  
  732. RFC 1649               X.400 Management in GO-MHS              July 1994
  733.  
  734.  
  735. References
  736.  
  737.    [1] Eppenberger, U., Routing Coordination for X.400 MHS-Services
  738.        Within a Multi Protocol / Multi Network Environment, RFC 1465,
  739.        SWITCH, May 1993.
  740.  
  741.    [2] Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading, RFC 1328,
  742.        University College London, May 1992.
  743.  
  744.    [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
  745.        and RFC 822, RFC 1327, May 1992.
  746.  
  747.    [4] Cargille, A., "Postmaster Convention for X.400 Operations", RFC
  748.        1648, University of Wisconsin, July 1994.
  749.  
  750.    [5] International Telecommunications Union, CCITT.  Data
  751.        Communications Networks, Volume VIII, Message Handling Systems,
  752.        ITU: Geneva 1985.
  753.  
  754.    [6] Harrenstien, K., Stahl, M., and E. Feinler, "DOD Internet Host
  755.        Table Specification", RFC 952, SRI, October 1985.
  756.  
  757.    [7] Braden, R., "Requirements for Internet Hosts -- Application and
  758.        Support", STD 3,  RFC 1123, USC/Information Sciences Institute,
  759.        October 1989.
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Hagens & Hansen                                                [Page 14]
  787.  
  788.