diff options
Diffstat (limited to 'doc/rfc/rfc1649.txt')
| -rw-r--r-- | doc/rfc/rfc1649.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc1649.txt b/doc/rfc/rfc1649.txt new file mode 100644 index 0000000..3a62071 --- /dev/null +++ b/doc/rfc/rfc1649.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group R. Hagens +Request for Comments: 1649 Advanced Network & Services, Inc. +Category: Informational A. Hansen + UNINETT + July 1994 + + + Operational Requirements for X.400 Management Domains + in the GO-MHS Community + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +1. Introduction + + There are several large, operational X.400 services currently + deployed. Many of the organizations in these services are connected + to the Internet. A number of other Internet-connected organizations + are beginning to operate internal X.400 services (for example, U.S. + government organizations following U.S. GOSIP). The motivation for + this document is to foster a Global Open Message Handling System + (GO-MHS) Community that has full interoperability with the existing + E-mail service based on RFC-822 (STD-11). + + The goal of this document is to unite regionally operated X.400 + services on the various continents into one GO-MHS Community (as seen + from an end-user's point of view). Examples of such regional + services are the COSINE MHS Service in Europe and the XNREN service + in the U.S. + + A successful GO-MHS Community is dependent on decisions at both the + national and international level. National X.400 service providers + are responsible for the implementation of the minimum requirements + defined in this document. In addition to these minimum requirements, + national requirements may be defined by each national service + provider. + + This document refers to other documents which are published as RFCs. + These documents are [1], [2], [3], [4], [6] and [7] in the reference + list. + + This document handles issues concerning X.400 1984 and X.400 1988 to + 1984 downgrading. Issues concerning pure X.400 1988 are left for + further study. + + + + +Hagens & Hansen [Page 1] + +RFC 1649 X.400 Management in GO-MHS July 1994 + + + We are grateful to Allan Cargille and Lawrence Landweber for their + input and guidance on this paper. This paper is also a product of + discussions in the IETF X.400 Operations WG and the RARE WG-MSG + (former RARE WG1 (on MHS)). + +1.1. Terminology + + This document defines requirements, recommendations and conventions. + Throughout the document, the following definitions apply: a + requirement is specified with the word shall. A recommendation is + specified with the word should. A convention is specified with the + word might. Conventions are intended to make life easier for RFC-822 + systems that don't follow the host requirements. + +1.2. Profiles + + Different communities have different profile requirements. The + following is a list of such profiles. + + o U.S. GOSIP - unspecified version + o ENV - 41201 + o UK GOSIP for X.400(88) + + In the case when mail traffic is going from the RFC-822 mail service + to the GO-MHS Community, the automatic return of contents when mail + is non-delivered should be requested by RFC 1327 gateways and should + be supported at the MTA that generates the non-delivery report. + However, it should be noted that this practice maximizes the cost + associated with delivery reports. + +2. Architecture of the GO-MHS Community + + In order to facilitate a coherent deployment of X.400 in the GO-MHS + Community it is necessary to define, in general terms, the overall + structure and organization of the X.400 service. This section is + broken into several parts which discuss management domains, lower + layer connectivity issues, and overall routing issues. + + The GO-MHS Community will operate as a single MHS community, as + defined in reference [1]. + +2.1. Management Domains + + The X.400 model supports connectivity between communities with + different service requirements; the architectural vehicle for this is + a Management Domain. Management domains are needed when different + administrations have different specific requirements. Two types of + management domains are defined by the X.400 model: an Administration + + + +Hagens & Hansen [Page 2] + +RFC 1649 X.400 Management in GO-MHS July 1994 + + + Management Domain (ADMD) and a Private Management Domain (PRMD). + + Throughout the world in various countries there are different + organizational policies for MDs. All of these policies are legal + according to the X.400 standard. Currently, X.400 service providers + in a country (inside or outside the GO-MHS Community), are organized + as: + + a) One or several ADMDs. + b) One or several PRMDs and with no ADMDs present in + the country, or that are not connected to any ADMD. + c) One or several PRMDs connected to one or several ADMDs. + + Or in combinations of a), b) and c). At this stage it is not + possible to say which model is the most effective. Thus, the GO-MHS + Community shall allow every model. + +2.2. The RELAY-MTA + + The X.400 message routing decision process takes as input the + destination O/R address and produces as output the name (and perhaps + connection information) of the MTA who will take responsibility of + delivering the message to the recipient. The X.400 store and forward + model permits a message to pass through multiple MTAs. However, it + is generally accepted that the most efficient path for a message to + take is one where a direct connection is made from the originator to + the recipient's MTA. + + Large scale deployment of X.400 in the GO-MHS Community will require + a well deployed directory infrastructure to support routing. In the + GO-MHS Community X.500 is considered to be the best protocol for such + an infrastructure. In this environment, a routing decision can be + made by searching the directory with a destination O/R address in + order to obtain the name of the next hop MTA. This MTA may be a + central entry point into an MD, or it may be the destination MTA + within an MD. + + Deployment of X.400 without a well deployed Directory infrastructure, + will require the use of static tables to store routing information. + These tables (keyed on O/R addresses), will be used to map a + destination O/R address to a next hop MTA. In order to facilitate + efficient routing, one could build a table that contains information + about every MTA in every MD. However, this table would be enormous + and very dynamic, so this is not feasible in practice. Therefore, it + is necessary to use the concept of a RELAY-MTA. + + The purpose of a RELAY-MTA is to act as a default entry point into an + MD. The MTA that acts as a RELAY MTA for an MD shall be capable of + + + +Hagens & Hansen [Page 3] + +RFC 1649 X.400 Management in GO-MHS July 1994 + + + accepting responsibility for all messages that it receives that are + destined for well-defined recipients in that MD. + + The use of a RELAY-MTA for routing is defined by reference [1]. + RELAY-MTAs in the GO-MHS Community shall route according to reference + [1]. + +2.3. Lower Layer Stack Incompatibilities + + A requirement for successful operation of the GO-MHS Community is + that all users can exchange messages. The GO-MHS Community is not + dependent on the traditional TCP/IP lower layer protocol suite. A + variety of lower layer suites are used as carriers of X.400 messages. + + For example, consider Figure 1. + + ----------------------------------------------------- + ! ! + ! PRMD A ! + ! -------------------- ! + ! ! o x ! ! + ! ! ! ! + ! ! o w ! ! + ! ! z ! ! + ! -------------------- ! + ! PRMD B ! + ! ------------------ ! + ! ! o o ! ! + ! PRMD C ! o ! ! + ! ------------------ ! o z ! ! + ! ! o ! ! ! ! + ! ! o x ! ------------------ ! + ! ! o w ! ! + ! ! o ! ! + ! ------------------ ! + ! ! + ! Key: Each character the in ! + ! the boxes illustrates an MTA. ! + ! ! + ! x: TP0/RFC1006/TCP RELAY-MTA ! + ! w: TP4/CLNP RELAY-MTA ! + ! z: TP0/CONS/X.25 RELAY-MTA ! + ! o: MTA ! + ----------------------------------------------------- + + Figure 1: A Deployment Scenario + + + + + +Hagens & Hansen [Page 4] + +RFC 1649 X.400 Management in GO-MHS July 1994 + + + PRMD A has three RELAY-MTAs which collectively provide support for + the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks. (Note: it is + acceptable for a single RELAY-MTA to support more than one stack. + Three RELAY-MTAs are shown in this figure for clarity.) Thus, PRMD A + is reachable via these stacks. However, since PRMD B only supports + the TP0/CONS/X.25 stack, it is not reachable from the TP0/RFC 1006 or + the TP4/CLNS stack. PRMD C supports TP0/RFC1006 and TP4/CLNS. Since + PRMD B and PRMD C do not share a common stack, how is a message from + PRMD C to reach a recipient in PRMD B? + + One solution to this problem is to require that PRMD B implement a + stack in common with PRMD C. However this may not be a politically + acceptable answer to PRMD B. + + Another solution is to implement a transport service bridge (TSB) + between TP0/RFC 1006 in PRMD C to TP0/CONS in PRMD B. This will + solve the problem for PRMD C and B. However, the lack of coordinated + deployment of TSB technology makes this answer alone unacceptable on + an international scale. + + The solution to this problem is to define a coordinated mechanism + that allows PRMD B to advertise to the world that it has made a + bilateral agreement with PRMD A to support reachability to PRMD B + from the TP0/RFC 1006 stack. + + This solution does not require that every MTA or MD directly support + all stacks. However, it is a requirement that if a particular stack + is not directly supported by an MD, the MD will need to make + bilateral agreements with other MD(s) in order to assure that + connectivity from that stack is available. + + Thus, in the case of Figure 1, PRMD B can make a bilateral agreement + with PRMD A which provides for PRMD A to relay messages which arrive + on either the TP4/CLNP stack or the TP0/RFC 1006 stack to PRMD B + using the TP0/CONS stack. + + The policies described in reference [1] define this general purpose + solution. It is a requirement that all MDs follow the rules and + policies defined by reference [1]. + +3. Description of GO-MHS Community Policies + + A GO-MD is a Management Domain in the GO-MHS Community. + + The policies described in this section constitute a minimum set of + common policies for GO-MDs. They are specified to ensure + interoperability between: + + + + +Hagens & Hansen [Page 5] + +RFC 1649 X.400 Management in GO-MHS July 1994 + + + - all GO-MDs. + - all GO-MDs and the RFC-822 mail service (SMTP). + - all GO-MDs and other X.400 service providers. + +3.1. X.400 Address Registration + + An O/R address is a descriptive name for a UA that has certain + characteristics that help the Service Providers to locate the UA. + Every O/R address is an O/R name, but not every O/R name is an O/R + address. This is explained in reference [5], chapter 3.1. + + Uniqueness of X.400 addresses shall be used to ensure end-user + connectivity. + + Mailboxes shall be addressed according to the description of O/R + names, Form 1, Variant 1 (see reference [5], chapter 3.3.2). The + attributes shall be regarded as a hierarchy of: + + Country name (C) + Administration domain name (ADMD) + [Private domain name] (PRMD) + [Organization name] (O) + [Organizational Unit Names] (OUs) + [Personal name] (PN) + [Domain-defined attributes] (DDAs) + + Attributes enclosed in square brackets are optional. At least one of + PRMD, O, OU and PN names shall be present in an O/R address. At least + one of PN and DDA shall be present. + + In general a subordinate address element shall be unique within the + scope of its immediately superior element. An exception is PRMD, see + section 3.1.3. There shall exist registration authorities for each + level, or mechanisms shall be available to ensure such uniqueness. + +3.1.1. Country (C) + + The values of the top level element, Country, shall be defined by the + set of two letter country codes, or numeric country codes in ISO + 3166. + +3.1.2. Administration Management Domain (ADMD) + + The values of the ADMD field are decided on a national basis. Every + national decision made within the GO-MHS community shall be supported + by a GO-MD. + + + + + +Hagens & Hansen [Page 6] + +RFC 1649 X.400 Management in GO-MHS July 1994 + + +3.1.3. Private Management Domain (PRMD) + + The PRMD values should be unique within a country. + +3.1.4. Organization (O) + + Organization values shall be unique within the context of the + subscribed PRMD or ADMD if there is no PRMD. For clarification, the + following situation is legal: + + 1) C=FI; ADMD=FUMAIL; O=FUNET. + 2) C=FI; ADMD=FUMAIL; PRMD=NOKIA; O=FUNET. + + In this case 1) and 2) are different addreses. (Note that 2) at this + point is a hypotethical address). O=FUNET is a subscriber both at + ADMD=FUMAIL, 1), and at PRMD=NOKIA, 2). + +3.1.5. Organizational Units (OUs) + + If used, a unique hierarchy of OUs shall be implemented. The top + level OU is unique within the scope of the immediately superior + address element (i.e., Organization, PRMD or ADMD). Use of multiple + OUs may be confusing. + +3.1.6. Given Name, Initials, Surname (G I S) + + Each Organization can define its own Given-names, Initials, and + Surnames to be used within the Organization. In the cases when + Surnames are not unique within an O or OU, the Given-name and/or + Initial shall be used to identify the Originator/Recipient. In the + rare cases when more than one user would have the same combination of + G, I, S under the same O and/or OUs, each organization is free to + find a practical solution, and provide the users with unique O/R + addresses. + + Either one of Given-name or Initials should be used, not both. + Periods shall not be used in Initials. + + To avoid problems with the mapping of the X.400 addresses to RFC-822 + addresses, the following rules might be used. ADMD, PRMD, O, and OU + values should consist of characters drawn from the alphabet (A-Z), + digits (0-9), and minus. Blank or Space characters should be + avoided. No distinction is made between upper and lower case. The + last character shall not be a minus sign or period. The first + character should be either a letter or a digit (see reference [6] and + [7]). + + + + + +Hagens & Hansen [Page 7] + +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: user@cs.wisc.edu. + + 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: + + Firstname.Lastname@some.place.edu + + 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 + + + Firstname.Lastname@cpg.cdc.com + +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: +1 703 758 7700 + Fax: +1 703 758 7717 + EMail: hagens@ans.net + DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US + + + Alf Hansen + UNINETT + Elgesetergt. 10 + Postbox 6883, Elgeseter + N-7002 Trondheim + Norway + + Phone: +47 7359 2982 + Fax: +47 7359 6450 + EMail: Alf.Hansen@uninett.no + 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] + |