rfc1664.txt

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

   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



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


   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 RFC1327 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
   RFC1327 mapping rules, 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.

   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:



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


   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 RFC1327 mapping information;

   MAPX400      A <domain-name> element containing the value of
                <x400-in-domain-syntax> derived from the X.400 part of
                the RFC1327 mapping information (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' 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 'gate' 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.

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 RFC1327
   specification for mapping rules. In fact, any RFC1327 mapping table
   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 an RFC1327 entry 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 RFC1327 tables. However an
   entry like

      ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.




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


   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
   RFC1327 original syntax.

   Another extension to the RFC1327 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 RFC1327 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
   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 RFC1327 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 RFC1327 mapping 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



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


   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 RFC1327 mapping 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
   RFC1327 to define mapping 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 an RFC1327 mapping 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

   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 an RFC1327 mapping rule in <domain-name> syntax is solved.

   The RFC822 domain part of any RFC1327 mapping rule is of course
   already in <domain-name> syntax, and thus remains unchanged.

   In particular, in a 'table1' 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 'gate' 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 RFC1327



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


   rules are also mapped as special cases.

   Let's then define the following simple rules:

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

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

    RFC1327 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 an RFC1327 mapping rule 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




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


   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 an RFC1327 mapping rules 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 RFC1327 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."

   Flow chart 1 - Translation from RFC1327 to DNS format: