GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2163

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,
 e-mail User Agents or any other tool requiring the mapping rules to
 produce correct results.

Allocchio Standards Track [Page 2] RFC 2163 MIXER MCGAM January 1998

 Two much more efficient methods are proposed by MIXER for publication
 of MCGAM: the Internet DNS and X.500. This memo is the complete
 technical specification for publishing MCGAM via Internet DNS.
 A first proposal to use the Internet DNS to store, retrieve and
 maintain those mappings was introduced by two of the authors of
 RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record
 (RR)  types: TO-X400 and TO-822. This proposal now adopts a more
 complete strategy, and requires one new RR only. The distribution of
 MCGAMs via DNS is in fact an important service for the whole Internet
 community: it completes the information given by MX resource record
 and it allows to produce clean addresses when messages are exchanged
 among the Internet RFC822 world and the X.400 one (both Internet and
 Public X.400 service providers).
 A first experiment in using the DNS without expanding the current set
 of RR and using available ones was deployed by some of the authors of
 RFC1664 at the time of its development. The existing PTR resource
 records were used to store the mapping rules, and a new DNS tree was
 created under the ".it" top level domain. The result of the
 experiment was positive, and a few test applications ran under this
 provisional set up. This test was also very useful in order to define
 a possible migration strategy during the deployment of the new DNS
 containing the new RR. The Internet DNS nameservers wishing to
 provide this mapping information need in fact to be modified to
 support the new RR type, and in the real Internet, due to the large
 number of different implementations, this takes some time.
 The basic idea is to adopt a new DNS RR to store the mapping
 information. The RFC822 to X.400 mapping rules (including the so
 called 'gate2' rules) will be stored in the ordinary DNS tree, while
 the definition of a new branch of the name space defined under each
 national top level domain is envisaged in order to contain the X.400
 to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping
 resolution schema is thus fully implemented.
 The creation of the new domain name space representing the X.400 O/R
 names structure also provides the chance to use the DNS to distribute
 dynamically other X.400 related information, thus solving other
 efficiency problems currently affecting the X.400 MHS service.
 In this paper we will adopt the MCGAM syntax, showing how it can be
 stored into the Internet DNS.

Allocchio Standards Track [Page 3] RFC 2163 MIXER MCGAM January 1998

1.1 Definitions syntax

 The definitions in this document is given in BNF-like syntax, using
 the following conventions:
    |   means choice
    \   is used for continuation of a definition over several lines
    []  means optional
    {}  means repeated one or more times
 The definitions, however, are detailed only until a certain level,
 and below it self-explaining character text strings will be used.

2. Motivation

 Implementations of MIXER gateways require that a database store
 address mapping information for X.400 and RFC822. This information
 must be made available (published) to all MIXER gateways. In the
 Internet community, the DNS has proven to be a practical mean for
 providing a distributed name service. Advantages of using a DNS based
 system over a table based approach for mapping between O/R addresses
 and domain names are:
  1. It avoids fetching and storing of entire mapping tables by every

host that wishes to implement MIXER gateways and/or tools

  1. Modifications to the DNS based mapping information can be made

available in a more timely manner than with a table driven

     approach.
  1. It allows full authority delegation, in agreement with the

Internet regionalization process.

  1. Table management is not necessarily required for DNS-based

MIXER gateways.

  1. One can determine the mappings in use by a remote gateway by

querying the DNS (remote debugging).

 Also many other tools, like address converters and User Agents can
 take advantage of the real-time availability of MIXER tables,
 allowing a much easier maintenance of the information.

3. The domain space for X.400 O/R name addresses

 Usual domain names (the ones normally used as the global part of an
 RFC822 e-mail address) and their associated information, i.e., host
 IP addresses, mail exchanger names, etc., are stored in the DNS as a

Allocchio Standards Track [Page 4] RFC 2163 MIXER MCGAM January 1998

 distributed database under a number of top-level domains. Some top-
 level domains are used for traditional categories or international
 organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
 any country has its own two letter ISO country code as top-level
 domain (FR, DE, GB, IT, RU, ...), including "US" for USA.  The
 special top-level/second-level couple IN-ADDR.ARPA is used to store
 the IP address to domain name relationship. This memo defines in the
 above structure the appropriate way to locate the X.400 O/R name
 space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
 The MIXER mapping information is composed by four tables:
  1. 'table1' and 'gate1' gives the translation from X.400 to RFC822;
  2. 'table2' and 'gate2' tables map RFC822 into X.400.
 Each mapping table is composed by mapping rules, and a single mapping
 rule is composed by a keyword (the argument of the mapping function
 derived from the address to be translated) and a translator (the
 mapping function parameter):
                          keyword#translator#
 the '#' sign is a delimiter enclosing the translator. An example:
               foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
 Local mappings are not intended for use outside their restricted
 environment, thus they should not be included in DNS. If local
 mappings are used, they should be stored using static local tables,
 exactly as local static host tables can be used with DNS.
 The keyword of a 'table2' and 'gate2' table entry is a valid RFC822
 domain; thus the usual domain name space can be used without problems
 to store these entries.
 On the other hand, the keyword of a 'table1' and 'gate1' entry
 belongs to the X.400 O/R name space. The X.400 O/R name space does
 not usually fit into the usual domain name space, although there are
 a number of similarities; a new name structure is thus needed to
 represent it. This new name structure contains the X.400 mail
 domains.
 To ensure the correct functioning of the DNS system, the new X.400
 name structure must be hooked to the existing domain name space in a
 way which respects the existing name hierarchy.
 A possible solution was to create another special branch, starting
 from the root of the DNS tree, somehow similar to the in-addr.arpa
 tree. This idea would have required to establish a central authority

Allocchio Standards Track [Page 5] RFC 2163 MIXER MCGAM January 1998

 to coordinate at international level the management of each national
 X.400 name tree, including the X.400 public service providers. This
 coordination problem is a heavy burden if approached globally. More
 over the X.400 name structure is very 'country oriented': thus while
 it requires a coordination at national level, it does not have
 concepts like the international root. In fact the X.400 international
 service is based  on a large number of bilateral agreements, and only
 within some communities an international coordination service exists.
 The X.400 two letter ISO country codes, however, are the same used
 for the RFC822 country top-level domains and this gives us an
 appropriate hook to insert the new branches. The proposal is, in
 fact, to create under each national top level ISO country code a new
 branch in the name space. This branch represents exactly the X.400
 O/R name structure as defined in each single country, following the
 ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
 under each country top-level domain, and hence the national X.400
 name space derives its own structure:
                                  . (root)
                                  |
    +-----------------+-----------+--------+-----------------+...
    |                 |                    |                 |
   edu                it                   us                fr
    |                 |                    |                 |
+---+---+...    +-----+-----+...     +-----+-----+...     +--+---+...
|       |       |     |     |        |     |     |        |      |

… … cnr X42D infn va ca X42D X42D inria

                      |                    |     |        |
         +------------+------------+...   ...   ...  +----+-------+...
         |            |            |                 |            |
  ADMD-PtPostel  ADMD-garr  ADMD-Master400        ADMD-atlas  ADMD-red
                      |            |                 |            |
           +----------+----+...   ...        +-------+------+... ...
           |               |                 |              |
       PRMD-infn       PRMD-STET        PRMD-Telecom   PRMD-Renault
           |               |                 |              |
          ...             ...               ...            ...
 The creation of the X.400 new name tree at national level solves the
 problem of the international coordination. Actually the coordination
 problem is just moved at national level, but it thus becomes easier
 to solve. The coordination at national level between the X.400
 communities and the Internet world is already a requirement for the
 creation of the national static MIXER mapping tables; the use of the
 Internet DNS gives further motivations for this coordination.

Allocchio Standards Track [Page 6] RFC 2163 MIXER MCGAM January 1998

 The coordination at national level also fits in the new concept of
 MCGAM pubblication. The DNS in fact allows a step by step authority
 distribution, up to a final complete delegation: thus organizations
 whishing to publish their MCGAM just need to receive delegation also
 for their branch of the new X.400 name space. A further advantage of
 the national based solution is to allow each country to set up its
 own X.400 name structure in DNS and to deploy its own authority
 delegation according to its local time scale and requirements, with
 no loss of global service in the mean time. And last, placing the new
 X.400 name tree and coordination process at national level fits into
 the Internet regionalization and internationalisation process, as it
 requires local bodies to take care of local coordination problems.
 The DNS name space thus contains completely the information required
 by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
 simple query to the nearest nameserver provides it. Moreover there is
 no more any need to store, maintain and distribute manually any
 mapping table. The new X.400 name space can also contain further
 information about the X.400 community, as DNS allows for it a
 complete set of resource records, and thus it allows further
 developments. This set of RRs in the new X.400 name space must be
 considered 'reserved' and thus not used until further specifications.
 The construction of the new domain space trees will follow the same
 procedures used when organising at first the already existing DNS
 space: at first the information will be stored in a quite centralised
 way, and distribution of authority will be gradually achieved. A
 separate document will describe the implementation phase and the
 methods to assure a smooth introduction of the new service.

4. The new DNS resource record for MIXER mapping rules: PX

 The specification of the Internet DNS (RFC1035) provides a number of
 specific resource records (RRs) to contain specific pieces of
 information. In particular they contain the Mail eXchanger (MX) RR
 and the host Address (A) records which are used by the Internet SMTP
 mailers. As we will store the RFC822 to X.400 mapping information in
 the already existing DNS name tree, we need to define a new DNS RR in
 order to avoid any possible clash or misuse of already existing data
 structures. The same new RR will also be used to store the mappings
 from X.400 to RFC822. More over the mapping information, i.e., the
 MCGAMs, has a specific format and syntax which require an appropriate
 data structure and processing. A further advantage of defining a new
 RR is the ability to include flexibility for some eventual future
 development.

Allocchio Standards Track [Page 7] RFC 2163 MIXER MCGAM January 1998

 The definition of the new 'PX' DNS resource record is:
    class:        IN   (Internet)
    name:         PX   (pointer to X.400/RFC822 mapping information)
    value:        26
 The PX RDATA format is:
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                  PREFERENCE                   |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        /                    MAP822                     /
        /                                               /
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        /                    MAPX400                    /
        /                                               /
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 where:
 PREFERENCE   A 16 bit integer which specifies the preference given to
              this RR among others at the same owner.  Lower values
              are preferred;
 MAP822       A <domain-name> element containing <rfc822-domain>, the
              RFC822 part of the MCGAM;
 MAPX400      A <domain-name> element containing the value of
              <x400-in-domain-syntax> derived from the X.400 part of
              the MCGAM (see sect. 4.2);
 PX records cause no additional section processing. The PX RR format
 is the usual one:
           <name> [<class>] [<TTL>] <type> <RDATA>
 When we store in DNS a 'table1' or a 'gate1' entry, then <name> will
 be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we
 store a 'table2' or a 'gate2' table entry, <name> will be an RFC822
 mail domain name, including both fully qualified DNS domains and mail
 only domains (MX-only domains). All normal DNS conventions, like
 default values, wildcards, abbreviations and message compression,
 apply also for all the components of the PX RR. In particular <name>,
 MAP822 and MAPX400, as <domain-name> elements, must have the final
 "." (root) when they are fully qualified.

Allocchio Standards Track [Page 8] RFC 2163 MIXER MCGAM January 1998

4.1 Additional features of the PX resource record

 The definition of the RDATA for the PX resource record, and the fact
 that DNS allows a distinction between an exact value and a wildcard
 match for the <name> parameter, represent an extension of the MIXER
 specification for mapping rules. In fact, any MCGAM entry is an
 implicit wildcard entry, i.e., the rule
    net2.it#PRMD$net2.ADMD$p400.C$it#
 covers any RFC822 domain ending with 'net2.it', unless more detailed
 rules for some subdomain in 'net2.it' are present. Thus there is no
 possibility to specify explicitly a MCGAM as an exact match only
 rule. In DNS an entry like
  • .net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it.
 specify the usual wildcard match as for MIXER tables. However an
 entry like
    ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.
 is valid only for an exact match of 'ab.net2.it' RFC822 domain.
 Note also that in DNS syntax there is no '#' delimiter around MAP822
 and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not
 allow the <blank> (ASCII decimal 32) character within these fields,
 making unneeded the use of an explicit delimiter as required in the
 MIXER original syntax.
 Another extension to the MIXER specifications is the PREFERENCE value
 defined as part of the PX RDATA section. This numeric value has
 exactly the same meaning than the similar one used for the MX RR. It
 is thus possible to specify more than one single mapping for a domain
 (both from RFC822 to X.400 and vice versa), giving as the preference
 order. In MIXER static tables, however, you cannot specify more than
 one mapping per each RFC822 domain, and the same restriction apply
 for any X.400 domain mapping to an RFC822 one.
 More over, in the X.400 recommendations a note suggests than an
 ADMD=<blank> should be reserved for some special cases. Various
 national functional profile specifications for an X.400 MHS states
 that if an X.400 PRMD is reachable via any of its national ADMDs,
 independently of its actual single or multiple connectivity with
 them, it should use ADMD=<blank> to advertise this fact. Again, if a
 PRMD has no connections to any ADMD it should use ADMD=0 to notify
 its status, etc. However, in most of the current real situations, the
 ADMD service providers do not accept messages coming from their

Allocchio Standards Track [Page 9] RFC 2163 MIXER MCGAM January 1998

 subscribers if they have a blank ADMD, forcing them to have their own
 ADMD value. In such a situation there are problems in indicating
 properly the actually working mappings for domains with multiple
 connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
 take in consideration these problems.
 However, as these extensions are not available with MIXER static
 tables, it is strongly discouraged to use them when interworking with
 any table based gateway or application. The extensions were in fact
 introduced just to add more flexibility, like the PREFERENCE value,
  or they were already implicit in the DNS mechanism, like the
 wildcard specification. They should be used very carefully or just
 considered 'reserved for future use'. In particular, for current use,
 the PREFERENCE value in the PX record specification should be fixed
 to a value of 50, and only wildcard specifications should be used
 when specifying <name> values.

4.2 The DNS syntax for an X.400 'domain'

 The syntax definition of the MCGAM rules is defined in appendix F of
 that document. However that syntax is not very human oriented and
 contains a number of characters which have a special meaning in other
 fields of the Internet DNS. Thus in order to avoid any possible
 problem, especially due to some old DNS implementations still being
 used in the Internet, we define a syntax for the X.400 part of any
 MCGAM rules (and hence for any X.400 O/R name) which makes it
 compatible with a <domain-name> element, i.e.,
 <domain-name>    ::= <subdomain> | " "
 <subdomain>      ::= <label> | <label> "." <subdomain>
 <label>          ::= <alphanum>|
                      <alphanum> {<alphanumhyphen>} <alphanum>
 <alphanum>       ::= "0".."9" | "A".."Z" | "a".."z"
 <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
 (see RFC1035, section 2.3.1, page 8).  The legal character set for
 <label> does not correspond to the IA5 Printablestring one used in
 MIXER to define MCGAM rules. However a very simple "escape mechanism"
 can be applied in order to bypass the problem. We can in fact simply
 describe the X.400 part of a MCGAM rule format as:
   <map-rule>   ::= <map-elem> | <map-elem> { "." <map-elem> }
   <map-elem>   ::= <attr-label> "$" <attr-value>
   <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
   <attr-value> ::= " " | "@" | IA5-Printablestring

Allocchio Standards Track [Page 10] RFC 2163 MIXER MCGAM January 1998

 As you can notice <domain-name> and <map-rule> look similar, and also
 <label> and <map-elem> look the same. If we define the correct method
 to transform a <map-elem> into a <label> and vice versa the problem
 to write a MCGAM rule in <domain-name> syntax is solved.
 The RFC822 domain part of any MCGAM rule is of course already in
 <domain-name> syntax, and thus remains unchanged.
 In particular, in a 'table1' or 'gate1' mapping rule the 'keyword'
 value must be converted into <x400-in-domain-syntax> (X.400 mail DNS
 mail domain), while the 'translator' value is already a valid RFC822
 domain.  Vice versa in a 'table2' or 'gate2' mapping rule, the
 'translator' must be converted into <x400-in-domain-syntax>, while
 the 'keyword' is already a valid RFC822 domain.

4.2.1 IA5-Printablestring to <alphanumhyphen> mappings

 The problem of unmatching IA5-Printablestring and <label> character
 set definition is solved by a simple character mapping rule: whenever
 an IA5 character does not belong to <alphanumhyphen>, then it is
 mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
 small set of special rules is also defined for the most frequent
 cases. Moreover some frequent characters combinations used in MIXER
 rules are also mapped as special cases.
 Let's then define the following simple rules:
  MCGAM rule            DNS store translation    conditions
  -----------------------------------------------------------------
  <attr-label>$@        <attr-label>             missing attribute
  <attr-label>$<blank>  <attr-label>"b"          blank attribute
  <attr-label>$xxx      <attr-label>-xxx         elsewhere
 Non <alphanumhyphen> characters in <attr-value>:
  MCGAM rule            DNS store translation    conditions
  -----------------------------------------------------------------
  -                     -h-                      hyphen
  \.                    -d-                      quoted dot
  <blank>               -b-                      blank
  <non A/N character>   -<3digit-decimal>-       elsewhere
 If the DNS store translation of <attr-value> happens to end with an
 hyphen, then this last hyphen is omitted.
 Let's now have some examples:

Allocchio Standards Track [Page 11] RFC 2163 MIXER MCGAM January 1998

  MCGAM rule            DNS store translation    conditions
  -----------------------------------------------------------------
  PRMD$@                PRMD                     missing attribute
  ADMD$<blank>          ADMDb                    blank attribute
  ADMD$400-net          ADMD-400-h-net           hyphen mapping
  PRMD$UK\.BD           PRMD-UK-d-BD             quoted dot mapping
  O$ACME Inc\.          O-ACME-b-Inc-d           blank & final hyphen
  PRMD$main-400-a       PRMD-main-h-400-h-a      hyphen mapping
  O$-123-b              O--h-123-h-b             hyphen mapping
  OU$123-x              OU-123-h-x               hyphen mapping
  PRMD$Adis+co          PRMD-Adis-043-co         3digit mapping
 Thus, an X.400 part from a MCGAM like
   OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
 translates to
   OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
 Another example:
   OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
 translates to
   OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB

4.2.2 Flow chart

 In order to achieve the proper DNS store translations of the X.400
 part of a MCGAM or any other X.400 O/R name, some software tools will
 be used. It is in fact evident that the above rules for converting
 mapping table from MIXER to DNS format (and vice versa) are not user
 friendly enough to think of a human made conversion.
 To help in designing such tools, we describe hereunder a small flow
 chart. The fundamental rule to be applied during translation is,
 however, the following:
    "A string must be parsed from left to right, moving appropriately
    the pointer in order not to consider again the already translated
    left section of the string in subsequent analysis."

Allocchio Standards Track [Page 12] RFC 2163 MIXER MCGAM January 1998

 Flow chart 1 - Translation from MIXER to DNS format:
               parse  single attribute
            (enclosed in "." separators)
                         |
          (yes)  ---  <label>$@ ?  ---  (no)
            |                             |
      map to <label>        (no)  <label>$<blank> ?  (yes)
            |                 |                        |
            |           map to <label>-        map to <label>"b"
            |                 |                        |
            |           map "\." to -d-                |
            |                 |                        |
            |           map "-" to -h-                 |
            |                 |                        |
            |    map non A/N char to -<3digit>-        |
restart     |                 |                        |
   ^        |      remove (if any) last "-"            |
   |        |                 |                        |
   |        \------->     add a  "."    <--------------/
   |                          |
   \----------  take  next  attribute  (if  any)
 Flow chart 2 - Translation from DNS to MIXER format:
              parse single attribute
          (enclosed in "." separators)
                        |
          (yes) ---- <label> ? ---- (no)
            |                          |
    map to <label>$@        (no) <label>"b" ? (yes)
            |                 |                 |
            |           map to <label>$    map to <label>$<blank>
            |                 |                 |
            |           map -d- to "\."         |
            |                 |                 |
            |           map -h- to "-"          |
            |                 |                 |
            |           map -b- to " "          |
restart     |                 |                 |
   ^        |   map -<3digit>- to non A/N char  |
   |        |                 |                 |
   |        \-------->   add a "."   <----------/
   |                         |
   \------------- take next attribute (if any)

Allocchio Standards Track [Page 13] RFC 2163 MIXER MCGAM January 1998

 Note that the above flow charts deal with the translation of the
 attributes syntax, only.

4.2.3 The Country Code convention in the <name> value.

 The RFC822 domain space and the X.400 O/R address space, as said in
 section 3, have one specific common feature: the X.400 ISO country
 codes are the same as the RFC822 ISO top level domains for countries.
 In the previous sections we have also defined a method to write in
 <domain-name> syntax any X.400 domain, while in section 3 we
 described the new name space starting at each country top level
 domain under the X42D.cc (where 'cc' is then two letter ISO country
 code).
 The <name> value for a 'table1' or 'gate1' entry in DNS should thus
 be derived from the X.400 domain value, translated to <domain-name>
 syntax, adding the 'X42D.cc.' post-fix to it, i.e.,
   ADMD$acme.C$fr
 produces in <domain-name> syntax the key:
   ADMD-acme.C-fr
 which is post-fixed by 'X42D.fr.' resulting in:
   ADMD-acme.C-fr.X42D.fr.
 However, due to the identical encoding for X.400 country codes and
 RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
 clearly redundant.
 We thus define the 'Country Code convention' for the <name> key,
 i.e.,
   "The C-cc section of an X.400 domain in <domain-name> syntax must
   be omitted when creating a <name> key, as it is identical to the
   top level country code used to identify the DNS zone where the
   information is stored".
 Thus we obtain the following <name> key examples:
 X.400 domain                       DNS <name> key
 --------------------------------------------------------------------
 ADMD$acme.C$fr                     ADMD-acme.X42D.fr.
 PRMD$ux\.av.ADMD$ .C$gb            PRMD-ux-d-av.ADMDb.X42D.gb.
 PRMD$ppb.ADMD$Dat 400.C$de         PRMD-ppb.ADMD-Dat-b-400.X42D.de.

Allocchio Standards Track [Page 14] RFC 2163 MIXER MCGAM January 1998

4.3 Creating the appropriate DNS files

 Using MIXER's assumption of an asymmetric mapping between X.400 and
 RFC822 addresses, two separate relations are required to store the
 mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS
 we will maintain the two different sections, even if they will both
 use the PX resource record. More over MIXER also specify two
 additional tables: MIXER 'gate1' and 'gate2' tables. These additional
 tables, however, have the same syntax rules than MIXER 'table1' and
 'table2' respectively, and thus the same translation procedure as
 'table1' and 'table2' will be applied; some details about the MIXER
 'gate1' and 'gate2' tables are discussed in section 4.4.
 Let's now check how to create, from an MCGAM entry, the appropriate
 DNS entry in a DNS data file. We can again define an MCGAM entry as
 defined in appendix F of that document as:
   <x400-domain>#<rfc822-domain>#  (case A: 'table1' and 'gate1'
   entry)
 and
   <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate2'
   entry)
 The two cases must be considered separately. Let's consider case A.
  1. take <x400-domain> and translate it into <domain-name> syntax,

obtaining <x400-in-domain-syntax>;

  1. create the <name> key from <x400-in-domain-syntax> i.e., apply

the Country Code convention described in sect. 4.2.3;

  1. construct the DNS PX record as:
  • .<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax>
 Please note that within PX RDATA the <rfc822-domain> precedes the
 <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry.
 an example: from the 'table1' rule
   PRMD$ab.ADMD$ac.C$fr#ab.fr#
 we obtain
  • .PRMD-ab.ADMD-ac.X42D.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr.
 Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
 fully qualified <domain-name> elements, thus ending with a ".".

Allocchio Standards Track [Page 15] RFC 2163 MIXER MCGAM January 1998

 Let's now consider case B.
  1. take <rfc822-domain> as <name> key;
  2. translate <x400-domain> into <x400-in-domain-syntax>;
  3. construct the DNS PX record as:
  • .<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax>
 an example: from the 'table2' rule
   ab.fr#PRMD$ab.ADMD$ac.C$fr#
 we obtain
  • .ab.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr.
 Again note the fully qualified <domain-name> elements.
 A file containing the MIXER mapping rules and MIXER 'gate1' and
 'gate2' table written in DNS format will look like the following
 fictious example:
   !
   ! MIXER table 1: X.400 --> RFC822
   !
   *.ADMD-acme.X42D.it.               IN  PX  50  it. ADMD-acme.C-it.
   *.PRMD-accred.ADMD-tx400.X42D.it.  IN  PX  50   \
                              accred.it. PRMD-accred.ADMD-tx400.C-it.
   *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it.  IN  PX  50   \
                     cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
   !
   ! MIXER table 2: RFC822 --> X.400
   !
   *.nrc.it.    IN  PX  50   nrc.it. PRMD-nrc.ADMD-acme.C-it.
   *.ninp.it.   IN  PX  50   ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
   *.bd.it.     IN  PX  50   bd.it. PRMD-uk-d-bd.ADMDb.C-it.
   !
   ! MIXER Gate 1 Table
   !
   *.ADMD-XKW-h-Mail.X42D.it.         IN  PX  50   \
                          XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
   *.PRMD-Super-b-Inc.ADMDb.X42D.it.  IN  PX  50   \
                          GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
   !
   ! MIXER Gate 2 Table
   !
   my.it.  IN PX 50  my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
   co.it.  IN PX 50  co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.

Allocchio Standards Track [Page 16] RFC 2163 MIXER MCGAM January 1998

 (here the "\" indicates continuation on the same line, as wrapping is
 done only due to typographical reasons).
 Note the special suffix ".G." on the right side of the 'gate1' and
 'gate2' Tables section whose aim is described in section 4.4. The
 corresponding MIXER tables are:
   #
   # MIXER table 1: X.400 --> RFC822
   #
   ADMD$acme.C$it#it#
   PRMD$accred.ADMD$tx400.C$it#accred.it#
   O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
   #
   # MIXER table 2: RFC822 --> X.400
   #
   nrc.it#PRMD$nrc.ADMD$acme.C$it#
   ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
   bd.it#PRMD$uk\.bd.ADMD$ .C$it#
   #
   # MIXER Gate 1 Table
   #
   ADMD$XKW-Mail.C$it#XKW-gateway.it#
   PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
   #
   # MIXER Gate 2 Table
   #
   my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
   co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#

4.4 Storing the MIXER 'gate1' and 'gate2' tables

 Section 4.3.4 of MIXER also specify how an address should be
 converted between RFC822 and X.400 in case a complete mapping is
 impossible. To allow the use of DDAs for non mappable domains, the
 MIXER 'gate2' table is thus introduced.
 In a totally similar way, when an X.400 address cannot be completely
 converted in RFC822, section 4.3.5 of MIXER specifies how to encode
 (LHS encoding) the address itself, pointing then to the appropriate
 MIXER conformant gateway, indicated in the MIXER 'gate1' table.
 DNS must store and distribute also these 'gate1' and 'gate2' data.
 One of the major features of the DNS is the ability to distribute the
 authority: a certain site runs the "primary" nameserver for one
 determined sub-tree and thus it is also the only place allowed to
 update information regarding that sub-tree. This fact allows, in our

Allocchio Standards Track [Page 17] RFC 2163 MIXER MCGAM January 1998

 case, a further additional feature to the table based approach. In
 fact we can avoid one possible ambiguity about the use of the 'gate1'
 and 'gate2' tables (and thus of LHS and DDAs encoding).
 The authority maintaining a DNS entry in the usual RFC822 domain
 space is the only one allowed to decide if its domain should be
 mapped using Standard Attributes (SA) syntax or Domain Defined
 Attributes (DDA) one. If the authority decides that its RFC822 domain
 should be mapped using SA, then the PX RDATA will be a 'table2'
 entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822
 domain we cannot have any more two possible entries, one from 'table2
 and another one from 'gate2' table, and the action for a gateway
 results clearly stated.
 Similarly, the authority mantaining a DNS entry in the new X.400 name
 space is the only one allowed to decide if its X.400 domain should be
 mapped using SA syntax or Left Hand Side (LHS) encoding. If the
 authority decides that its X.400 domain should be mapped using SA,
 then the PX RDATA will be a 'table1' entry, otherwise it will be a
 'gate1' table entry. Thus also for an X.400 domain we cannot have any
 more two possible entries, one from 'table1' and another one from
 'gate1' table, and the action for a gateway results clearly stated.
 The MIXER 'gate1' table syntax is actually identical to MIXER
 'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
 Thus the same syntax translation rules from MIXER to DNS format can
 be applied in both cases. However a gateway or any other application
 must know if the answer it got from DNS contains some 'table1',
 'table2' or some 'gate1', 'gate2' table information. This is easily
 obtained flagging with an additional ".G." post-fix the PX RDATA
 value when it contains a 'gate1' or 'gate2' table entry. The example
 in section 4.3 shows clearly the result. As any X.400 O/R domain must
 end with a country code ("C-xx" in our DNS syntax) the additional
 ".G." creates no conflicts or ambiguities at all. This postfix must
 obviously be removed before using the MIXER 'gate1' or 'gate2' table
 data.

5. Finding MIXER mapping information from DNS

 The MIXER mapping information is stored in DNS both in the normal
 RFC822 domain name space, and in the newly defined X.400 name space.
 The information, stored in PX resource records, does not represent a
 full RFC822 or X.400 O/R address: it is a template which specifies
 the fields of the domain that are used by the mapping algorithm.
 When mapping information is stored in the DNS, queries to the DNS are
 issued whenever an iterative search through the mapping table would
 be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping

Allocchio Standards Track [Page 18] RFC 2163 MIXER MCGAM January 1998

 B). Due to the DNS search mechanism, DNS by itself returns the
 longest possible match in the stored mapping rule with a single
 query, thus no iteration and/or multiple queries are needed. As
 specified in MIXER, a search of the mapping table will result in
 either success (mapping found) or failure (query failed, mapping not
 found).
 When a DNS query is issued, a third possible result is timeout. If
 the result is timeout, the gateway operation is delayed and then
 retried at a later time. A result of success or failure is processed
 according to the algorithms specified in MIXER. If a DNS error code
 is returned, an error message should be logged and the gateway
 operation is delayed as for timeout. These pathological situations,
 however, should be avoided with a careful duplication and chaching
 mechanism which DNS itself provides.
 Searching the nameserver which can authoritatively solve the query is
 automatically performed by the DNS distributed name service.

5.1 A DNS query example

 An MIXER mail-gateway located in the Internet, when translating
 addresses from RFC822 to X.400, can get information about the MCGAM
 rule asking the DNS. As an example, when translating the address
 SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX
 resource record. The DNS should contain a PX record like this:
  • .cce.nrc.it. IN PX 50 cce.nrc.it. O-cce.PRMD-nrc.ADMD-acme.C-it.
 The first query will return immediately the appropriate mapping rule
 in DNS store format.
 There is no ".G." at the end of the obtained PX RDATA value, thus
 applying the syntax translation specified in paragraph 4.2 the MIXER
 Table 2 mapping rule will be obtained.
 Let's now take another example where a 'gate2' table rule is
 returned.  If we are looking for an RFC822 domain ending with top
 level domain "MW", and the DNS contains a PX record like this,
  • .mw. IN PX 50 mw. O-cce.PRMD-nrc.ADMD-acme.C-it.G.
 DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
 'gate2' table entry in DNS store format. Dropping the final ".G." and
 applying the syntax translation specified in paragraph 4.2 the
 original rule will be available. More over, the ".G." flag also tells
 the gateway to use DDA encoding for the inquired RFC822 domain.

Allocchio Standards Track [Page 19] RFC 2163 MIXER MCGAM January 1998

 On the other hand, translating from X.400 to RFC822 the address
    C=de; ADMD=pkz; PRMD=nfc; O=top;
 the mail gateway should convert the syntax according to paragraph
 4.2, apply the 'Country code convention' described in 4.2.3 to derive
 the appropriate DNS translation of the X.400 O/R name and then query
 DNS for the corresponding PX resource record. The obtained record for
 which the PX record must be queried is thus:
    O-top.PRMD-nfc.ADMD-pkz.X42D.de.
 The DNS could contain:
  • .ADMD-pkz.X42D.de. IN PX 50 pkz.de. ADMD-pkz.C-de.
 Assuming that there are not more specific records in DNS, the
 wildcard mechanism will return the MIXER 'table1' rule in encoded
 format.
 Finally, an example where a 'gate1' rule is involved. If we are
 looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the
 DNS contains a PX record like this,
  • .ADMD-PWT400.X42D.us. IN PX 50 intGw.com. ADMD-PWT400.C-us.G.
 DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a
 'gate1' table entry in DNS store format. Dropping the final ".G." and
 applying the syntax translation specified in paragraph 4.2 the
 original rule will be available. More over, the ".G." flag also tells
 the gateway to use LHS encoding for the inquired X.400 domain.

6. Administration of mapping information

 The DNS, using the PX RR, is able to distribute the MCGAM rules to
 all MIXER gateways located on the Internet. However, not all MIXER
 gateways will be able to use the Internet DNS. It is expected that
 some gateways in a particular management domain will conform to one
 of the following models:
   (a) Table-based, (b) DNS-based, (c) X.500-based
 Table-based management domains will continue to publish their MCGAM
 rules and retrieve the mapping tables via the International Mapping
 Table coordinator, manually or via some automated procedures. Their
 MCGAM information can be made available also in DNS by the
 appropriate DNS authorities, using the same mechanism already in
 place for MX records: if a branch has not yet in place its own DNS

Allocchio Standards Track [Page 20] RFC 2163 MIXER MCGAM January 1998

 server, some higher authority in the DNS tree will provide the
 service for it. A transition procedure similar to the one used to
 migrate from the 'hosts.txt' tables to DNS can be applied also to the
 deployment phase of this specification. An informational document
 describing the implementation phase and the detailed coordination
 procedures is expected.
 Another distributed directory service which can distribute the MCGAM
 information is X.500. Coordination with table-based domains can be
 obtained in an identical way as for the DNS case.
 Coordination of MCGAM information between DNS and X.500 is more
 complex, as it requies some kind of uploading information between the
 two systems. The ideal solution is a dynamic alignment mechanism
 which transparently makes the DNS mapping information available in
 X.500 and vice versa. Some work in this specific field is already
 being done [see Costa] which can result in a global transparent
 directory service, where the information is stored in DNS or in
 X.500, but is visible completely by any of the two systems.
 However we must remind that MIXER concept of MCGAM rules publication
 is different from the old RFC1327 concept of globally distributed,
 coordinated and unique mapping rules. In fact MIXER does not requires
 any more for any conformant gateway or tool to know the complete set
 of MCGAM: it only requires to use some set (eventually empty) of
 valid MCGAM rules, published either by Tables, DNS or X.500
 mechanisms or any combination of these methods. More over MIXER
 specifies that also incomplete sets of MCGAM can be used, and
 supplementary local unpublished (but valid) MCGAM can also be used.
 As a consequence, the problem of coordination between the three
 systems proposed by MIXER for MCGAM publication is non essential, and
 important only for efficient operational matters. It does not in fact
 affect the correct behaviour of MIXER conformant gateways and tools.

7. Conclusion

 The introduction of the new PX resource record and the definition of
 the X.400 O/R name space in the DNS structure provide a good
 repository for MCGAM information. The mapping information is stored
 in the DNS tree structure so that it can be easily obtained using the
 DNS distributed name service. At the same time the definition of the
 appropriate DNS space for X.400 O/R names provide a repository where
 to store and distribute some other X.400 MHS information. The use of
 the DNS has many known advantages in storing, managing and updating
 the information. A successful number of tests were been performed
 under the provisional top level domain "X400.IT" when RFC1664 was
 developed, and their results confirmed the advantages of the method.
 Operational exeprience for over 2 years with RFC1664 specification

Allocchio Standards Track [Page 21] RFC 2163 MIXER MCGAM January 1998

 confirmed the feasibility of the method, and helped identifying some
 operational procedures to deploy the insertion of MCGAM into DNS.
 Software to query the DNS and then to convert between the textual
 representation of DNS resource records and the address format defined
 in MIXER was developed with RFC1664. This software also allows a
 smooth implementation and deployment period, eventually taking care
 of the transition phase. This software can be easily used (with
 little or null modification) also for this updated specification,
 supporting the new 'gate1' MIXER table. DNS software implementations
 supporting RFC1664 also supports with no modification this memo new
 specification.

Allocchio Standards Track [Page 22] RFC 2163 MIXER MCGAM January 1998

 A further informational document describing operational and
 implementation of the service is expected.

8. Acknowledgements

 We wish to thanks all those who contributed to the discussion and
 revision of this document: many of their ideas and suggestions
 constitute essential parts of this work. In particular thanks to Jon
 Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
 TERENA wg-msg and IETF namedroppers groups. A special mention to
 Christian Huitema for his fundamental contribution to this work.
 This document is a revision of RFC1664, edited by one of its authors
 on behalf of the IETF MIXER working group. The current editor wishes
 to thank here also the authors of RFC1664:
   Antonio Blasco Bonito     RFC822: bonito@cnuce.cnr.it
   CNUCE - CNR               X.400:  C=it;A=garr;P=cnr;
   Reparto infr. reti                O=cnuce;S=bonito;
   Viale S. Maria 36
   I 56126 Pisa
   Italy
   Bruce Cole                RFC822: bcole@cisco.com
   Cisco Systems Inc.        X.400:  C=us;A= ;P=Internet;
   P.O. Box 3075                     DD.rfc-822=bcole(a)cisco.com;
   1525 O'Brien Drive
   Menlo Park, CA 94026
   U.S.A.
   Silvia Giordano           RFC822: giordano@cscs.ch
   Centro Svizzero di        X.400:  C=ch;A=arcom;P=switch;O=cscs;
   Calcolo Scientifico               S=giordano;
   Via Cantonale
   CH 6928 Manno
   Switzerland
   Robert Hagens                   RFC822: hagens@ans.net
   Advanced Network and Services   X.400:  C=us;A= ;P=Internet;
   1875 Campus Commons Drive               DD.rfc-822=hagens(a)ans.net;
   Reston, VA 22091
   U.S.A.

Allocchio Standards Track [Page 23] RFC 2163 MIXER MCGAM January 1998

9. References

 [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
     Systems: System Model - Service Elements", October 1988.
 [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
     822", RFC 1327, March 1992.
 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
     STD 13, RFC 1034, USC/Information Sciences Institute, November
     1987.
 [RFC 1035] Mockapetris, P., "Domain names - Implementation and
     Specification", STD 13, RFC 1035, USC/Information Sciences
     Institute, November 1987.
 [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
     1033, SRI International, November 1987.
 [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
     Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
     January 1998.
 [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
     Managing DNS Information in the X.500 Directory", Proceeding of
     the 4th Joint European Networking Conference, Trondheim, NO, May
     1993.

10. Security Considerations

 This document specifies a means by which DNS "PX" records can direct
 the translation between X.400 and Internet mail addresses.
 This can indirectly affect the routing of mail across an gateway
 between X.400 and Internet Mail.  A succesful attack on this service
 could cause incorrect translation of an originator address (thus
 "forging" the originator address), or incorrect translation of a
 recipient address (thus directing the mail to an unauthorized
 recipient, or making it appear to an authorized recipient, that the
 message was intended for recipients other than those chosen by the
 originator) or could force the mail path via some particular gateway
 or message transfer agent where mail security can be affected by
 compromised software.

Allocchio Standards Track [Page 24] RFC 2163 MIXER MCGAM January 1998

 There are several means by which an attacker might be able to deliver
 incorrect PX records to a client.  These include: (a) compromise of a
 DNS server,  (b) generating a counterfeit response to a client's DNS
 query, (c) returning incorrect "additional information" in response
 to an unrelated query.
 Clients using PX records SHOULD ensure that routing and address
 translations are based only on authoritative answers.  Once DNS
 Security mechanisms [RFC 2065] become more widely deployed, clients
 SHOULD employ those mechanisms to verify the authenticity and
 integrity of PX records.

11. Author's Address

 Claudio Allocchio
 Sincrotrone Trieste
 SS 14 Km 163.5 Basovizza
 I 34012 Trieste
 Italy
 RFC822: Claudio.Allocchio@elettra.trieste.it
 X.400:  C=it;A=garr;P=Trieste;O=Elettra;
 S=Allocchio;G=Claudio;
 Phone:  +39 40 3758523
 Fax:    +39 40 3758565

Allocchio Standards Track [Page 25] RFC 2163 MIXER MCGAM January 1998

12. Full Copyright Statement

 Copyright (C) The Internet Society (1998).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Allocchio Standards Track [Page 26]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2163.txt · Last modified: 1998/01/08 00:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki