Network Working Group C. Allocchio
Request for Comments: 2163 GARR-Italy
Obsoletes: 1664 January 1998
Category: Standards Track
Using the Internet DNS to Distribute
MIXER Conformant Global Address Mapping (MCGAM)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This memo is the complete technical specification to store in the
Internet Domain Name System (DNS) the mapping information (MCGAM)
needed by MIXER conformant e-mail gateways and other tools to map
RFC822 domain names into X.400 O/R names and vice versa. Mapping
information can be managed in a distributed rather than a centralised
way. Organizations can publish their MIXER mapping or preferred
gateway routing information using just local resources (their local
DNS server), avoiding the need for a strong coordination with any
centralised organization. MIXER conformant gateways and tools located
on Internet hosts can retrieve the mapping information querying the
DNS instead of having fixed tables which need to be centrally updated
and distributed.
This memo obsoletes RFC1664. It includes the changes introduced by
MIXER specification with respect to RFC1327: the new 'gate1' (O/R
addresses to domain) table is fully supported. Full backward
compatibility with RFC1664 specification is mantained, too.
RFC1664 was a joint effort of IETF X400 operation working group
(x400ops) and TERENA (formely named "RARE") Mail and Messaging
working group (WG-MSG). This update was performed by the IETF MIXER
working group.
Allocchio Standards Track [Page 1]
RFC 2163 MIXER MCGAM January 1998
1. Introduction
The connectivity between the Internet SMTP mail and other mail
services, including the Internet X.400 mail and the commercial X.400
service providers, is assured by the Mail eXchanger (MX) record
information distributed via the Internet Domain Name System (DNS). A
number of documents then specify in details how to convert or encode
addresses from/to RFC822 style to the other mail system syntax.
However, only conversion methods provide, via some algorithm or a set
of mapping rules, a smooth translation, resulting in addresses
indistinguishable from the native ones in both RFC822 and foreign
world.
MIXER describes a set of mappings (MIXER Conformant Global Address
Mapping - MCGAM) which will enable interworking between systems
operating the CCITT X.400 (1984/88/92) Recommendations and systems
using using the RFC822 mail protocol, or protocols derived from
RFC822. That document addresses conversion of services, addresses,
message envelopes, and message bodies between the two mail systems.
This document is concerned with one aspect of MIXER: the mechanism
for mapping between X.400 O/R addresses and RFC822 domain names. As
described in Appendix F of MIXER, implementation of the mappings
requires a database which maps between X.400 O/R addresses and domain
names; in RFC1327 this database was statically defined.
The original approach in RFC1327 required many efforts to maintain
the correct mapping: all the gateways needed to get coherent tables
to apply the same mappings, the conversion tables had to be
distributed among all the operational gateways, and also every update
needed to be distributed.
The concept of mapping rules distribution and use has been revised in
the new MIXER specification, introducing the concept of MIXER
Conformant Global Address Mapping (MCGAM). A MCGAM does not need to
be globally installed by any MIXER conformant gateway in the world
any more. However MIXER requires now efficient methods to publish its
MCGAM.
Static tables are one of the possible methods to publish MCGAM.
However this static mechanism requires quite a long time to be spent
modifying and distributing the information, putting heavy constraints
on the time schedule of every update. In fact it does not appear
efficient compared to the Internet Domain Name Service (DNS). More
over it does not look feasible to distribute the database to a large
number of other useful applications, like local address converters,
datatracker.ietf.org