X400 Operations Working Group                        September 1992
     Request for Comments:  DRAFT v3.0
 
 
       Using the Internet DNS to maintain RFC1327 Address Mapping Tables
                         and X.400 Routing Informations
 
                Claudio Allocchio (Allocchio@elettra.trieste.it)
                     A. Blasco Bonito (blasco@cnuce.cnr.it)
                         Bruce Cole (cole@cs.wisc.edu)
                    Silvia Giordano (Giordano@cnuce.cnr.it)
                       Robert Hagens (hagens@cs.wisc.edu)
 
                     GARR-Italy & Wisconsin University CC-US
 
 
     0.  Status of this memo
 
     This memo proposes a method of storing in  the  Internet  Domain  Name
     System the information needed by RFC1327 e-mail gateways to map RFC822
     domain names into X.400 OR-names and viceversa.   Mapping  information
     can  be  managed  in  a  distributed  rather  than  a centralized way.
     Gateways  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.   A  proposal  about  storing
     also  X.400  routing  informations into the Internet DNS is presented,
     too.   This  document  specify  an  experimental  standard   proposal.
     Distribution of this memo is unlimited.
 
     This  document is an  Internet Draft.   Internet  Drafts  are  working 
     documents  of the  Internet Engineering  Task Force (IETF), its Areas, 
     and its  Working Groups.  Note that  other groups  may also distribute
     working documents as Internet Drafts. 
 
     Internet  Drafts  are draft  documents  valid  for  a  maximum  of six 
     months.  Internet  Drafts  may  be  updated,  replaced,  or  obsoleted
     by  other  documents  at  any  time.   It  is  not appropriate  to use
     Internet  Drafts  as  reference  material  or to  cite them other than
     as a "working draft" or "work in progress."
 
     Please check the I-D abstract listing contained in each Internet Draft 
     directory to  learn the current  status  of this or any other Internet
     Draft.
 
     0.1 Document Expiration Date
 
     This document was submitted on September 23rd, 1992 and its validity
     will expire on March 23rd 1993.
 
 
 
 
 
 
     1.  Introduction
 
     RFC1327 describes a set of mappings between the X.400 (1984/88) series
     of  protocols  and 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 RFC1327:  the  mechanism
     for  mapping  between X.400 O/R addresses and RFC822 domain names.  As
     described in Appendix F of RFC1327,  implementation  of  the  mappings
     requires  a database which maps between X.400 O/R addresses and domain
     names, and this database is statically defined.
 
     This approach requires many efforts to maintain the  correct  mapping:
     all  the  gateways  need  to  get  coherent  tables  to apply the same
     mappings, the conversion tables must  be  distributed  among  all  the
     operational  gateways,  and also every update needs to be distributed.
     This static mechanism requires quite  a  long  time  to  be  spent  in
     modifying   and   distributing   these   informations,  putting  heavy
     constraints on the time schedule of every update.  In fact it does not
     appear efficient compared to the Internet distributed name service.
 
     A first proposal to use  the  Internet  DNS  to  store,  retrieve  and
     maintain those mappings was introduced by two of the authors (B.  Cole
     and R.  Hagens) adopting two new DNS resource record  types:   TO-X400
     and  TO-822.   However  there  was a critical point:  the Internet DNS
     nameservers wishing to provide this mapping information needed  to  be
     modified  to support those new resource record types and a new address
     class.  In the real Internet, those modifications cold not  really  be
     accomplished on a significant number of operational DNS servers within
     a reasonable time period.  This new proposal tries to bypass the above
     problem.
 
     The basic idea is to use an already defined,  commonly  available  DNS
     resource- records type to store the mapping information.  In addition,
     the use of a new domain name space is  envisaged  in  order  to  fully
     implement a "two-way" mapping resolution scheme.
 
     The creation of the new domain name space also gives the chance to use
     the  DNS  to  distrubute  dynamically  the X.400 routing informations,
     solving thus another efficiency problem currently affecting the  X.400
     MHS implementations.
 
     In this paper we will adopt the RFC1327 mapping rules syntax,  showing
     how  it  can  be  stored into the Internet DNS, and the DOMAIN and WEP
     document  definitions  from  Urs  Eppenberger's  routing  coordination
     document.
 
     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 serveral 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 RFC1327 gateways  require  that  a  database  store
     address  mapping  information  for X.400 and RFC822.  This information
     must be  disseminated  to  all  RFC1327  gateways.   In  the  internet
     community,  the DNS has proven to be a practical means for providing a
     distributed nameservice.  Advantages of using a DNS based system  over
     a  table  based  approach for mapping between O/R addresses and domain
     names are:
 
          - It avoids fetching and storing  of  entire  mapping  tables  by
     every host that wishes to implement RFC1327.
 
          - Modifications to the DNS based mapping information can be  made
     available in a more timely manner than with a table driven approach.
 
          - Table management is  not  necessarily  required  for  DNS-based
     RFC1327 gateways.
 
          - One can determine the mappings in use by a  remote  gateway  by
     querying the DNS (remote debugging).
 
     Also the distribution via DNS of the current statically defined  X.400
     MHS routing information will take the same advantages listed above.
 
 
     3.  Proposal:  the new "X400.ARPA" domain space
 
     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
     distributed  database  under a number of top- level domains (EDU, COM,
     countries like  UK, IT, FR,  etc).  The special top-level/second-level
     couple  IN-ADDR.ARPA  is  used  to store the IP address to domain name
     relationship.
 
     Our proposal, which closely resembles the above model, is to store the
     RFC1327  mapping  informations  in  a new branch of the DNS name space
     (under the already defined top-level  domain  "ARPA")  using  the  PTR
     resource-record.   In particular in this new name space "X400.ARPA" we
     will have a complete set of existing  resource  records  available  to
     store  any  other  useful informations concerning X.400, like routing,
     responsible people, etc.
 
     This name space is thus used to contain completely  the  informations:
     the  data  required  by  an e-mail gateway to perform the X.400-RFC822
     mapping can be easily  found  with  a  simple  query  to  the  nearest
     nameserver,  thus  avoiding  a  long  search  in  complex,  statically
     defined, mapping tables.  Moreover there is no more any need to store,
     maintain and distribute manually those tables.
 
     The special name space begins at the top-level "X400.ARPA" and  should
     have  a  structure following the X.400 hierachical structure (country,
     ADMD, PRMD, organization, ...).   The  fully-qualified  PTR  value  is
     constructed  starting  from  the  original  RFC1327  mapping rule, and
     chaining the string ".X400.ARPA" at the end.
 
     The construction of the new domain space tree  will  follow  the  same
     procedures  used  when  organizing  at  first the already existing DNS
     space:  authoritative information about the X400.ARPA top-level domain
     is  maintained  by the root servers while a central nameserver in each
     country is delegated by the root servers to hold the national part  of
     the  mapping  tables.   At  first,  however,  the informations will be
     stored in a quite centralized way, and distribution of authority  will
     be   gradually   achieved.   A  seprate  document  will  describe  the
     implementation phase.
 
 
 
     4.  Detailed storage proposal for RFC1327 mapping rules.
 
     Among the resource-record types that can be  associated  to  a  domain
     name  in  the  DNS,  the  PTR  is  generically defined as a pointer to
     another part of the domain name space.  The only use of the PTR record
     being well known is in the IN-ADDR.ARPA domain space:  in that context
     it provides the IP address to domain name resolution (or "inverse name
     resolution").   PTR  in the new "X400.ARPA" name space will instead be
     used for storing RFC1327 mapping informations.
 
     The PTR format, as defined in the RFC 1034, section 3.3 is as follows:
 
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                 PTRDNAME                      |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 
     where:
 
     PTRDNAME       A <domain-name> which points to some location
                    in the domain name space.
 
     These resource records are used in special domains to  point  to  some
     other  location  in  the domain space.  These records are simple data,
     and do not imply any special processing.
 
     The PTR value, as defined in the RFC 1034, must be a domain name, i.e.
 
     <domain> ::= <subdomain> | " " 
     <subdomain> ::= <label> | <label>.<subdomain>
     <label> ::= <alphanum> {<alphanumhyphen>} <alphanum>
     <alphanum> ::= "0".."9" | "A".."Z" | "a".."z"
     <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
 
     As you will notice, the legal  character  set  for  <label>  does  not
     correspond  to  the  IA5  Printablestring  one.  However a very simple
     "escape mechanism" can be applied in order to bypass the problem.   We
     can simply describe the mapping rule format as:
 
     <map-rule> ::= <map-element> | <map-element> { "." <map-element> }
     <map-element> ::= <attr-label> "$" <attr-value>
     <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
     <attr-value> ::= " " | "@" | IA5-Printablestring
 
     In our model we define the following logical equivalences:
 
     <domain>  == <map-rule> + "X400.ARPA"
     <label> == <map-element>
 
     i.e.  we will use insert the <map-rule> information where usually  the
     <domain>  one  is,  and  the  <map-element>  will  replace the <label>
     element.
 
     4.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
     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>$       <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    condition
     ------------------------------------------------------------------
     PRMD$@             PRMD                     missing attribute
     ADMD$              ADMDb                    blank attribute
     ADMD$400-net       ADMD-400-h-net           hyphen mapping
     PRMD$UK\.AC        PRMD-UK-d-AC             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
 
     Thus, a complete 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
 
     translates to
 
           OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
 
     4.1.1 Flow chart
 
     In order to achieve the proper DNS store translations of  the  RFC1327
     mapping rules 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  viceversa)  are  not  user friendly enough to think of a
     human made conversion.
 
     To help in designing such tools, a small flow chart will be described.
     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 tranlsated left
     section of the string in subsequent analysis."
 
 
     Flow chart 1 - Translation from rfc1327 to DNS format:
 
                     parse single attribute
                   (enclosed in . separators)
                               |
                 (yes)     <label>$@ ?     (no)
                   |                         |
             map to <label>         (no)  <label>$  ?  (yes)  
                   |                  |                  |         
               next elem.         map to <label>-    map to <label>"b"
                                      |                  |
                               map "\." to -d-       next elem.
                                      |
                               map "-" to -h-
                                      |
                              map non A/N char
                                      |
                           remove (if any) last "-"
                                      |
                                  next elem.
 
 
 
     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)  
                   |                  |                  |         
               next elem.         map to <label>-    map to <label>$ 
                                      |                  |
                                map -d- to "\."       next elem.
                                      |
                                map -h- to "-"
                                      |
                         map -<3digit> to non A/N char
                                      |
                                  next elem.
 
     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 Table 1 and RFC1327 Table 2; thus  also  in
     DNS we will mantain the two different sections, even if they will both
     belong to the PTR section.  More over RFC1327  also  specify  a  third
     table:   RFC1327  Gate Table.  This additional table, however, has the
     same syntax rules than RFC1327 Table 2 and thus the  same  tranlsation
     procedure  as  Table 2 will be applied; some details about the RFC1327
     Gate table are discussed in section 4.2.
 
     A file containing the RFC1327 mappig  rules  and  RFC1327  Gate  table
     written in DNS format will look like the following example:
 
     !
     ! RFC1327 table 1: X.400  --> RFC822
     !
     ADMD-garr.C-it.X400.ARPA.                       IN PTR it.X400.ARPA.
     PRMD-switch.ADMD-arcom.C-ch.X400.ARPA.          IN PTR switch.ch.X400.ARPA.
     O-uw-h-madison.PRMD-xnren.ADMDb.C-us.X400.ARPA. IN PTR cs.wisc.edu.X400.ARPA.
     !
     ! RFC1327 table 2: RFC822 --> X.400
     !
     cnr.it.X400.ARPA.       IN PTR  PRMD-CNR.ADMD-garr.C-it.X400.ARPA.
     infn.it.X400.ARPA.      IN PTR  O.PRMD-infn.ADMD-garr.C-it.X400.ARPA.
     ac.uk.X400.ARPA.        IN PTR  PRMD-uk-d-ac.ADMDb.C-gb.X400.ARPA.
     !
     ! RFC1327 Gate Table
     !
     my.G.X400.ARPA.   IN PTR  OU-cosine-h-gw.O.PRMD-infn.ADMD-garr.C-it.X400.ARPA.
     edu.G.X400.ARPA.  IN PTR  O-mhs-h-relay.PRMD-xnren.ADMDb.C-us.X400.ARPA.
 
     which corresponds to the following RFC1327 table:
 
     #
     # RFC1327 table 1: X.400  --> RFC822
     #
     ADMD$garr.C$it#it#
     PRMD$switch.ADMD$arcom.C$ch#switch.ch#
     O$uw-madison.PRMD$xnren.ADMD$ .C$us#cs.wisc.edu#
     #
     # RFC1327 table 2: RFC822 --> X.400
     #
     cnr.it#PRMD$CNR.ADMD$garr.C$it#
     infn.it#O.PRMD$infn.ADMD$garr.C$it#
     ac.uk#PRMD$uk\.ac.ADMD$ .C$gb#
     #
     # RFC1327 Gate table
     #
     my#OU$cosine-gw.O$@.PRMD-infn.ADMD$garr.C$it#
     edu#O$mhs-relay.PRMD$xnren.ADMD$ .C$us#
 
 
     4.2 Storing the RFC1327 Gate table
 
     The RFC1327 Gate table syntax is identical to RFC1327 Table  2.   Thus
     the  same  syntax  translation rules from RFC1327 to DNS format can be
     applied.  However, as the three RFC1327 tables  are  stored  into  the
     same  DNS  PTR  section,  we must distinguish between Table 2 and Gate
     Table informations.  This is easily obtained adding and additional "G"
     third  level  pseudo-domain  (i.e.   "G.X400.ARPA"  as a whole) to the
     RFC822 domain part of the table.  The example in section  4.1.1  shows
     clearly  the  result.   As  "G"  is an illegal RFC822 top level domain
     there are no comflicts  or  ambiguities  in  using  it  as  a  special
     identifier.   To  be more explicit, the left hand side (RFC822 domain)
     of a Table 2 rule adds ".X400.ARPA", wheareas the left hand side of  a
     Gate table entry adds ".G.X400.ARPA".  The right hand side (O/R domain
     address) adds ".X400.ARPA" in both cases.
 
 
     5.  Finding RFC1327 mapping information from DNS
 
     The RFC1327 mapping information is  stored  in  PTR  resource  records
     located  in nodes of the the DNS tree.  The resource record associated
     with a particular node is identified by the  concatenation  of  labels
     encountered while traversing the tree to that node.  As defined above,
     a PTR record is identified by  elements  derived  from  an  X.400  O/R
     address  (Table  1)  or  by  an  RFC-822 domain name (Table 2 and Gate
     table).
 
     Moreover, placing our PTR mapping records under the same new X400.ARPA
     root  will  provide  a  good  facility for management of the mappings,
     distribution of the zones of  the  DNS,  and  minimize  zone  transfer
     resource consumption.
 
     The mapping information  stored  in  PTR  resource  records  does  not
     represent  a  full  O/R address.  It is a template which specifies the
     fields of the O/R address 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 (RFC1327:  section 4.3.4, State I;  section  4.3.5,  mapping
     B).   A  recursive  set of queries to the DNS will be issued trying to
     find a PTR record with the longest possible match.   As  specified  in
     RFC1327,  a  search of the mapping table will result in either success
     (mapping found) or failure (all queries 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 RFC 1327.  If a DNS error
     code is returned, an error message should be logged  and  the  gateway
     operation is delayed as for timeout.
 
     Searching the name-server which can authoritatively solve the query is
     automatically performed by the DNS distributed name-service.
 
     5.1 A DNS query example
 
     An RFC1327 mail-gateway  located  in  the  Internet,  when  traslating
     addresses  from RFC822 to X.400, can get information about the RFC1327
     mapping rule asking the DNS.  As  an  example,  when  translating  the
     address SUN.CNUCE.CNR.IT, the gateway will append "X400.ARPA" and then
     query DNS for the associated PTR record.  The DNS should contain a PTR
     record like this:
 
     cnuce.cnr.it.X400.ARPA. IN PTR O-cnuce.PRMD-cnr.ADMD-garr.C-it.X400.ARPA.
 
     The first query will  fail.   Then  'SUN'  will be dropped and a  new
     query  will be issued, returning the mapping rule is DNS store format.
     Applying  the  syntax  translation  specified in  paragraph  4.1  and
     dropping "X400.ARPA" the RFC1327 mapping rule will be obtained.
 
     Translating from X.400 to RFC822 the address
 
          C=de; ADMD=dbp; PRMD=dfn; O=gmd;
 
     the mail gateway should convert the syntax according to paragraph 4.1,
     append  "X400.ARPA"  and  then  query  DNS  for  the corresponding PTR
     record.  The DNS should contain:
 
     ADMD-dbp.C-de.X400.ARPA.  IN PTR dbp.de.X400.ARPA.
 
     Assuming that there are not more specific  PTR  records  in  DNS,  the
     first  two  queries  will  fail;  then  the PTR record value is found,
     "X400.ARPA" is dropped and the RFC1327 rule is available.
 
     When looking for an entry in the RFC1327 Gate table, the gateway  will
     append  "G.X400.ARPA"  to the RFC822 domain and then query DNS for the
     associated PTR record.  If we are looking for  the  Gate  table  entry
     representing  top level domain "MY", then the DNS should contain a PTR
     record like this:
 
     my.G.X400.ARPA.  IN PTR O-cnuce.PRMD-cnr.ADMD-garr.C-it.X400.ARPA.
 
     DNS will return, possibly after some recursive iterations, the rule in
     DNS  store  format.   Applying  the  syntax  translation  specified in
     paragraph 4.1 and dropping "X400.ARPA" the RFC1327  Gate  table  entry
     rule will be obtained.
 
 
 
 
     6.  Administration of mapping information
 
     Not all RFC1327 gateways will be able to use the Internet DNS  to  map
     between  O/R  addresses  and RFC822 domain names.  It is expected that
     gateways in a particular country or management domain will conform  to
     one of the following models:
 
          Table-based    DNS-based    X.500-based
 
     Table-based countries and management domains will submit  and  receive
     their mapping tables from the International Mapping Table coordinator.
     DNS-based countries and management domains will  store  their  mapping
     information   in  the  DNS.   The  DNS  Mapping  coordinator  will  be
     responsible  for  operating  authoritative  nameservers  for  resource
     records  pertinent  to management domains in Table- based communities.
     Also, the DNS Mapping coordinator will be responsible  for  generating
     the table form of mappings based in the DNS and transmitting it to the
     International Mapping Table coordinator.  X.500-based storage  is  not
     yet fully defined.
 
     As of this writing, the International Mapping Table coordinator is the
     COSINE  MHS Project Team and the DNS Mapping coordinator is the COSINE
     Gateway Service.
 
     A set of coordination procedures to keep  aligned  the  three  mapping
     distribution  services  will  be published in the implementation phase
     document.
 
 
 
     7.  Storing and finding X.400 routing informations
 
     In the usual domain name space  the  MX  records  are  used  to  store
     information for SMTP mailers; their content is a list of possible Mail
     eXchanger and a pure number  stating  the  preferred  order  of  these
     mailers  (priority).  As we created a new domain space under X400.ARPA
     top level domain, we can now use the MX  resource  records  in  it  to
     store  informations  about  routing  in  the X.400 MHS, using the same
     principles adopted by SMTP mailers.  A document defining the X.400 MHS
     routing   strategy   has   been   defined   by  Urs  Eppenberger  from
     SWITCH/COSINE MHS project team.  In this document the approach to  the
     routing  problem  is  again table driven, using the so called "DOMAIN"
     and "WEP" documents (section 3).  However  the  data  defined  in  the
     DOMAIN  document  closely  resembles the MX approach, allowing an easy
     use of DNS MX resource records for storing  X.400  MHS  routing  data.
     Some  other  DNS  resource  records  will  then  be  used to store the
     additional data present in the WEP document.
 
     The definition of the usual MX record in DNS is:
 
     <domain> <class> MX <prio> <dest-host-domain>
 
     where <dest-host-domain> is then resolved via an "A"  resource  record
     into  an  IP  host address:  in fact the only transport forseen in DNS
     for SMTP protocol is TCP/IP, and  the  socket  number  25  is  already
     reserved.  Also DDCMP and X.25 transports are used for SMTP (DSMTP and
     XSMTP), but their connection data are not included and distributed via
     DNS.
 
     In the X.400 MHS routing document we can identify these elements:
 
     <MHS-subtree> <Default-Priority> <UniqueMTAkey> <Delay>
 
     which can be somehow equivalenced to the usual DNS elements.   However
     the  routing  can be done on different protocol stacks, and each stack
     can have a different priority.  Thus we have additional data for  each
     specific stack:
 
     <Service-type> <P-address> <Priority>
 
     On the other hand, the MTA connection data are much more complex  than
     a  simple  4-byte  IP  address.   For each connection stack we have in
     fact:
 
     <password> <called-connection> <calling connection>
 
     and both <called-connection> and  <calling-connection>  is  a  set  of
     complex data.  Thus we will need additional store to keep these data.
 
     7.1 Detailed storage proposal for routing informations in DNS
 
     To implement in the most convenient  way  the  storage  of  X.400  MHS
     routing data we can take advantage of the DNS MX records; in fact they
     already provide  wildcard  support  and  a  priority  mechanism  (note
     however  that the X.400 MHS priority values must be interpreted in the
     opposite direction than SMTP  ones).   Other  available  DNS  resource
     record  types  will  be  then  used  for  the  remaining  WEP data; in
     particular  the  HINFO  resource  record  can  be  used  for  the  WEP
     connection and system data.
 
     Let us define the <MHS-route-record> object which can be inserted into
     a DNS MX reseource record:
 
     <MHS-route-record> ::= <MHS-ORdomain> "IN" "MX" <Defualt-Priority> \
                            <WEP-data>
 
     where:
 
     <MHS-ORdomain> ::= DNS translation of <MHS-subtree> (sect. 7.1.1)
 
     <WEP-data> ::= { <DNS-Service-key> "-" <DNS-Priority> "." } \
                      <DNS-Delay> "." <DNS-MTAkey>
 
     <DNS-MTAkey> ::= DNS translation of <UniqueMTAkey> (sect. 7.1.2)
 
     <DNS-Delay> ::= DNS translation of <Delay> (sect. 7.1.3)
 
     <DNS-Priority> ::= DNS translation of <Priority> (sect. 7.1.4)
 
     <DNS-Service-key> ::= A unique keywork to identify a <WEP-call-data> 
                           and <WEP-clng-data> record (sect. 7.1.5)
 
     The additional data for a WEP connection are  stored  into  HINFO  DNS
     resource  records.   In particular we need to store informations about
     the WEP itself (password, system,  supported  stacks)  and  about  the
     network  connectivity (service type, MTS, P- address).  We define thus
     three records, which will be stored into  three  different  DNS  HINFO
     records:
 
     <WEP-host_data> ::= <DNS-MTAkey>  "IN" "HINFO" "<password> <system>" \
                         "<DNS-Service-key> { [ "." <DNS-Service-key> ] }"
 
     <WEP-call-data> ::= "C." <DNS-Serivce-key> "." <DNS-MTAkey> \
                         "IN" "HINFO" "<Service-type> <MTS>" "<P-address>"
 
     <WEP-clng-data> ::= "R." <DNS-Serivce-key> "." <DNS-MTAkey> \
                         "IN" "HINFO" "<Service-type>" "<P-address>"
 
     Note   that   the   <DNS-Service-key>   list   contained   into    the
     <WEP-host-data> record must contain exactly the same elements used for
     any couple of <WEP-call-data> and <WEP-clng-data> records, i.e.  is we
     have  3  couples  of connection information records using "XX0", "RX0"
     and "IT6" keys, then this list must be present in the  <WEP-host-data>
     record.
 
     The HINFO resource record can hold up  to  twice  256  octet  strings,
     allowing  thus  enough  available  space  even for complex <P-address>
     data.
 
     The concept of routing records in the DOMAIN document has an  implicit
     wildcard   specification:    anything   ending   up  with  the  stated
     <MHS-subtree> is to be routed as indicated,  unless  a  more  specific
     routing  record  is  found.   In DNS MX records this must be specified
     using explicitly wildcards, as it allows to  specify  fully  qualified
     domains,  too.  This feature could eventually be used to obtained more
     detailed X.400 MHS routing rules with DNS (see an example  in  section
     7.2).
 
 
 
     7.1.1 DNS translation of <MHS-subtree>
 
     The allowed character set for an <MHS-ORdomain> is the same  described
     in  section  4,  as  its  definition  corresponds in DNS to a <domain>
     element.  Thus we will follow the same approach described  in  section
     4.1  for non {alphanumhypehn} elements, and a similar solution for the
     general tranlsation.
 
     The definition of <MHS-subtree> in the DOMAIN document is:
 
     <MHS-subtree> ::= "Domain: " \
                       "C=" 'Two Character Contry Code ISO-3166' \
                       ";ADMD=" 'ADMDname' \
                       [ ";PRMD=" 'PRMDname' ] \
                       [ ";O=" 'Organization-name' ] \
                       [ { ";OU=" 'Org-unit-name' } ]
 
     i.e.  a label ("Domain:") followed by a string made  up  by  Attribute
     Labels  ("C", "ADMD", "PRMD", "O", "OU") plus Attribute Values and ";"
     as separators.
 
     This definition allows  in  its  syntax  to  skip  eventually  missing
     intermediate  address  elements,  instead  of substituting them with a
     standard placeholder ("@") as defined in  RFC1327  for  mapping  rules
     syntax.  The new DNS tree under top level domain "X400.ARPA", however,
     must be coherent in order to allow a correct distribution of authority
     and  a  correct  sequence of queries along its branches.  Thus we will
     insert again  the  skipped  attributes  into  our  DNS  translaion  of
     <MHS-subtree>  and  <UniqueMTAkey>,  using  the same placeholder ("@")
     defined in RFC1327.
 
     An equivalent definition of <MHS-subtree> is:
 
     <MHS-subtree> ::= "Domain: " <addr-element> [ { ";" <addr-element> } ]
     <addr-element> ::= <attr-label> "=" <attr-value>
     <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
     <attr-value> ::= IA5-Printablestring
 
     To obtain our <DNS-ORdomain> we will follow these rules:
 
     - drop the "Domain: " label;
     - revert the order of <addr-element>;
     - insert eventually missing intermediate attributes as
       <attr-label> "=" "@";
     - "quote" all dots (".") in <attr-value>;
     - build <DNS-ORdomain> as:
       
     <DNS-ORdomain> ::= <d-addr-elem> [ { "." <d-addr-elem> } ] ".X400.ARPA"
     <d-addr-elem>  ::= <attr-label> "-" <mapped-attribute-value>
 
     Substituing the "$" sign with the "=" sign and the "." separator  with
     the ";" one, the same rules specified in sections 4.1 and 4.1.1 can be
     thus used to translate <attr-  value>  into  <mapped-attribute-value>.
     Let's have some examples:
 
          Domain:  C=CH;ADMD=ARCOM;PRMD=WHO;
 
     is translated in <DNS-ORdomain> as
 
          PRMD-WHO.ADMD-arcom.C-ch.X400.ARPA
 
     Another one:
 
          Domain:  C=GB;ADMD= ;PRMD=UK.AC;OU=ACME Inc.;
 
     is translated in <DNS-ORdomain> as
 
          OU-ACME-b-Inc-d.O.PRMD-UK-d-AC.ADMDb.C-GB.X400.ARPA
 
     7.1.2 DNS translation of <UniqueMTAkey>
 
     The character set and syntax allowed for a <DNS-MTAkey> is  again  the
     one  corresponding  in DNS to a <domain> element.  Thus sections 4 and
     4.1 already give us the correct solution.
 
     More over <UniqueMTAkey> syntax is very  close  to  the  <MHS-subtree>
     one:
 
     <UniqueMTAkey> ::=  "C=" 'Two Character Contry Code ISO-3166' \
                       ";ADMD=" 'ADMDname' \
                       [ ";PRMD=" 'PRMDname' ] \
                       [ ";O=" 'Organization-name' ] \
                       [ { ";OU=" 'Org-unit-name' } ] \
                       ";MTAname=" 'MTAname'
 
     i.e.  an <MHS-subtree> definition, locating exactly the MTA within its
     management domain, plus the MTA name itself.  An equivalent definition
     is again
 
     <UniqueMTAkey> ::= <addr-element> [ { ";" <addr-element> } ]
     <addr-element> ::= <attr-label> "=" <attr-value>
     <attr-label>   ::= "C" | "ADMD" | "PRMD" | "O" | "OU" | "MTAname"
     <attr-value>   ::= IA5-Printablestring
 
     To obtain our <DNS-MTAkey> we will follow these rules:
 
     - revert the order of <addr-element>;
     - insert eventually missing intermediate attributes as
       <attr-label> "=" "@";
     - "quote" all dots (".") in <attr-value>;
     - replace "MTAname=" with "MTA=" 
     - build <DNS-MTAkey> as:
       
     <DNS-MTAkey>  ::= <d-addr-elem> [ { "." <d-addr-elem> } ] ".X400.ARPA"
     <d-addr-elem> ::= <attr-label> "-" <mapped-attribute-value>
 
     Substituing the "$" sign with the "=" sign and the "." separator  with
     the ";" one, the same rules specified in sections 4.1 and 4.1.1 can be
     thus used to translate <attr-  value>  into  <mapped-attribute-value>.
     Let's have some examples:
 
          C=it;ADMD=garr;PRMD=infn;OU=cosine-gw;MTAname=cosine-gw.infn.it
 
     is translated in <DNS-MTAkey> as
 
          MTA-cosine-h-gw-d-infn-d-it.OU=cosine-h-gw.O.PRMD-infn. \
          ADMD-garr.c-it.X400.ARPA
 
     Another one:
 
          C=GB;ADMD= ;PRMD=UK.AC;MTAname=uk.ac.mhs-relay
 
     is translated in <DNS-MTAkey> as
 
          MTA-uk-d-ac-d-mhs-h-relay.PRMD-UK-d-AC.ADMDb.C-GB.X400.ARPA
 
 
     7.1.3 DNS translation of <Delay>
 
     As <Delay> is a pure number, we need to apply a label to it  in  order
     to  be  conformant  with  RFC1034  and also to distinguish it from the
     other elements.  Thus our definition of <DNS-delay> is
 
     <DNS-delay> ::= "D" <Delay>
 
     If <Delay> is defined as "25", then its DNS translation will be "D25".
 
     7.1.4 DNS translation of <Priority>
 
     As <Priority> is a pure number, we need to apply  a  label  to  it  in
     order  to  be  conformant with RFC1034 and also to distinguish it from
     the other elements.  Thus our definition of <DNS-priority> is
 
     <DNS-priority> ::= "P" <Priority>
 
     If <Priority> is defined as "5", then  its  DNS  translation  will  be
     "P5".
 
     7.1.5 Defining the <DNS-Service-key>
 
     The <DNS-Service-key> is just a  label  to  identify  a  DNS  resource
     record  where  the  relevant MTA connection data are stored.  Thus its
     only  requirement  is  to  be  unique  within  an  MTA  identified  by
     <DNS-MTAkey>.  However it could be very useful to define some criteria
     and common abbreviations in order to have short  keys  and  also  some
     "guessable"  keys  for  the  most  common cases.  Our suggestion is to
     adopt a three characters key:
 
     <DNS-Service-key> ::= <k-name> <k-service> <k-protocol>
 
     <k-name> ::= one A/N character identifying the network name, adopting
                  the following abbreviations:
 
                       'X' Public-X.25
                       'I' Internet
                       'R' RARE-IXI
                       'L' RARE-CLNS
 
     <k-service> ::= "X" | "O" | "L" | "T"
                     standing respectively for X.25, CONS, CLNS, TCP
 
     <k-protocol> ::= "0" | "2" | "4" | "6"
                      standing respectively for TP0, TP2, TP4, RFC1006
 
     Thus "Internet/TCP/RFC1006" will produce a  <DNS-Service-key>  =  IT6,
     while "RARE-IXI/CONS/TP0" produces <DNS-Service-key> = RO0.
 
 
     7.2 An example of DNS stored Domain and WEP documents
 
     As said in the previous sections, the X.400 MHS routing  data  can  be
     stored  in  DNS  using  MX  and  HINFO reseouce records and the set of
     defined mapping rules.  Let's see an example  containing  the  routing
     data of a management domain.
 
     ;
     ; document it.garr
     ;
     ; Community: COSINE-MHS
     ; Update: DATE=920806
     ;
     *.ADMD-GARR.C-it.X400.ARPA. IN  MX 10 \
       RX0-P9.XX0-P7.D0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
                             IN  MX 20 \
       RX0-P9.XX0-P7.D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
     ;
     *.PRMD-Y-h-net.ADMD-Master400.C-it.X400.ARPA.  IN  MX  10 \
       RX0-P9.XX0-P7.D0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
                             IN  MX 20 \
       RX0-P9.XX0-P7.D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
     ;
     ; WARNING the next record routes ONLY C=it;ADMD=Master400;PRMD=ssgrr;
     ; OR address, excluding any subdomain.
     ;
     PRMD-ssgrr.ADMD-Master400.C-it.X400.ARPA.  IN  MX  10 \
       RX0-P9.XX0-P7.D0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
                             IN  MX 20 \
       RX0-P9.XX0-P7.D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
     ;
     *.PRMD=isanet.ADMD-0.C-is.X400.ARPA.  \
        IN  MX 10 D5.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
        IN  MX 20 D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
     ;
     ; Now infn.it WEP host data
     ;
     MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
       "Password: not used; COM=VAX4000; OPS=VMS5.5; MHS=MRX2.2-000" \
       "RX0.XX0"
     ;
     ; Now infn.it WEP connection data
     ;
     C.RX0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
       "RARE-IXI/X.25/TP0; MTS-TP-84" \
       "INFN/TELEX+00728722+X25(80)+04+20432240000+CUDF+03010100" 
     ;
     R.RX0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
       "RARE-IXI/X.25/TP0" \
       "INFN/TELEX+00728722+X25(80)+04+20432240000" 
     ;
     C.XX0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
      "Public-X.25/X.25/TP0; MTS-TP-84" \
      "INFN/TELEX+00728722+X25(80)+01+22225110072+CUDF+03010100"
     ;
     R.XX0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
      "Public-X.25/X.25/TP0" \
      "INFN/TELEX+00728722+X25(80)+01+22225110072"
     ;
     ; Now cosine-gw.infn.it WEP host data
     ;
     MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
       "Password: not used; COM=VAX9210; OPS=VMS5.5; MHS=MRX2.2-000" \
       "RX0.XX0"
     ;
     ; Now cosine-gw.infn.it WEP connection data
     ;
     C.RX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
       "RARE-IXI/X.25/TP0; MTS-TP-84" \
       "INFN/TELEX+00728722+X25(80)+04+20432240009008+CUDF+03010100"
     ;
     R.RX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
       "RARE-IXI/X.25/TP0" \
       "INFN/TELEX+00728722+X25(80)+04+20432240009008"
     ;
     C.XX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
       "Public-X.25/X.25/TP0; MTS-TP-84" \
       "INFN/TELEX+00728722+X25(80)+01+22225110072082+CUDF+03010100"
     ;
     R.XX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.  IN  HINFO \
       "Public-X.25/X.25/TP0" \
       "INFN/TELEX+00728722+X25(80)+01+22225110072082"
 
     Note that the above lines have been wrapped for clarity reasons, using
     "\" to show continuation on the same line.
 
     7.3 An example of query to DNS for routing data
 
     In this example we will assume that the routing data those defined  in
     section 7.2; let's see how it works.
 
     Case 1:  OR address C=it;ADMD=garr;PRMD=infn;S=helpdesk;
 
     After translation of the routing part of the OR address in DNS syntax,
     a   first   query   for   an  MX  records  list  will  be  issued  for
     PRMD-infn.ADMD-garr.C-it.X400.ARPA; DNS will match the query with  the
     first couple of MX records listed in our above example, i.e.
 
     IN MX 10 RX0-P9.XX0-P7.D0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
     IN MX 20 RX0-P9.XX0-P7.D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
 
     The answer contains already a choice between 2 possible WEPs and again
     2  available connection stacks per each WEP, identified by RX0 and XX0
     keyworks and with different priorities.  Note that the RX0 key of  the
     first  records  has nothing to do with the identical one in the second
     record:  they just happen to look the same, but a  <DNS-  service-key>
     is meaningful and must be uniqe only within a <DNS-MTAkey>.
 
     As priority 20 indicated the preferred WEP, and we already  have  also
     the  preferred  connection  stack (identified by RX0 key) we can query
     directly for connection data, looking an HINFO record like:
 
     C.RX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
 
     and attempt connection to the remote WEP.  If this fails, according to
     Eppenberger's  document,  we  will  then  query for the next supported
     stack connecton record (identified by XX0 key plus  <DNS-MTAkey>)  and
     continue like that.
 
     Case 2:  OR address C=is;ADMD=0;PRMD=isanet;O=mgr;S=postmaster;
 
     After translation of the routing part of the OR address in DNS syntax,
     a first query for an MX records list will be issued for
 
     O-mgr.PRMD-isanet.ADMD-0.C-is.X400.ARPA
 
     DNS will match the query with:
 
     IN  MX 10 D5.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
     IN  MX 20 D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
 
     In this case the answer only indicates  2  possible  WEPs  with  their
     priority,  but  gives  no preference about possible connection stacks,
     nor informs us about the availble connection  stacks.   We  will  then
     query for an HINFO record containing the WEP host informations for the
     preferred 'cosine-gw.infn.it' one, i.e.  query for
 
     MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA. 
 
     HINFO record. The result will be:
 
     "Password: not used; COM=VAX9210; OPS=VMS5.5; MHS=MRX2.2-000" \
     "RX0.XX0"
 
     We can now choose, at  our  discrection  about  2  possible  connecton
     stacks,   identified  by  RX0  and  XX0  keywords,  querying  for  the
     respective <WEP-call-data> records and continuing as for  the  case  1
     example.
 
 
 
     8.  Conclusion
 
     The use of the PTR resource-record and a new name space tree  promises
     to  provide  a good possible repository for mapping informations.  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 introduction of the new "X400.ARPA"  domain  name  space
     allows us also to use the DNS to store and distribute many other X.400
     MHS informations, including the routing ones.  The use of the DNS  has
     many  advantages in storing, managing and updating information.  Using
     the existing resource records in the  new  name  tree  does  not  even
     require  the  introduction  of new types.  A further study to define a
     storage detailed strategy for routing informations  is  expected  when
     the table-driven routing strategy for X.400 MHS becomes stable.
 
     Software to query the DNS and then  to  convert  between  the  textual
     representation  of DNS resource records and the address format defined
     in RFC1327 needs to be developed.   Also  some  tools  to  derive  DNS
     format  from  DOMAIN  and  WEP  documents  will  be needed to help the
     implementation of this specification.
 
 
 
 
     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",  RFC  1034,  USC/Information Sciences Institute, November
     1987.
 
 
          [RFC 1035] Mockapetris, P., "Domain names  -  Implementation  and
     Specification", RFC 1035, USC/Information Sciences Institute, November
     1987.
 
 
          [Internet draft] Eppenberger, U., "Routing Coordination for X.400
     MHS  services  within  a  multi protocol / multi network environment",
     March 1992.
 
 
 
 
 
     10. Document Expiration Date
 
     This document was submitted on September 23rd, 1992 and its validity
     will expire on March 23rd 1993.