rfc1664.txt

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

                 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)







Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 12]

RFC 1664          Internet DNS for Mail Mapping Tables       August 1994


   Flow chart 2 - Translation from DNS to RFC1327 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)


   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' 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



Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 13]

RFC 1664          Internet DNS for Mail Mapping Tables       August 1994


   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.

4.3 Creating the appropriate DNS files

   Using RFC1327's assumption of an asymmetric mapping between X.400 and
   RFC822 addresses, two separate relations are required to store the
   mapping database: RFC1327 'table1' and RFC1327 'table2'; thus also in
   DNS we will maintain the two different sections, even if they will
   both use the PX resource record. More over RFC1327 also specify a
   third table: RFC1327 'gate' Table. This additional table, however,
   has the same syntax rules than RFC1327 'table2' and thus the same
   translation procedure as 'table2' will be applied; some details about
   the RFC1327 'gate' table are discussed in section 4.4.

   Let's now check how to create, from an RFC1327 mapping rule entry,
   the appropriate DNS entry in a DNS data file. We can again define an
   RFC1327 mapping rule entry as defined in appendix F of that document
   as:

     <x400-domain>#<rfc822-domain>#  (case A: 'table1' entry)

   and

     <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate' entry)

   The two cases must be considered separately. Let's consider case A.



Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 14]

RFC 1664          Internet DNS for Mail Mapping Tables       August 1994


    - take <x400-domain> and translate it into <domain-name> syntax,
      obtaining <x400-in-domain-syntax>;
    - create the <name> key from <x400-in-domain-syntax> i.e., apply
      the Country Code convention described in sect. 4.2.3;
    - 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' entry.

   an example: from the 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 ".".

   Let's now consider case B.

    - take <rfc822-domain> as <name> key;
    - translate <x400-domain> into <x400-in-domain-syntax>;
    - construct the DNS PX record as:

     *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>

   an example: from the 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.












Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 15]

RFC 1664          Internet DNS for Mail Mapping Tables       August 1994


   A file containing the RFC1327 mapping rules and RFC1327 'gate' table
   written in DNS format will look like the following fictious example:

     !
     ! RFC1327 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.
     !
     ! RFC1327 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.
     !
     ! RFC1327 Gate 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.

   (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 'gate' Table
   section whose aim is described in section 4.4. The corresponding
   RFC1327 tables are:


     #
     # RFC1327 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#
     #
     # RFC1327 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#
     #
     # RFC1327 Gate Table
     #
     my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
     co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#



Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 16]

RFC 1664          Internet DNS for Mail Mapping Tables       August 1994


4.4 Storing the RFC1327 Gate table

   Section 4.3.4 of RFC1327 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
   RFC1327 'gate' table is thus introduced. DNS must store and
   distribute also these 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
   case, a further additional feature to the table based approach. In
   fact we can avoid one possible ambiguity about the use of the 'gate'
   table (and thus of 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 'gate' table entry. Thus for an RFC822
   domain we cannot have any more two possible entries, one from 'table2
   and another one from 'gate' table, and the action for a gateway
   results clearly stated.

   The RFC1327 'gate' table syntax is actually identical to RFC1327
   'table2'. Thus the same syntax translation rules from RFC1327 to DNS
   format can be applied. However a gateway or any other application
   must know if the answer it got from DNS contains some 'table2' or
   some 'gate' table information. This is easily obtained flagging with
   an additional ".G." post-fix the PX RDATA value when it contains a
   'gate' 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 RFC1327 'gate' table data.

5. Finding RFC1327 mapping information from DNS

   The RFC1327 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



Allocchio, Bonito, Cole, Giordano & Hagens                     [Page 17]

RFC 1664          Internet DNS for Mail Mapping Tables       August 1994


   be performed (RFC1327: section 4.3.4, State I; section 4.3.5, mapping
   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 RFC1327, 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