rfc1649.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1649               X.400 Management in GO-MHS              July 1994


3.1.7.  Domain Defined Attributes (DDAs)

   The GO-MHS Community shall allow the use of domain defined
   attributes.  Note: Support for DDAs is mandatory in the functional
   profiles, and all software must upgrade to support DDAs.  The
   following DDAs shall be supported by a GO-MD:

    "RFC-822" - defined in reference [3].

   The following DDAs should be supported by a GO-MD:

    "COMMON" - defined in reference [2].

3.2.  X.400 88 -> 84 Downgrading

   The requirements in reference [2] should be implemented in GO-MDs

3.3.  X.400 / RFC-822 address mapping

   All GO-MHS Community end-users shall be reachable from all end-users
   in the RFC-822 mail service in the Internet (SMTP), and vice versa.

   The address mapping issue is split into two parts:

    1) Specification of RFC-822 addresses seen from the X.400 world.
    2) Specification of X.400 addresses seen from the RFC-822 world.

   The mapping of X.400 and RFC-822 addresses shall be performed
   according to reference [3].

3.3.1.  Specification of RFC-822 Addresses seen from the X.400 World

   Two scenarios are described:

    A. The RFC-822 end-user belongs to an organization with no defined
       X.400 standard attribute address space.
    B. The RFC-822 end-user belongs to an organization with a defined
       X.400 standard attribute address space.

   Organizations belong to scenario B if their X.400 addresses are
   registered according to the requirements in section 3.1.

3.3.1.1.  An Organization with a defined X.400 Address Space

   An RFC-822 address for an RFC-822 mail user in such an organization
   shall be in the same address space as a normal X.400 address for
   X.400 users in the same organization.  RFC-822 addresses and X.400
   addresses are thus sharing the same address space.  Example:



Hagens & Hansen                                                 [Page 8]

RFC 1649               X.400 Management in GO-MHS              July 1994


   University of Wisconsin-Madison is registered under C=US;
   ADMD=Internet; PRMD=XNREN; with O=UW-Madison and they are using OU=cs
   to address end-users in the CS-department.  The RFC-822 address for
   RFC-822 mail users in the same department is: [e-mail].

   An X.400 user in the GO-MHS Community will address the RFC-822 mail
   user at the CS-department with the X.400 address:

    C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user;

   This is the same address space as is used for X.400 end-users in the
   same department.

3.3.1.2.  An Organization with no defined X.400 Address Space

   RFC-822 addresses shall be expressed using X.400 domain defined
   attributes.  The mechanism used to define the RFC-822 recipient will
   vary on a per-country basis.

   For example, in the U.S., a special PRMD named "Internet" is defined
   to facilitate the specification of RFC-822 addresses.  An X.400 user
   can address an RFC-822 recipient in the U.S. by constructing an X.400
   address such as:

    C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;

   The first part of this address:

    C=us; ADMD=Internet; PRMD=Internet;

   denotes the U.S. portion of the Internet community and not a specific
   "gateway". The 2nd part:

    DD.RFC-822=user(a)some.place.edu

   is the RFC-822 address of the RFC-822 mail user after substitution of
   non-printable characters according to reference [3]. The RFC-822
   address is placed in an X.400 Domain Defined Attribute of type RFC-
   822 (DD.RFC-822).

   Each country is free to choose its own method of defining the RFC-822
   community.  For example in Italy, an X.400 user would refer to an
   RFC-822 user as:

    C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it

   In the UK, an X.400 user would refer to an RFC-822 user as:




Hagens & Hansen                                                 [Page 9]

RFC 1649               X.400 Management in GO-MHS              July 1994


    C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk

3.3.2.  Specification of X.400 Addresses seen from the RFC-822 World

   If an X.400 organization has a defined RFC-822 address space, RFC-822
   users will be able to address X.400 recipients in RFC-822/Internet
   terms.  This means that the address of the X.400 user, seen from an
   RFC-822 user, will generally be of the form:

    [e-mail]

   where the some.place.edu is a registered Internet domain.

   This implies the necessity of maintaining and distributing address
   mapping tables to all participating RFC-1327 gateways. The mapping
   tables shall be globally consistent.  Effective mapping table
   coordination procedures are needed.

   If an organization does not have a defined RFC-822 address space, an
   escape mapping (defined in reference [3]) shall be used. In this
   case, the address of the X.400 user, seen from an RFC-822 user, will
   be of the form:

    "/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
                                    some.gateway.edu

   Note that reference [7] specifies that quoted left-hand side
   addresses must be supported and that these addresses may be greater
   than 80 characters long.

   This escape mapping shall also be used for X.400 addresses which do
   not map cleanly to RFC-822 addresses.

   It is recommended that an organization with no defined RFC-822
   address space, should register RFC-822 domains at the appropriate
   registration entity for such registrations. This will minimize the
   number of addresses which must use the escape mapping.

   If the escape mapping is not used, RFC-822 users will not see the
   difference between an Internet RFC-822 address and an address in the
   GO-MHS Community.  For example:

   The X.400 address:

    C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;

   will from an RFC-822 user look like:




Hagens & Hansen                                                [Page 10]

RFC 1649               X.400 Management in GO-MHS              July 1994


       [e-mail]

3.4.  Routing Policy

   To facilitate routing in the GO-MHS Community before an X.500
   infrastructure is deployed, the following two documents, a RELAY-MTA
   document and a Domain document, are defined.  These documents are
   formally defined in reference [1]. The use of these documents is
   necessary to solve the routing crisis that is present today. However,
   this is a temporary solution that will eventually be replaced by the
   use of X.500.

   The RELAY-MTA document will define the names of RELAY-MTAs and their
   associated connection data including selector values, NSAP addresses,
   supported protocol stacks, and supported X.400 protocol version(s).

   Each entry in the Domain document consists of a sub-tree hierarchy of
   an X.400 address, followed by a list of MTAs which are willing to
   accept mail for the address or provide a relay service for it. Each
   MTA name will be associated with a priority value. Collectively, the
   list of MTA names in the Domain document make the given address
   reachable from all protocol stacks. In addition, the list of MTAs may
   provide redundant paths to the address, so in this case, the priority
   value indicates the preferred path, or the preferred order in which
   alternative routes should be tried.

   The RELAY-MTA and Domain documents are coordinated by the group
   specified in the Community document.  The procedures for document
   information gathering and distribution, are for further study.

3.5.  Minimum Statistics/Accounting

   The following are not required for all MTAs. The information is
   provided as guidelines for MTA managers.  This is helpful for
   observing service use and evaluating service performance.

   This section defines the data which should be kept by each MTA.
   There are no constraints on the encoding used to store the data
   (i.e., format).

   For each message/report passing the MTA, the following information
   should be collected.









Hagens & Hansen                                                [Page 11]

RFC 1649               X.400 Management in GO-MHS              July 1994


   The following fields should be collected.

    Date
    Time
    Priority
    Local MTA Name
    Size

   The following fields are conditionally collected.

    From MTA Name (fm)
    To MTA Name (tm)
    Delta Time (dt)
    Message-id (id)

   At least one of 'fm' and 'tm' should be present.  If one of 'fm' and
   'tm' is not present, 'id' should be present. If both 'fm' and 'tm'
   are present, then 'dt' indicates the number of minutes that the
   message was delayed in the MTA.  If 'id' cannot be mapped locally
   because of log file formats, 'id' is not present and every message
   creates two lines: one with 'fm' empty and one with 'tm' empty. In
   this case, 'date' and 'time' in the first line represent the date and
   time the message entered the MTA.  In the second line, they represent
   the date and time the message left the MTA.

   The following fields are optionally collected.

    From Domain (fd)
    To Domain (td)

   For route tracing, 'fd' and 'td' are useful. They represent X.400
   OU's, O, PRMD, ADMD and C and may be supplied up to any level of
   detail.

4.  Community Document

   For the GO-MHS community there will exist one single COMMUNITY
   document containing basic information as defined in reference [1].
   First the contact information for the central coordination point can
   be found together with the addresses for the file server where all
   the documents are stored.  It also lists network names and stacks to
   be used in the RELAY-MTA and DOMAIN documents. The GO-MHS community
   must agree on its own set of mandatory and optional networks and
   stacks.







Hagens & Hansen                                                [Page 12]

RFC 1649               X.400 Management in GO-MHS              July 1994


5.  Security Considerations

   Security issues are not discussed in this memo.

6.  Authors' Addresses

   Robert Hagens
   Advanced Network & Services, Inc.
   1875 Campus Commons Drive
   Suite 220
   Reston, VA 22091
   U.S.A.

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US


   Alf Hansen
   UNINETT
   Elgesetergt. 10
   Postbox 6883, Elgeseter
   N-7002 Trondheim
   Norway

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   G=Alf; S=Hansen; O=uninett; P=uninett; C=no





















Hagens & Hansen                                                [Page 13]

RFC 1649               X.400 Management in GO-MHS              July 1994


References

   [1] Eppenberger, U., Routing Coordination for X.400 MHS-Services
       Within a Multi Protocol / Multi Network Environment, RFC 1465,
       SWITCH, May 1993.

   [2] Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading, RFC 1328,
       University College London, May 1992.

   [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
       and RFC 822, RFC 1327, May 1992.

   [4] Cargille, A., "Postmaster Convention for X.400 Operations", RFC
       1648, University of Wisconsin, July 1994.

   [5] International Telecommunications Union, CCITT.  Data
       Communications Networks, Volume VIII, Message Handling Systems,
       ITU: Geneva 1985.

   [6] Harrenstien, K., Stahl, M., and E. Feinler, "DOD Internet Host
       Table Specification", RFC 952, SRI, October 1985.

   [7] Braden, R., "Requirements for Internet Hosts -- Application and
       Support", STD 3,  RFC 1123, USC/Information Sciences Institute,
       October 1989.


























Hagens & Hansen                                                [Page 14]