rfc2163.txt

bind 9.3结合mysql数据库

   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]